I've just done a slackpkg upgrade-all. At the end it asks whether I want to run lilo. But because of EFI (and using ext4) I have to say "no" and do a bunch of stuff (creating initrd.gz and copying files etc).

I'm using a DELL XPS13 (9343). Now, I *think* I can get it to boot in "legacy mode" and I'm tempted to try it; I used to use lilo and was very happy with it. Then I used a Macbook Pro for a long time and was *forced* to use EFI.

Apart from Slackware I have a (mostly unused) Arch installation on this laptop.


Is there any reason I should use EFI instead of MBR?

No. But why not just run eliloconfig? It will take care of copying the kernel linked to by /boot/vmlinuz and /boot/initrd.gz if it exists to the EFI System Partition. Nothing to do manually. And if you use a huge kernel you don't need an initrd, so that's no more work than running lilo.

Well, eventually systems will likely stop supporting "legacy" mode for UEFI, so there will be no choice but to use EFI. However, we aren't there yet, and if you have the option, you're certainly welcome to use it.

On top of what Didier wrote, it is also not recommended by Pat to use slackpkg to upgrade kernels (even though it's enabled by default). If you check /etc/slackpkg/blacklist, it will show the following statement.

It is recommended to install them manually, most electing to run installpkg on the new kernels, regenerate initrd, edit their bootloader, then test the new kernel. Once you've verified the kernel works fine, you can remove your old kernel and adjust the bootloader accordingly. This leaves you with a known-good working kernel and a way to fall back to it if the new kernel doesn't work as it should.

Patrick Volkerding provides instructions in an email to the slackware-security mailing list whenever he makes a kernel upgrade for security reasons (which has been always the case for kernel upgrades of Slackware stable, as far as I remember), that can safely be followed in all cases, I think. For instance see the most recent email of this kind.

Like most other computer interfaces of the last 10 years or so the Unified Extensible Firmware Interface is a half-finished, bug-ridden heap of junk. I had nothing but trouble with it last year. If your setup is straightforward it's fine, but if you do anything like LVM and/or software RAID and/or Xen then forget about it. My advice is to use the legacy option as long as your hardware supports it.

That is what I am doing, I haven't even tried to boot EFI yet. I just use the "legacy" mode. When I install Slackware I load lilo into the root partition then boot to my Windows 10 partition and use EasyBCD to add Slackware the the windows boot loader and chainload lilo that way. Probably not the most elegant way of doing things but it works and I don't feel like messing with something that isn't broken.

Well, I have the old kernels and initrds in /boot/efi/EFI/Slackware and edit the elilo.conf there, so I could boot a previous configuration, if necessary.

... oh. I just checked. I only have a complete /lib/modules/4.4.38/ directory (and a mangled old 4.4.14).

Didier,

it's not so much the work, it's more that I'm inclined to agree with Gerard. UEFI is a horrible mess:

[rant deleted]

Those kernels would remain in place unless something with elilo removes them. The Slackware kernel packages will add kernels into the /boot/ directory, and if those packages are upgraded or removed, those kernels would also be removed. But, I believe eliloconfig just copies kernels and initrds out of the /boot/ directory into the /boot/efi/EFI/Slackware/ directory. Those are untracked by pkgtool, so they wouldn't be removed when the kernel is removed/upgraded.

As for your mangled /lib/modules/4.4.14/ directory, my first guess is that you compiled some custom kernel modules that were installed there. pkgtool will remove all the original files in the package, but it won't remove newly added ones. If there are new files in a directory, it would prevent that directory from being removed when the package is removed.

If you have properly configured your initrd, then it should "just work". There is no technical reason EFI should get in the way at all.
Not really. Granted, UEFI isn't very well documented, but this website has some good, clear information about it: http://www.rodsbooks.com/refind/

It's mostly a matter of understanding where to put things.

The one thing I dislike about EFI is that it uses the FAT filesystem, which makes it prone to damage. That said, it works fine with filesystems created with GNU tools.

As with everything else, Slackware's implementation of EFI support is probably the most sane available.

1 members found this post helpful.

To those who despise UEFI... Please read the current specification, then come back. See you next month. Or maybe, next year?

More seriously:

• UEFI is a specification. This in itself is a big progress as there is no BIOS specification instead. And the availability of this spec makes UEFI something very well documented.
• Not all implementations are fully compliant, and some include not specified features but that's mostly vendors' responsibility (old implementations by Apple come to mind).
• The specification contains some unclear statements that could lead to diverging interpretations. How can that be avoided in a document 2656 pages long? The Pascal specification in BNF probably contains less ambiguous statements, but it's certainly easier to specify a programming language from scratch than an interface that has to cope with a wide variety of contexts on both sides, notwithstanding the great job done by Niklaus Wirth.
• There are a lot more divergences in BIOS implementations. As an example, just 2 days ago H. Peter Anvin posted in the Syslinux mailing list:
  Quote:

  The bytes CD 18 (INT 18h) at the beginning of a boot sector is supposed to tell the BIOS that "this device isn't bootable, try the next one"; unfortunately not all BIOSes handle that correctly (although most recent ones do.)

  If someone knows something about BIOS, it's Peter.
• The layout of firmwares' boot menus vary widely among implementations, but that is explicitly out of the specification's scope.
• Usage of LVM or software RAID is not in the scope of the specification, as at time of finding the root device for instance, the firmware has already handed over the system to the OS.
• Needless to say, UEFI provides useful features not available in a BIOS implementation, like ability to modify the firmware's boot menu from the OS, not using a boot manager at all (as e.g. with an Linux EFI stub, that bundle a kernel and possibly an initramfs with a built-in command line in an EFI image, providing a live system in only one file), even upgrading the firmware itself from the OS.

My disk is not exceptionally large, and I have no need for so many partitions. I am going to postpone UEFI until I really need it.

The UEFI specification does not require the use of a GUID Partition Table anyway. It allows to continue using a Legacy Master Boot Record. On the other hand if you use LiLo you are in good hands: we know who is the official maintainer