Hi guys. Over the last couple of days I've been trying to get to grips with, and understand, the concepts and processes of booting Slackware64 using the UEFI method. Some things are not making sense and I wondered if someone better informed could enlighten me.

The first puzzle I have relates to Slackware64-current 'setup'. I'm installing on a Samsung 850 EVO SSD [250GB] which is my boot/root device. The process generally goes as smooth as silk until the point where 'efibootmgr' is writing a boot menu entry and it's at that point which produces an error - [ https://imgur.com/v6IiTly - see this screenshot ] - which results in no boot menu entry being written; and consequently on rebooting after 'setup' all I get is a, hex-dump formatted, half-filled screen of number 9's. However, I did find a way to circumvent this error - I've discovered that if I wipe the drive's superblock before running Slackware64-current 'setup' then there is no 'efibootmgr' error. First I thought it was just the EFI partition that needed wiping but after a few hours of testing I found that it was actually the superblock. My question here is; is it normal and/or expected procedure to completely wipe the drive [a.k.a. 'dd if=/dev/zero of=/dev/sdX' fashion] before running Slackware64-current 'setup' if you're planning on booting with UEFI?

Another puzzle I have relates to the persistent naming of devices. Whenever I add a drive to my system [which I do on a regular basis] it throws the known device ID list out of the window and the hardware seems to enjoy making up its own. So, I thought persistent naming was the way to go. However, after configuring the system so that partitions would remain the same "ID" across the board, it makes no difference and, when an additional drive is connected, the device IDs change the same as before. I'm using PARTUUID for this purpose. I have a SSD boot/root [/dev/sdb] and 2x 2TB HDD drives [/dev/sda and /dev/sdc] connected to the system. Let me show you my setup and config outputs.

So, I get the PARTUUID from 'blkid' command output.

Then I use the correct PARTUUID in /etc/fstab to identify my partitions.

In elilo.conf I've specified 'root=' using the correct PARTUUID for /dev/sdb4.

With all the above in place, if I connect another SATA storage drive to the system then this setup is not relevant and the new drive becomes /dev/sdb, the current /dev/sdb becomes /dev/sdc, /dev/sdc becomes /dev/sdd, and so forth. I have found it easier to boot with the Slackware DVD or USB-boot and just work from there, but it's not ideal doing this each time. My question is; what am I doing wrong, or not doing at all, which is still causing this device ID to change?

The last question I have relates to 'eliloconfig'. Having set the PARTUUID of the devices in /etc/fstab and /boot/efi/EFI/Slackware/elilo.conf I have read on Slackdocs and elsewhere on the Internet that one should run 'eliloconfig' after making any changes - as it is with 'lilo' under the same conditions. However, when I do, I find that 'root=PARTUUID=7fdc1b32-70e8-42eb-a3a0-b24851c28fa8' in my elilo.conf file has been replaced with an append of 'root=/dev/sdb4', Which is the correct device ID but I would expect it to be identified by PARTUUID instead:

So I looked in the /usr/sbin/eliloconfig file to see what it was doing and I found the following code [line 60(ish)]:

So, ${ROOT_DEVICE} has grepped '/' from the output of the 'mount' command. When I view the output of 'mount' is tells me:

My final question(s); it's obvious 'eliloconfig' is programmed to append 'root=' with the /dev/sdX of '/' but, can I not use 'eliloconfig' at all and retain the PARTUUID settings in my /boot/efi/EFI/Slackware/elilo.conf file which I set manually? More importantly, why is the persistent naming not working when I have done all of the above? What am I missing?

[EDIT] I haven't touched /boot/efi/EFI/Slackware/elilo.efi but I'd guess that it has a lot to do with this.

[EDIT2] I forgot to mention - I made sure the system is booting in UEFI mode...

Thanks for your interest and any advice on this issue.

this is well worth a read: http://slackware.uk/slackware/slackw...EADME_UEFI.TXT

I fairly recently got a HP laptop that had windows 10 on it.
I made a mistake of wiping of the EFI partition.
Luckily when i started installing current using an iso from Alien Bob it detected it and told me to drop out and re-install it using a tool via command line (can't remember what it was)

When i got to bootloader stage it was a little confusing and went for (belt and braces) install lilo to
mbr and then got another elio option.


my elio.conf is: chooser=simple
delay=1
timeout=1
# what it was)
image=vmlinuz
label=vmlinuz
initrd=initrd.gz
read-only
append="root=/dev/sda3 vga=normal ro"


my partitions :

Device Start End Sectors Size Type
/dev/sda1 2048 206847 204800 100M EFI System
/dev/sda2 206848 8595455 8388608 4G Linux swap
/dev/sda3 8595456 122142686 113547231 54.1G Linux filesystem



A couple of elements helped me; slackware will boot using efi but you have to set bios to disable secure boot and use legacy boot.

I don't really bother editing and found i don't need to interfere . my next approach on installing slackware on any new pc will be to set up efi partition of 100mb type EF00, swap and then main partition for install of ext4. if I get another pc with efi already there I will just leave it; anything that needs to be over written should be during the install

when you install slackware it should just be a case of the install recognizing the partitions and you basically agreeing with it.


if you do any editing to elio.conf and then run eliloconf i'm pretty sure its just going to over write your edits. I think with any superblock issue its probably a case of making sure hd is fixed of issues before installing

first off, are you absolutely sure that this drive in question has 'gpt' partition table?
having to wipe that little bit on the front of the hdd suggests it is a msdos partition table.

if that drive comes up dos, using gparted (for one) select Device-> new partition table -> (drop down list) gpt : check button

this will wipe your entire drive, so if you have anything on it that you want to keep make sure you back it up somewhere else before you proceed with this operation.

then on installing slack, when you get to the log in, login root, then use fdisk, or cfdisk to partition out your drive you can create your efi, / (root) /home , swap (if you want one) and so on and so forth in that step before moving onto the install part.

1 members found this post helpful.

The libefivar error looks like something wasn't installed, was this a full install of A, AP and L series? I wonder if efibootmgr runs chrooted in /mnt.

Did you get efibootmgr to list the boot entries, maybe there's some junk getting inexplicably written in there, I've seen that myself. You may want to try deleting all the entries one by one (the -B option) and then trying again with no boot entries (assuming you don't need to boot other OSes with the same motherboard).

I think there is a bit of work to do on Slackware setup to deal more kindly with edge cases for EFI. Slackware's had a couple of decades to iron out most LILO/Bios issues but EFI is a complicated beast, and will require complicated setup scripting to deal with it.

1 members found this post helpful.

Thanks for the reply. For GPT disks I use 'cgdisk' - not 'cfdisk' - to create all partitions. 'cfdisk' is for MBR and cannot create EFI partitions and I am really not sure about the rest which is why I stick with 'cgdisk'.

In answer to your query:

I also read Tim Miller's post about disabling all the legacy and CSM stuff in BIOS which I did before installing. The thing that made the difference with the 'libefivar' error was whether the SSD superblock had been wiped or not. Everything else hardware-wise and in 'setup' remained the same.

I have Slackware64-current installed, booting with UEFI, and running like a dream now. However, when i connect another SATA storage drive the device IDs will swap places as per usual so persistent naming isn't doing much for me and I'm trying to understand why. I really don't need (or want to) go over re-installing Slackware because that's a waste of your time. I'm past that point.

Note: You can create EFI partitions with MBR and they work fine except for one small issue with setup.
https://www.linuxquestions.org/quest...391/page2.html

See Didier's patch in that thread which may have made it into -current by now, I'd have to check.

FYI: I have an MSI motherboard and the same Samsung 850 256GB drive. I exclusively use UEFI mode only, no secure boot and Slackware current booted fine from this set up using elilo, BUT, I did have to copy an efi file (name escapes me) in order to boot. My point is that legacy mode for me was not enabled and the system booted fine. This probably varies depending on the motherboard I am guessing since it appears UEFI, although a standard, is anything but...

Thanks for your advice.

No. I didn't mess about with 'efibootmgr' much apart from seeing what the script code did with ROOT_DEVICE variable. Initially when I was having issues removing the old /boot partition I used 'dd' to wipe the drive and after doing that Slackware64-current installed perfectly without a hitch. I did that a second time yesterday which resulted in the same flawless installation, as expected. I found that if I didn't wipe the SSD superblock prior to running 'setup' then the 'libefivar' issue appeared during installation. I will make a note and next time use the -B option. However, it may be quite some time before that happens again.

I can certainly live with the fact that Slackware64 may not yet be able to deal with EFI in all areas but if that is the case then I really am wasting everybody's time here. Thanks again·

yes it can, I use cfdisk to do this on my installs on GPT disks.
the disk HAS to be gpt in order to see that selection under 'type'

Hi thanks for your reply.

My board is an ASRock Q1900-ITX and I have enabled everything it will allow to to enable for UEFI [in my case it's just the legacy USB turned off and UEFI mode turned on instead] and disabled all the CSM entries completely. Secure boot is certainly disabled.

I know UEFI has been around for some time and because my system stated it was UEFI enabled I perhaps ignorantly assumed it wouldn't be a problem installing Slackware64 to boot with it instead of MBR. Don't get me wrong, everything on the Slackware64 system works just great! I'm simply trying to get my head around why so many strange things are happening with UEFI, and such, along the way.

Then I bow to your better knowledge. I got my information from 'man cgdisk' so accept my apologies if it's incorrect: "The cgdisk program employs a user interface similar to that of Linux's cfdisk, but cgdisk modifies GPT partitions."

Yes, this was very much my way of thinking when I was learning about EFI. Bt for a classic BIOS, your boot depends on:

- CMOS Boot device options, saved by the BIOS to CMOS RAM.
- MBR content (which indirectly determines image location)

FOR modern EFI firmware your boot depends on:
- CMOS Boot device options, saved by the firmware interface to CMOS RAM.
- MBR content for any 'legacy' behaviour, exact nature of which seems to depend on what the firmware manufacturer dreamed up
- CMOS boot entries, saved by efibootmgr to CMOS RAM, and completely inaccessible to the firmware user interface (at least for the EFI firmware I've used).

So in the past dd if=/dev/zero of=/dev/sda bs=512 count=1 was the answer to most of your problems. In EFI land, you may need to in addition delete the boot entries, which can only be done using the efibootmgr utility. So I think setup in Slackware probably wants to show the user what's already there and/or validate it instead of the current 'would you like a boot entry' question so the user can make an informed decision, perhaps they'd like to delete any stale boot entries at this stage.

no big deal, now you know you got options.

How old is that board?

I have a older laptop that says UEFI in BIOS but that is for the we're just getting started with UEFI and it is badly supported.

it will not even use efibootmanager, I have to do too much fanagging on it to get UEFI to work on that one so I just leave it to MBR boot.

Thanks for the heads-up. If 'cgdisk' is more than capable of handling GPT partitions without any issues [which is THE reason why I am using it] then there's really no need to make work for myself by hacking and patching. I have come across enough niggles as it is with UEFI without wanting to add to them.

Yes absolutely and there are other reasons why you want to use GPT, I just wanted to clear up a common misconception, more for others reading than yourself.