What wear and tear? I've found EFI to be a bit easier since I don't need to ever worry about forgetting to run lilo after updating my kernel/initrd. I don't dual boot, so elilo has worked fine for me so far. If I needed to dual boot, I'd probably look into rEFInd or maybe grub (although, I've successfully steered clear of grub over the years, so I'd probably do that as a last resort or if it ended up becoming default in Slackware).

1 members found this post helpful.

I've only just come across to Slackware myself, and, I too, am/was stunned by the friendly assistance provided.

There are two basic ways, both command line.

For the basic system use, slackpkg

For the most everything else use, sbopkg ... ... .... which has to be downloaded and installed from as a tar from https://sbopkg.org/ (note sbopkg has a dependancy before it will install...but I can not remember what it is).

Of course if you want to know more I suggest you consult the relevant man page.

sbopkg does not have any dependencies as it is just shell scripts that use commands already in a full Slackware install.

You can download the Slackware package directory from their website.

Well there you go. I multiboot, never forget to run lilo (probably because I do it so often) and never have resorted to an initrd, though that last bit may possibly change if I take on encryption. Why would I choose to write and rewrite to nvram when instead I can do that on a device meant to be overwritten many times and in a human readable text file? What possible advantage is there? It is far easier to edit on a hard drive than in nvram.

The wear and tear was due to my learning first on an older system that apparently had early (and somewhat poor) EFI support. I wrote and rewrote on that box many times.

My first trial with just Slackware and elilo went without a hitch on my newest (Z77) box, but again to what advantage? In my case this was further complicated by my installing an NVME .m2 drive by virtue of a PCIe sled and apparently my bios can "see it" well enough to access it but shows no indication of it's existence in BIOS/UEFI Setup. I suspect a mismatch problem with either the sled or the nvme's boot rom, but that doesn't change the fact that ANY complications like any of these can make for multiple rewrites and yet again, for what?

FWIW I rewrote the NVME as MBR table and legacy boot, which still won't run directly because of some mismatch, possibly the one I've noted, but at least it will chainload perfectly.

Simply put I find MBR boot with editable text configuration files far simpler, more flexible, and more direct than EFI, but admittedly I can see how a single OpSys box would feel much simpler than the mess that exists with multiple systems, although in my case that would mean my shiny new NVME would still be in the cardboard shipping box until I get a newer mainboard.

I'm not understanding where these rewrites are coming from (unless it is just you playing around with the system trying to learn things -- rewrites are not needed once properly setup). I've never needed to run anything beyond my first efibootmgr command when I first setup elilo, which registered the efi stub location to the UEFI firmware. You never need to write that again unless you're changing where the efi stub is located (by default, elilo puts it in /boot/efi/EFI/Slackware/elilo.efi). After that you never need to do anything else with the nvram/UEFI firmware. When your kernel/initrd are updated, you make sure your conf file is correct and you're done.

I do think if you run eliloconfig, it will rerun the efibootmgr command to ensure things are registered with your motherboard, but that is easily avoidable. And there are alternatives to elilo that better support multiboot.

By no means am I saying lilo was difficult. It worked great for me over the years and it was a rare event if I forgot to run lilo after updating (and it was always easily fixable since I had my previous kernels available). I just find UEFI a bit easier than legacy and I found the transition to basically be effortless. About my only complaint is if you are moving systems, you need to re-register the efi stub with the new firmware (I had to do that once, but it was pretty easy) and elilo doesn't support the "addappend" option like lilo.

2 members found this post helpful.

I guess I was less than clear. I had zero problems installing EFI boot via elilo on a newer machine with an hdd install, which would have been great if it was a sole OpSys boxen and even that could be worked around by hitting the Boot Menu button and selecting an MBR drive.

My only point, especially for multiboot machines but even solo boxen, is that why? to what advantage? I see none. Now if it is actually impossible for GPT to have been built supporting something like MBR Boot, then I can see that some very few instances where someone needs to boot a partition in excess of 2TB, EFI is essential... but who needs that?

I'm still lost on the "wear and tear" of nvram unless it was trying to figure things out initially and needing to use efibootmgr several times.

As for benefits, I'm certainly not the best to speak on this. I haven't found any amazing benefits to use UEFI, just as I haven't found any amazing benefits to using legacy. Both have been simple and relatively problem free. I simply had used UEFI booting on my new at-the-time system, because I figured at some point legacy booting will probably stop being offered by motherboard makers and I might as well figure out this "new fangled thing". It was a simple transition for my use case and now all my machines are running UEFI booting with elilo.

I'm not here to tout that everyone should move to UEFI and that "it's the best thing since sliced bread", because it certainly isn't (although, some boot managers may make things much easier, but I haven't really looked into them). It is "about the same" to me as legacy booting, but at some point legacy booting will go away. I figured I'd rather have a say in when I make that transition rather than be forced into it because a new motherboard doesn't have legacy booting anymore.

I will say I do like GPT partitioning. I always hated extended partitions (and luckily have been able to avoid them for a LONG time). And the ability to have partitions larger than 2TB is a necessity for me since my only drives with less than 2TB are all NAND based and I have probably 5 or 6 HDDs (I lost count) that are all 4TB or larger (with the largest being 12TB).

elilo has grown on me with its simplicity, and I find it much easier and more streamlined than lilo in adding new kernels. I have 5 of the previous -current- kernels (in generic and huge) in elilo and managing them is a breeze. You will need to resize your EFI partition if you're going to have more than a handful kernels. The default 100MB just doesn't cut it.

1 members found this post helpful.

This.

Copy the Slackware installer onto your EFI partition, and you'll never need to burn a DVD again... just point it to the partition where you've mirrored the tree.

You're not the Lone Ranger on that one. I'm trying to figure it out too.

In total, I'd say that I've written to nvram fewer than 5 times in ~8 years of living with EFI. That's across several different computers, both physical and virtual machines. Sometimes you can't avoid it (eg: with proprietary laptops), but most of the time you can get away with renaming rEFInd and putting it into the default location (EFI/Boot/bootx64.efi). There's no writing to nvram at all in that situation... just reboot and there it is.

Once that's done, it'll automatically find and offer to boot any EFI bootloader you put into the EFI partition. For eLILO, you just need to ensure that the kernel you want to boot is listed in the config file. The *BSDs are even easier. Their efi bootloaders don't even need a config file.

I don't know how I can make it any clearer, and with apologies to OP since it has zero to do with Slackware, but older bios, incompatible boot rom, multiple operating systems, kernels without initrd all led to my writing 8 or more times in 2 days to nvram and this on a box for which I recently had to buy a new BIOS chip to replace one that went south over time. Additionally an even older Intel mobo I still use, a DP45SG, has a BIOS going bad that is unreplaceable since it is soldered in place, so maybe I'm a lil' gun-shy on BIOS/UEFI nvram chips these days.

Bottom line for me is still Cost vs/ Benefit. I see zero advantage and some cost. Admittedly rEFInd is pretty cool but I'd rather edit a clear text config on a hard drive any day.

How about not editing anything?

Maybe it's just that your experience is entirely different and simpler than mine, almost certainly due to hardware differences, but although I can see your side with my experience on my newer box with a recognized hard drive which the Slackware -Current Installer launched as EFI booted handled with extreme ease and worked right "out of the box", first shot, Done!

However I had to wrestle with a partially supported NVME drive trying to find a way to get it to work. That required LOTS of editing and ultimately showed me it cannot work as it exists on this box. So I was forced to drop back to MBR and hard drive located, human text file configs to get it to work. Apparently you didn't have such issues so I can kind of understand why you have no experiential frame of reference but I assure you it can exist when there are incompatibilities or only middling support for newer hardware. It is likely such problems will disappear when I get a newer motherboard this year and this could then become a non-issue. It is not for everyone with every hardware yet.

What in that process required you to write things multiple times? The only time you need to write to the nvram is when you tell the UEFI firmware where to find the EFI stub (for elilo, EFI/Slackware/elilo.efi on the EFI partition). The EFI stub and the nvram can stay unchanged no matter what kernel, initrd, or distro you decide to use. Those changes go to the bootloader's config file and any changes do not require a rewrite of the nvram. If you used the wrong efibootmgr commands or swapped between multiple boot managers, then that not a UEFI issue.

A simple efibootmgr command would be:

To break that down,

Once this command is run, you will never need to do it again on that computer unless you decide you want to switch to or add a different boot manager. You don't have to have the efi stub in "Slackware", you can name the folder and label whatever you want.

@ enorbet; one nice thing with UEFI is that you can edit the firmware's menu from the OS, as bassmadrigal just illustrated with efibootmgr. If you prefer a GUI for that, our friend George Vlahavas (Salix maintainer) provides one, cf. https://github.com/gapan/guefi. just type make && make install and you are all set.

More fun: Windows 10 also have a GUI that does the same thing, so now you say from Windows "next time I boot this machine, I want to start Slackware"

PS One more benefit of UEFI is that you can now safely install Windows and Slackware on the same drive without risking that some Windows update prevents Slackware to boot as each have its own OS loader in the ESP.

Cost? A bit of learning. I think that no one is too old to learn. As an example I communicate on a mailing list with a guy who plans to learn Python, born in 1936, blind and deaf (fortunately he could learn Braille before becoming deaf, so he has no issue communicating). He uses Linux (Debian for now If I remember well, nobody's perfect).