If you use elilo, only run eliloconfig once to register it. eliloconfig copies the initrd.gz and the vmlinunz to efi/EFI/Slackware. Occasionally eliloconfig fails to do an update properly and messes up the efibootmgr, so it is best to just copy the new initrd.gz and vmlinuz to each kernel update.

If you were using the huge kernel with no initrd previously, then you shouldn't need an initrd with it now.

For me, once I got my head around how UEFI works, it was much easier to understand.

When you power-on your system, the built-in UEFI system in your box looks for a FAT partition, as this is all it can read.
When it finds one, it looks for an efi binary that it can run. In the case of elilo, this is the "elilo.efi" binary.
Then it simply runs that and its job is over.

So now "elilo.efi" is in charge. It looks for its config file "elilo.conf" in the same directory.
Here is my simple elilo.conf:
The first "image=..." entry is the default, and it waits for 2 seconds before booting it.

It is a good idea to keep an old kernel (along with its modules) as a backup in vmlinuz-old
To upgrade your kernel, all you do is copy the new huge kernel to "vmlinuz"

Here is what the whole directory looks like:
To upgrade the kernel, you just run
ps If you like the old lilo ways, you could add that to /root/.bashrc as an alias :-)

3 members found this post helpful.

OK, so the good news is that your process isn't going to be much different with eLILO.

After installing the new kernel packages using All you need to do is:

Boom. Job done.

As others have pointed out, you don't need an initrd if you're using the huge kernel, so don't worry about it.

Note: By default, the current Slackware installer will install the generic kernel and an initrd. Copying the huge kernel into its place might cause some error messages on the screen as the initrd tries to load. Those messages can safely be ignored, but if you want to stop them you can edit /boot/efi/EFI/Slackware/elilo.conf and comment out the initrd line.
LILO doesn't work with nvme drives.

4 members found this post helpful.

Actually, it can. There is some dependence on specific BIOS/UEFI firmware specifics but generally if the NVME drive is assigned in BIOS, it will boot from lilo. If a specific firmware doesn't boot, it isn't hard to use the MBR of a mechanical drive and "handoff" the process to NVME since very early on modern Linux kernels will see NVME just fine. I've done the latter for years on an older boxen whose firmware does not "see" NVME as an expected drive. I still use this machine with a mixture of mechanical and SSD drives, some of which boot from Legacy MBR lilo, and others as EFI with rEFInd.

1 members found this post helpful.

On some systems Elilo will hand back control to the computer firmwares boot manager to autoboot Windows when a dummy stanza is used. This works on my HP Elitedesk 800.


image=no_windows
label=Windows-10
read-only

1 members found this post helpful.

Au contraire!
It won't boot a f2fs partition, but it will boot a ext4 partition on SSD drives. I have a small ext4 partition set up as /boot, and / and /home are on F2FS partitions.

Well, sometimes the old fashion way is just better and easier. Using a /boot partition for example, not using an initrd, and configuring your own kernel for your machine. Not only does it compile ALOT faster if you get rid of all the stuff that is irrelevant to your hardware, but you can build in any "hard requirements" instead of having them as modules. For example encryption, if you want to use enrypted / or anything else you supposedly need an initrd for. Your boot will be faster without an initrd as well, and there will be less points of failure in the boot sequence.

And eh, I don't want to be that guy, but eh, Grub is quite an easy bootloader to handle most of the time. Perhaps it could ease your burden? Maybe read up on some basics of grub and give it a try?
In particular if you mess up grub, or something during boot, it's very easy to get it booting by editing the grub boot entries at boot if something is not quite right.

And ofcourse, always keep a working sequence in the bootloader alongside any new one, so you can boot the working one in case of any troubles with the new one(s).

Ps. initrd is a great tool for distribution of generic Kernels for a variety of users and hardware

AHA!! *THIS* seems to have 'clicked' for me for some reason and was pretty much what I needed to read I believe. It's always some little thing, seen or read in some way that is, sometimes minutely, different from all the others that are saying basically the same thing (I hope that all made sense!).

So, with elilo, if I get one of the 'security' e-mails about needing to 'upgrade' the kernel, I simply do the 'upgrade <kernel stuff>' like I've always done with lilo if I continue to use the huge kernel, and don't even need to do 'elilo' after? Is this correct?

WOOHOO! This and the post from Loomx I believe have done the trick to making things finally click together. I seem to be the worst case of needing *MANY* examples with certain subjects before one finally helps me understand what most others picked up the first instant, heh.

Thank you *ALL* for putting up with me and this seemingly never-ending dilemma I had and getting me the answer(s) I needed!

Yes. There's no /sbin/elilo program that you need to run to reconfigure ELILO as there is to reconfigure LILO. That's because LILO uses physical addresses and has to be reset to the addresses of the new kernel and initrd. ELILO uses the vfat filesystem to find these by name. If you change the name of the kernel, you'll need to edit that into elilo.conf but you won't need to run a special reconfiguration program afterwards. And if you use a constant name for all your kernels, you won't even need to do an edit. Just copy the new kernel to the esp, overwriting the old one (better make a safety copy first!), and you're good to go

I have a Slackware64-current (kernel 5.14.0) running with eLILO. After every kernel upgrade I am used to mkinitrd and then cp the initrd + vmlinuz* from /boot to /boot/efi/EFI/Slackware.

My elilo.conf, however, points to the huge-kernel, not the generic (vmlinuz being a symbolic link to vmlinuz-huge under /boot) - here is my elilo.conf:

Everything is working fine. Do I need initrd? Is it being used? Or the initrd should be used only in conjuntion with the generic kernel?

From the looks of it, I'd say that you're using the huge kernel and therefore don't need an initrd. You only need to use an initrd if your kernel doesn't have filesystem support built in (as per the generic kernel, which has no filesystem support built in at all).

If you want to be double-sure, then copy /boot/vmlinuz-huge to /boot/efi/EFI/Slackware/vmlinuz

I'm not 100% sure of what happens with the vmlinuz symlink, but the vmlinuz-huge one always points to the huge kernel. That's why I suggested it to FTIO above.

EDIT: If you're running the huge kernel and you see these types of messages on the screen:
It's because the initrd is trying to load modules which are built into the huge kernel. You can safely ignore these messages, but to stop them from appearing you can remove the initrd line from /boot/efi/EFI/Slackware/elilo.conf

3 members found this post helpful.

Thank you, rkelsen. I guess I am running huge-kernel. From dmesg I can read the messages you wrote, but without an error warning. See below:

A stock slackware install doesn't need an initrd with a huge kernel. However there are exceptions to this rule. If you use "root=UUID=<root partition uuid> instead of "root=/dev/<root-dev-partition> in the bootloader kernel options, yes an initrd is needed with the huge kernel. I have also seen on some hardware setups that an initrd is needed with the huge kernel, but these setups are rare and usually require the generic kernel with an initrd.

3 members found this post helpful.

Yes, you're running the huge kernel. The errors only appear on screen while the system is booting, but the lines in your dmesg output show that the initrd is trying to load. It's no big deal, you can ignore it.

1 members found this post helpful.