It makes no sense to link vmlinuz and initramfs to the root directory

[kindusmith]

In early Unix, boot and vmunix were both stored in the root directory as
programs, and boot was used to start vmunix. Debian inherited this for
compatibility, but the situation has changed a lot. Today, boot is
stored in the root directory as a directory, which already contains the
kernel files vmlinuz and initramfs. Therefore, it makes no sense to link
vmlinuz and initamfs to the root directory, so the best way is to remove
them from the root directory.

[Geert Stappers]

Post by kindusmith
In early Unix, boot and vmunix were both stored in the root directory as
programs, and boot was used to start vmunix. Debian inherited this for
compatibility, but the situation has changed a lot. Today, boot is stored in
the root directory as a directory, which already contains the kernel files
vmlinuz and initramfs. Therefore, it makes no sense to link vmlinuz and
initamfs to the root directory, so the best way is to remove them from the
root directory.

Chesters fence

[Bjørn Mork]

Post by Geert Stappers
Chesters fence

Chesterton's?


Bjørn

[Hans]

Am Dienstag, 12. November 2024, 07:14:34 CET schrieb kindusmith:
In very early linux, as far as I remember in SuSE-Linux, the kernel was
installed in a small partition /boot (about 3 or 4 sizes of the kernel) and a
link ponting to the kernel on the root-partitiion (the one, mounted to "/")

This got some advantages. If you have a very big root poartition and the
kernel was installed there, then it was possible, the system could not boot,
because the kernel was not found. The reason for this was, the BIOS could not
handle the size of this big partition.

To fix this and get not in trouble, the idea was to make a small partition
which got the kernel and can be booted, then after the kernel has started,
BIOS is no more used, because the kernel is handling the paretitiions. Andthe
kernel can handle very, very big partitions.

The sesond advantage of putting the kernel so, is , you can mount the kernel
partition read-only, so it can not be harmed by any malware.

For the uprading procedure it is possible (with a little script), to make this
partition writable, and automatically read-only after upgrade is done.
(If someone is interested in this, I will paste the script here, these are
only 4 lines).

I might remember, the seperated /boot partition was also default in RedHat,
Mandriva and SLAX, but I am not quite sure. It is now a long time ago!

However, maybe a link is alo no more needed, even with a seperated /boot
partition.

Best

Hans

Post by kindusmith
In early Unix, boot and vmunix were both stored in the root directory as
programs, and boot was used to start vmunix. Debian inherited this for
compatibility, but the situation has changed a lot. Today, boot is
stored in the root directory as a directory, which already contains the
kernel files vmlinuz and initramfs. Therefore, it makes no sense to link
vmlinuz and initamfs to the root directory, so the best way is to remove
them from the root directory.

[Andrey Rakhmatullin]

Post by Hans
In very early linux, as far as I remember in SuSE-Linux, the kernel was
installed in a small partition /boot (about 3 or 4 sizes of the kernel) and a
link ponting to the kernel on the root-partitiion (the one, mounted to "/")
This got some advantages. If you have a very big root poartition and the
kernel was installed there, then it was possible, the system could not boot,
because the kernel was not found. The reason for this was, the BIOS could not
handle the size of this big partition.
To fix this and get not in trouble, the idea was to make a small partition
which got the kernel and can be booted, then after the kernel has started,
BIOS is no more used, because the kernel is handling the paretitiions. Andthe
kernel can handle very, very big partitions.
The sesond advantage of putting the kernel so, is , you can mount the kernel
partition read-only, so it can not be harmed by any malware.
For the uprading procedure it is possible (with a little script), to make this
partition writable, and automatically read-only after upgrade is done.
(If someone is interested in this, I will paste the script here, these are
only 4 lines).
I might remember, the seperated /boot partition was also default in RedHat,
Mandriva and SLAX, but I am not quite sure. It is now a long time ago!
However, maybe a link is alo no more needed, even with a seperated /boot
partition.

I'm afraid none of this is relevant to the question which was about
garbage symlinks in /. We know how is /boot used.

[Johannes Schauer Marin Rodrigues]

Quoting Hans (2024-11-12 09:35:08)

Post by Hans
However, maybe a link is alo no more needed, even with a seperated /boot
partition.

It's just a symlink. What's the harm?

Having the symlink is very practical for bootloaders that are not grub.
Pointing an extlinux.conf or a boot.scr to /vmlinuz instead of having to infer
the version is nice.

The tool debvm-run also relies on that symlink to infer the kernel image
location.

And so does the tool mmdebstrap-autopkgtest-build-qemu.

This is why this is a good example of Chesterton's Fence as Geert already
pointed out. Before trying to tear it down, maybe you missed some of its uses.

Thanks!

cheers, josch

[Guillem Jover]

Hi!

Post by Johannes Schauer Marin Rodrigues
Quoting Hans (2024-11-12 09:35:08)

Post by Hans
However, maybe a link is alo no more needed, even with a seperated /boot
partition.

It's just a symlink. What's the harm?

For me, the default location of the symlinks (which was the initial complaint)
pollutes the root directory with files that to me do not belong there.

Post by Johannes Schauer Marin Rodrigues
Having the symlink is very practical for bootloaders that are not grub.
Pointing an extlinux.conf or a boot.scr to /vmlinuz instead of having to infer
the version is nice.

While related, I don't think this was the complaint at hand. I've got
no systems I personally manage with symlinks on /, but for the systems
where those symlinks are present (most of them, one with etckeeper
history going back to 2009, when I installed etckeeper there), those get
placed under /boot, which gives the advantages you point out.

This would be the distinction between:

do_symlinks = yes

and

image_dest = /boot

or

link_in_boot = yes

Post by Johannes Schauer Marin Rodrigues
The tool debvm-run also relies on that symlink to infer the kernel image
location.
And so does the tool mmdebstrap-autopkgtest-build-qemu.
This is why this is a good example of Chesterton's Fence as Geert already
pointed out. Before trying to tear it down, maybe you missed some of its uses.

I've had in mind starting this discussion some time ago, when I found
again a system with this default (thanks for starting it now!), but
postponed it because it would require checking whether there is any
current code that might break (although that would seem surprising
given the kernel-img.conf options available).

I think the first step, before considering a default change would probably
be a visit over codesearch.debian.net, and then see what needs fixing or
adapting to support both locations, then file some bugs (ideally with
patches), and once those are handled then file a bug against whatever
generates the default kernel-img.conf, and against what holds the default
value to change it?

Thanks,
Guillem

[Michael Stone]

Post by kindusmith
In early Unix, boot and vmunix were both stored in the root directory
as programs, and boot was used to start vmunix. Debian inherited this
for compatibility, but the situation has changed a lot. Today, boot is
stored in the root directory as a directory, which already contains
the kernel files vmlinuz and initramfs. Therefore, it makes no sense
to link vmlinuz and initamfs to the root directory, so the best way is
to remove them from the root directory.

You may alter /etc/kernel-img.conf however you wish.

[Iustin Pop]

Post by Michael Stone

Post by kindusmith
In early Unix, boot and vmunix were both stored in the root directory as
programs, and boot was used to start vmunix. Debian inherited this for
compatibility, but the situation has changed a lot. Today, boot is
stored in the root directory as a directory, which already contains the
kernel files vmlinuz and initramfs. Therefore, it makes no sense to link
vmlinuz and initamfs to the root directory, so the best way is to remove
them from the root directory.

You may alter /etc/kernel-img.conf however you wish.

The question is why on a default install with grub, which doesn't need
nor use the symlinks, are they still created. For most systems, they're
superfluous.

iustin, who also dislikes these and always needs to disable them

[Marco d'Itri]

Post by Iustin Pop
The question is why on a default install with grub, which doesn't need
nor use the symlinks, are they still created. For most systems, they're
superfluous.
iustin, who also dislikes these and always needs to disable them

Agreed.

[Ben Hutchings]

Post by Iustin Pop

Post by Michael Stone

Post by kindusmith
In early Unix, boot and vmunix were both stored in the root directory as
programs, and boot was used to start vmunix. Debian inherited this for
compatibility, but the situation has changed a lot. Today, boot is
stored in the root directory as a directory, which already contains the
kernel files vmlinuz and initramfs. Therefore, it makes no sense to link
vmlinuz and initamfs to the root directory, so the best way is to remove
them from the root directory.

You may alter /etc/kernel-img.conf however you wish.

The question is why on a default install with grub, which doesn't need
nor use the symlinks, are they still created. For most systems, they're
superfluous.
iustin, who also dislikes these and always needs to disable them

I agree they are not normally needed, but I just never got round to
changing the default.

Ben.

[Michael Stone]

Post by Iustin Pop

Post by Michael Stone

Post by kindusmith
In early Unix, boot and vmunix were both stored in the root directory as
programs, and boot was used to start vmunix. Debian inherited this for
compatibility, but the situation has changed a lot. Today, boot is
stored in the root directory as a directory, which already contains the
kernel files vmlinuz and initramfs. Therefore, it makes no sense to link
vmlinuz and initamfs to the root directory, so the best way is to remove
them from the root directory.

You may alter /etc/kernel-img.conf however you wish.

The question is why on a default install with grub, which doesn't need
nor use the symlinks, are they still created. For most systems, they're
superfluous.

I don't believe that actually was the question. In fact, I don't think
there was a question at all, merely a comment to which I added some
additional information.

If you wish to influence how things are done, try filing a bug on
linux-base asking for the defaults to change. I would guess that most
people that don't obsess over the results of ls / simply don't care.

[Iustin Pop]

Post by Iustin Pop

Post by Michael Stone

Post by kindusmith
In early Unix, boot and vmunix were both stored in the root directory as
programs, and boot was used to start vmunix. Debian inherited this for
compatibility, but the situation has changed a lot. Today, boot is
stored in the root directory as a directory, which already contains the
kernel files vmlinuz and initramfs. Therefore, it makes no sense to link
vmlinuz and initamfs to the root directory, so the best way is to remove
them from the root directory.

You may alter /etc/kernel-img.conf however you wish.

The question is why on a default install with grub, which doesn't need
nor use the symlinks, are they still created. For most systems, they're
superfluous.

I don't believe that actually was the question. In fact, I don't think there
was a question at all, merely a comment to which I added some additional
information.

Indeed. But even the comment, by itself, I think raises a question - why
do we (still) do this?

If you wish to influence how things are done, try filing a bug on linux-base
asking for the defaults to change. I would guess that most people that don't
obsess over the results of ls / simply don't care.

True :) But like the original poster, it does bother me, so I'll see if
there is a bug filled already. Thanks!

iustin

[Michael Stone]

Post by Iustin Pop
Indeed. But even the comment, by itself, I think raises a question - why
do we (still) do this?

Because there's very little incentive to change it.