Ok one other thing I noted with your refind.conf (and this could very well be the issue!)

The Options line i.e. options "ro root=UUID=..." MUST precede your initrd EFI/Slackware/initrd.gz line!
I found this out by fiddling with my menuentry sections. They too didn't work until I revised this order. Look carefully at the example in the doc page for Ubuntu 16.04. That is the required order for the menuentry section.

The doc page should be revised to reflect this.

I can't tell you how to get refind working but I can help you with Clover EFI. I'm multi booting Gparted Live + Clonezilla Live + Win 7 + Slackware 14.2.
https://www.linuxquestions.org/quest...re-4175661604/

No. The UEFI specification does allow to use a DOS partition table to host the ESP (EFI System Partition). That's what I use.

Well, I didn't know that! You learn all the time, don't you. Does that mean that a UEFI can boot in its native mode from a DOS disk? Because I thought that was impossible.

@wirelessmc. I've revised the order. We'll see if that does it.

The UEFI specification states:

To sum it up, in case of a DOS partition table (associated with a legacy MBR, not a protective MBR as found in a GPT), a partition that with an OSType of value 0xEF (as displayed for instance by lsblk in its PARTTYPE field) and includes a FAT file system should be handled by OS loader and the boot manager as an UEFI system partition.

Wow! Thank you for sharing this Didier Spaier!

Just like hazel I was under the impression that the EFI partition had to be of type GPT. One of the great thing about LinuxQuestions.org is you are constantly learning - provided you are visiting it :-)

Just a note: it's not the partition that's GPT, it's the disk label. The partition has to be of the type EFI system partition and formatted as vfat.

Well, FAT 12, FAT16 and FAT 32 are all allowed.

Practically, the command mkfs.fat is OK, as "man mkfs.fat" says:

So I've been experimenting. Refind's failure to boot Slack is definitely due to not finding the initrd, although I have now put this at the end of the stanza as instructed. I tried LFS instead as that doesn't need an initrd, but that hangs for some reason. However, I can chainload elilo.

So far I can only get refind to come up by making it the one-off "boot next". I tried to force it by deactivating elilo using "efibootmgr -b 5 -A" and rebooting, but I still got elilo! And when I checked, it was active again. This uefi definitely carries out its own edits behind my back!

The next step will be to remove the elilo entry. Of course, this might stop the system from booting at all; if that happens, I will have to boot from SystemRescueCD, chroot and run eliloconfig to reinstall it.

I'll try that tomorrow; it's not a thing you want to do when you're tired.

I found something in the Lenovo Forum that might be relevant. Someone installed Ubuntu on a Lenovo, which of course installed GRUB. Then he tried to switch to refind and couldn't. The machine would only boot grub. It seems that the first non-Windows bootloader installed is somehow locked in. In the end he deleted grub and renamed refind grubx64.efi. Then it worked. I may end up having to do something similar.

Could it be your system is similar to my HP where the only way to change the default boot file/order is from the bios setup.

Yes, that's also true as I discovered by trial and error. But my current problem is that even when you change the boot order inside the uefi, it isn't honoured at boot time.

As soon as one problem is solved, another rears its head! I discovered why the initrd wasn't being picked up. It was entirely my fault; I used a volume statement in my stanza because the examples used it, but it caused the initrd to be looked for on the wrong partition (in fact on the root partition where there is no EFI directory and therefore no path from it to anything useful).

Actually you only need this parameter to boot GRUB, because GRUB uses modules and a configuration file that it needs to have access to. A kernel doesn't need access to anything on the hard drive until it's finished booting to its initrd. But if you do use it, all your paths will be assumed to start from the root of that partition.

So now, the initrd name is printed on the screen and presumably gets loaded. But then the system hangs, as it does also with LFS (which has a custom kernel and doesn't use an initrd). I'm really wondering if all this is worthwhile but I hate to be defeated.

In the mean time, I have discovered more dastardly behaviour from the uefi chip. There are two entries for PXE boots in the menu, one for IPV4 and one for IPV6. I removed them as I have no use for them. I don't have a PXE server. But the next boot, there they were back again!

on my system, at the bios screen where I change the boot order I have to hit the f10(save and exit) for the boot order change to take effect. Save and exit at the normal bios exit screen doesn't save the boot order change.

1 members found this post helpful.