Using Lilo with GPT and PartUUID

[FastTurtle]

Just found this on a Slackware Thread about how to get Lilo to work with a PARTUUID

[eccerr0r]

TBH I'm not sure why one would want to use lilo or elilo on an uefi system. Former doesn't support EFI, latter hasn't had patches in almost a decade.

To use lilo on a modern machine, the firmware must have CSM or MBR BIOS compatibility mode. EFI will have nothing of legacy boot sectors.

This is not to say you can't install lilo on a GPT disk, but the firmware of the computer still needs to do legacy boot.

TBH either use grub or refind, or don't use a bootloader at all - the point of lilo is that MBR firmware does not understand filesystems and lilo bridged that gap. EFI however does understand one filesystem (ESP/FAT) and can load boot file images directly. Using EFI is much safer as you won't risk writing sectors in funny places (which is what lilo does in order to be able to boot) so less chance of corruption, not to mention you can't move files around without upsetting lilo.

There's the other problem of EFI firmware on expansion cards knowing that it needs to also do legacy boot, which may not exist...

I ditched lilo a long long time ago as grub brought boot features of OpenFirmware to PCs though without the safety of unmodifible firmware. With UEFI I also question the need of grub, alas having a consistent boot interface among all my PCs is helpful...
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

[Chiitoo]

When grub "legacy" was going away, and after having tried grub-2... I tried LILO and I like that it is simple and works.

Some years ago I did try the EFI way too... when I last moved my trusty install to another drive, and didn't get it to work on the first try, so I went back to the way I know works (with GPT included).

So far have not seen an advantage for me with the other methods, though I'm likely to be ignorant to them, but for the time being I'll probably be sticking with LILO at least for some more time to come.
_________________
Kindest of regardses.

[ian.au]

I guess the only reason to use a bootloader is if you need dualboot or multiboot capability. I don't need this capability generally, so I don't bother with one at all for EFI.

I use an EFI stub, and manually copy the new bzImage into /boot/EFI/Gentoo/bzImage.efi

This way I don't have to bother with rEFInd each time I build a kernel, set it once to bzImage and it will boot that file once copied into place.

I rename the outgoing kernel as a backup bzImage-X.X.XX.bak before I copy the new one over, just in case I cook a lemon and have to revert. I had to use it just once since 2020 (by neglecting to copy the correct .config over) so best to keep a boot stick handy JIC.

[eccerr0r]

Also preboot config/recovery. Having grub to tell init to start in single user mode is sometimes helpful, having a static boot environment makes that kind of tough. This sort of is the reason why I went against efistub/direct efi boot.
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

[ian.au]

I'm pretty sure that's possible, but I'm not hosting anything that requires me to boot into single user mode these days, so I haven't bothered.

It requires setting up a separate appropriately configured entry with efibootmgr and you can reach the menu by hitting 'e' during boot IIRC

I should also say that I could and should easily mv bzImage.efi to backup.efi instead of making a backup as above. Then with an additional entry in the boot menu with efibootmgr - that would be fine as a fallback.

It's on my to do list, but with a fair chunk of tasks in front of it... it would have happened by now if I'd had to chroot in a few times over the past few years. When I set this up I was pretty frgile on the whole thing, as my previous PC had a horribly broken uefi implementation - so I made this one as manual and simple as possible so I at least understood it.