Thanks for all this. You've pretty much described what I did with different issues involved. I did a full (longggggggggggg) 'smartctl' check of the SSD before trying to understand why the 'libefivar' error was appearing because I thought the same - that the drive may have faults. However, it came back 100% clean with no errors.

That's not quite true. You can always go into your UEFI at early boot time and configure it by hand, just like you would with a BIOS, only it's a pain in the neck. efibootmgr is supposed to protect you from that. But some UEFIs rearrange the efibootmgr settings behind your back as Rod Smith points out in his UEFI/rEFInd book. And the UEFI on my Lenovo Thinkstation apparently allows the preferred boot option to be changed once but never again!

That appears logical. However not much I have experienced regarding UEFI is that logical. Thanks for sharing info - I am aware of the benefits of using GPT partitions which is why I chose that route when replacing the HDDs on my Slackbox. It's just a shame I can't get the persistent naming to work because it seems that I will have to endure my devices exchanging IDs whenever I connect a new drive via SATA. Which is damned annoying!

You have about five different ways of specifying a partition these days.

1) Device names, optionally with a udev rule to keep them constant.
2) Filesystem UUIDs.
3) Your own labels, set with e2label.
4) GPT partition IDs (GUIDs).
5) GPT labels.

Don't any of these work for you?

I've only tried PARTUUID because I don't need to build an initrd in order to implement it, or so I read on the Internet. I use 'cgdisk' [Name] to change the LABEL on my GPT partitions.

So, persistent naming won't prevent /dev/sda from becoming /dev/sdc when different devices are plugged in. But when persistent naming is used in your fstab, it will make sure those drives are mounted in the correct location, regardless of whether they're /dev/sdb3 or /dev/sdf3

Now, your fstab looks fine, but I think part of your problem with persistent naming is your initrd. You put the root option in your stanza on your elilo.conf, but that is overridden by the root option that is specified when making your initrd. So, when using an initrd, the root= option in your stanza is ignored.

If you run the /usr/share/mkinitrd/mkinitrd_command_generator.sh command, it will spit out a long command. What you want to adjust is the -r option. You'll want to change the -r /dev/sdb4 to -r "PARTUUID=7fdc1b32-70e8-42eb-a3a0-b24851c28fa8" and keep the rest of the command the same (unless you want to change the name of the output file at the end). Then make sure that initrd is copied to /boot/efi/EFI/Slackware/ and is referenced properly in your elilo.conf.

There is no need to rerun eliloconfig unless you want it to automatically copy your kernel and initrd from /boot to the correct location on your EFI partition and reset your elilo.conf. EFI is different than the older systems like lilo. lilo was required to be run after kernel updates or lilo.conf changes because it needed to let the BIOS know the direct location of those files, since the BIOS doesn't understand filesystems or partitions. It just says start booting this kernel that starts at this location on the harddrive. UEFI firmware is notified where the EFI stub is located (in a default Slackware system, it is /boot/efi/EFI/Slackware/elilo.efi) and then that is able to figure out everything from there, so as long as the efi stub doesn't change location you never need to update the UEFI firmware like you did with lilo.

1 members found this post helpful.

Can't thank you enough for this very astute reply. It's the precise information and answers that I was looking (and asking) for... and then some.

At some point in the very near future I will endevour to follow your advice and build an initrd. I have already read about this somewhere on the Internet (Slackdocs I think) but the guide was geared for 'lilo'. Now I know the principle is much the same I shall pursue it. Thanks very much!

You posted this in another thread, and I wondered why I don't see UEFI shell as boot option, but I've come to the conclusion there's something wrong with my firmware. Just as some people get forcibly dumped into UEFI shell when they don't want to, I think it's the other way round for me, it's simply not there as an option.

EFI shell is a separate program and it's not always there by default. I don't have it on my machine either. But you can download it and put it on the EFI system partition, then create an option to boot into it.

1 members found this post helpful.

Looks to me like you're using the wrong elements from blkid output.

For your own use, humanly memorable yet sufficiently unique volume labels are much more practical whether using MBR or UEFI tables. Try creating volume labels, then e.g. this for fstab:and in /boot/efi/EFI/Slackware/elilo.conf

Slack must be different from other distros. In those I use, the root= contained in the initrd is a fallback which is overridden if the kernel cmdline contains one. AFAICT, there is no way for the grub configfile generator to not include a root= parameter, which makes the fallback in the initrd no more than bloat.

Thanks for the advice, but...

If I should ever connect a drive that has the same LABEL as an existing drive that's going to cause BIG trouble. That may be a possibility for me. Safer with PARTUUID I think. When I sort out an initrd, as bassmadrigal advised, that will be the telling point in all of this.

[OT]A basic grub setup is way easier.[/OT]

The possibility is a big if here. Keyword was "sufficiently unique". I include the last 3 or 4 characters of the HD or SSD serial number as well as what I typed. Sometimes I leave out the P, sometimes I put the P# first, sometimes last, so uniqueness is quite sufficient.

If and when there is a conflict, you'll see so in a boot message, dmesg or journal. I've tested. IIRC mounts will be RO or fail entirely. The "trouble" need be no more than a temporary nuisance, until the duplication can be corrected.

There is nothing wrong with using PARTUUID. Labels can be easier for some, but like Exaga, I use similar or the same labels for hard drives when I replace them. I like the look better when I'm seeing it in file managers. And using UUID or PARTUUID is a one time configuration option I use. I don't need to reference them all the time, so it really doesn't matter which one I use, but using UUIDs in my case prevent issues if I happen to plug in an older drive that has the same label as its replacement.

Maybe it depends on the bootloader. I remember the root= line not being honored when I was using an initrd with lilo and never really tried it any other time. Maybe it doesn't apply on other bootloaders or I was doing something wrong.

1 members found this post helpful.