Why the symlink to /boot/vmlinuz in root drectory??
 

In the root directory are a set of symlinks to the
kernel: /boot/vmlinuz-x.y.z and /boot/initrd.img-x.y.z.
1. What is the purpose of these symlinks?
2. Are they really necessary?
Other distros don't have them.

SYSTEM INFO:
Distro is Debian 9 "Stretch"; Boot loader is GRUB2;
BIOS is dual-personality set to "Legacy" (UEFI disabled).
Bootable root partition is sda1. (I suspect MBR,
but I'm not sure of this). There are other bootable hard disks
installed (sdb); holds old distro, not mounted on boot-up.

Thanks in advance.
Dynosaw
--

You can safely remove these symlinks.

The usual purpose is to provide a default boot - and the image used is then chosen via the redirected link.

But they aren't needed.

Opensuse does this too. They're not really necessary of course but if you get stuck in a grub command line boot and can't remember the full kernel version you can get booted with just the symlinks. And they don't take up any disk space.

I have done this very thing with multibooting

Thank you, everybody, for your quick responses.
Dynosaw

In addition to simplifying working with a grub prompt, they're especially useful if multibooting. They're easily used in configuring a custom master bootloader menu that does not need to be updated every time a kernel is updated. I've been doing this for over a decade.

I like the sound of this but you would have to update each symlink every time. Does this work out quicker?

A master bootloader is not touched by any of the installed systems, so its menu is static until changed by the admin. Thus each vmlinuz and initrd in its menu stanzas don't need to be changed when a new kernel is installed. Only the OS with a new kernel needs changing, which some, like openSUSE, do automatically.

The concept can be applied rather simply on UEFI systems via a custom.cfg managed by the admin, and a modification of /etc/grub.d/ changing (mv) 41-custom to 07-custom, which moves the admin's custom menu to live at the top of the boot menu.

I see now. I use a separate /boot with all entries from 3 partitions so that wouldn't work for me. I'll just have to continue editing grub.cfg. I use 90_persistent on my main system (opensuse 15) and remove x from all other grub.d entries. I'm not sure that the 90_persistent grub entry is available on many other distros.

You can add more symlinks, eg vmlinuz-slackware, vmlinuz-suse...
I think the point is no need to update bootloader config after a kernel update, just update symlink

That's why I was interested but I think it's just as quick to do grub.cfg edit once I started to think it through.

Except for a few, most distros auto run update-grub or something similar during updates for new kernels, So I create a custom menu for each partition using the grub configfile= to boot other distros with there own grub.cfg in a custom file before the osprober file in /etc/grub.d

I too use a "separate boot". However, it is never mounted to /boot. It's used only for booting, not for providing a home for kernels and initrds, which continue to live on their respective / partitions in their /boot directories. The symlinks live in those locations, while the boot control primary partition houses the mostly static boot menu that either loads kernels and initrds via symlinks, chainloads to the bootloaders on the respective filesystems, or uses the configfiles on the various installations. The only useful symlink renaming would be facilitating previous kernel versions in the master bootloader menu. My convention where desired is cp'ing or mv'ing existing symlinks immediately prior to kernel installation: vmlinuz-prv>vmlinuz-prv2; vmlinuz>vmlinuz-prv; initrd-prv>initrd-prv2; initrd>initrd-prv; etc..

Thanks everybody for a very interesting
and useful discussion.
I would like to close this thread out from
side.
Again thanks
Dynosaw
--