Did you know that the humans have a tail too? It's vestigial and usually it's hidden under skin (in the place you expect to be), but the anthropologists says that long time ago our tail was long and a very useful thing to have while our ancestors still lived above trees.

Same's with the huge kernels. Long time ago, probably they was a useful thing to have in your Slackware, but today they are just a vestigial tail. Nothing interesting there.

1 members found this post helpful.

Give it a break, man!

You're not forced to use Huge, but for those who do, it's a nice service we have it...


Jan, huge fan

1 members found this post helpful.

I dunno, for a regular user it seems equally fine to just use /dev/sdaX. Might get messed up if you boot from USB sticks or such, but should work in general.

NVME is great for this actually
Personally I boot /dev/nvmexyz for my custom kernel without initrd.

I confirm what LuckyCyborg said: the UUID (or filesystem uuid) is stored in the file system thus not available to the kernel at boot time.

So if you insist to use a huge kernel with no initrd you have two solutions:

1. Name the partition like /dev/<something> (only if the order of drives will never change and the drive is not removable).
2. Name the partition by partuuid (or partition uuid) as suggested by Labinnah.

To use the naming by partuuid you can just set in /etc/default/grub:
GRUB_DISABLE_LINUX_UUID="true"
GRUB_DISABLE_LINUX_PARTUUID="false"
and re-generate /boot/grub/grub.cfg using grub-mkconfig or update-grub

This being said I also agree with LuckyCyborg on this: there is zero benefit using a huge kernel instead of a generic one.

1 members found this post helpful.

I use LILO. I have entries for both the generic kernel and the huge kernel. Defaults to generic, but huge is there for a manual choice - like when I forget to make a new initrd after a kernel upgrade.

What can I say. I like backups, and having choices.

Wrong. Using UUIDs requires the use of an initrd. It doesn't matter if you boot the generic or huge kernel itself. It is possible you might run into issues booting the huge with a initrd, but I've personally never ran into them.

As you're well aware, "generic" and "huge" aren't kernel terms, but Slackware terms. An initrd can load a generic or huge kernel. I purposefully build in my ext4 module while using a "generic" config, just out of sheer laziness so I don't have to build an initrd (I'm using a single NVMe drive on my system and that happens to contain my EFI partition, so I have no current need for UUIDs).

As pointed out elsewhere, you can always use PARTUUIDs without needing an initrd.

This is totally wrong too. You can absolutely "mess" with a bootloader within another distro, as long as you understand how the bootloaders work and how kernels need to be referenced. I am *very* familiar with that with lilo, so I would have no problems getting multiple linux systems booting while editing /etc/lilo.conf in a single distro. However, I don't have that knowledge on how grub works, so I wouldn't risk it without a lot of work.

I've only ever used chainloading with Windows. It's not hard with a little bit of research to get multiple distros to boot using the same bootloader.

1 members found this post helpful.

It might be easier than you think. Ubuntu provides /boot symlinks to the kernel and initrd, so it should be possible to keep a static GRUB configuration on Slackware that points to symlinks only.

Yes, that won't be the hard part. I got into the habit of maintaining similar symlinks under Slackware, so I generally don't have to touch my GRUB configuration unless and until I add or remove or replace any systems.

I'm just not sure how easy or hard it is to add a bootloader to a UEFI system, or to remove one from it, without messing up the boot process.

Ideally, I would end up with two installed GRUB bootloaders: a "stable" one and an "experimental" one that I can play with without messing up the "stable" one. Under Legacy BIOS, I installed the "stable" GRUB as my primary bootloader onto the MBR, and I used chainloading to arrive at the "experimental" one. I have no idea, as of yet, how I could do such a thing under UEFI.

I've done switching before, but it's been awhile. Don't recall it being particularly complicated.

As for keeping two instances at the same time, giving them different labels at grub-install time might do the trick.

This is what I do on my slackware systems. The only thing I do is run mkinitrd with kernel upgrades.