This doesn't apply to EFI booting.

I would not know about whether EFI does not require a boot flag.

All I know is that my system requires an EFI partition, yet, apparently Slackware 14.2, ignores the EFI partition. So until I put a boot flag in place my system would not boot without the assistance of a usb.

I put the suggestion there because I figured it is worth trying.

Since I have been recently playing rather hard with learning both EFI boot and SSDs and in fact have the 1TB version of the superb EVO drive I have some questions and observations that may help you.

How is your EVO physically attached to your motherboard? Does your Motherboard have an .M2 slot or are you using a sled? If you're using a sled are you connecting via PCIe or through SATA?

The above questions can have crucial answers especially in my experience with sleds but to not waste time I'll ask the last question even though it may depend on those of the first set.

If your OpSys install is completely new did you boot the install media via UEFI? or from MBR? They will boot both ways and things go MUCH better and way simpler if you boot the installer in EFI mode. I suspect you didn't do this or you would have seen the elilo option and not installed MBR era LILO. You might consider reinstalling via EFI boot selected from your BIOS/UEFI Boot Order Menu.

You system is not the OP's system. What you did looks like a workaround because you didn't succeed booting in EFI mode, so probably you use LILO instead of eLILO to boot. But the OP wants to boot in EFI mode. As an aside even when using lilo, a boot flag on the root partition is only needed if you install LILO on the root partition, not on the MBR.

In EFI mode you install the OS loader in an EFI system partition, that does not need a boot flag and using it won't help.

try this again
for any warning messages, then q to quit.

As has already been suggested, you may have to use grub as the bootloader.

I have a look at web page of laptop provider. I am litlle terrified. I am sorry to say this but I would never buy their laptops. What essentially is systemd-boot? Here on this picture https://support.system76.com/articles/pop-recovery/? Does it kind of supervisor over common EFI boot? I feel completely ignorant here. Do you still have recovery partition? So how many boot stages are there?

Edit: Let me be clear. Hardware of laptop is beyond my dreams. But I see this there is level of complexity which makes life not easy.

Did you actually read the information on that web site?
Systemd-boot is a EFI boot manager, part of systemd but can be used standalone. A recovery partition is exactly what is being discussed there. What is a "common EFI boot" in your idea?

My point is how these two things systemd-boot and elilo can coexist? I have no idea what is common EFI boot. If I have choice I always go with standard partition table and lilo code put into MBR. Where is systemd-boot placed on? Does it piece of code loaded somehow from somewhere? If it is where is this somewhere? Kind of ROM attached to motherboard?

There are some notes regarding the open-source UEFI implementations and CoreBoot, which is used on the laptop owned by OP.

Disclaimer: those information are just from my own and my friends experiences, then may or may be not correct.

So, the CoreBoot is an open-source "BIOS" which uses some blobs for initializing the low level hardware and "payloads" for frontends - aka bootloaders. There are tons of CoreBoot payloads, but usually are used one of those two:

SeaBIOS : which is like the BIOS - the one from QEMU, it is 32bit only and can boot 32bit and 64bit OSes, but does NOT support NVME drives.

TianCore : which is an open-source EFI implementation, and it is like the EFI support from VirtualBox, it have also a variant named UEFI DUET which I use to make some of my BIOS-only motherboards to have UEFI support. It have support also for NVME drives as any proprietary EFI. It can be 32bit or 64bit, BUT the 64bit builds has no CSM, then it can boot only 64bit EFI capable operating systems.

This TianCore (or UEFI DUET) is really picky about the setup of system/boot EFI partitions. They must have the FAT32 filesystem and the hidden sectors setup accordingly. Believe or not, likely the FAT16 partitions will generate strange issues.

When it is used a MSDOS label, the system/boot EFI partition must be of type EF and to be formatted with a command like:
The "hidden sectors" value must be equal with the beginning/first sector of partition - in my example it is first partition and starts at sector 2048 . Of course, also the device should be customized as is the case.

A good size for this the system/boot partition is 512MB or 1GB.

Depending on the particular build this TianCore (and specialy UEFI DUET) may have issues with the EFI vars and specially with the boot variables - both at writing and reading.

Then, the fancy locations like those setup by the Slackware Setup: /EFI/Boot/Slackware/elilo.efi will likely NOT work, and the proper solution is to use the default boot location: /EFI/Boot/Bootx64.efi, then you can copy the elilo.efi and its config file to /EFI/Boot then rename elilo.efi as Bootx64.efi - even better (and prefered by me) is to put in this default location a boot manager like rEFInd, because you can load custom EFI drivers and detect on-fly new EFI boot devices like the plugged-in USB 3.0 hard drives.

I hope that those notes will help, considering that I managed to properly boot even Windows 10 from a NVME drive mounted in an adapter put in the PCIE x16 slot from a BIOS-only motherboard.

However, from my own experiences, booting from TianCore (or UEFI DUET) is not as simple as it looks - and I do not even started about how to setup the BIOS bootloaders (yes, you need two) for that UEFI DUET kernel named Efildr20 to be bring up and lighting as wasn't the case in this particular thread...

2 members found this post helpful.

...ignore this sorry

is there a line in your /etc/fstab for the efi partition to be mounted at /boot/efi during boot?

Geez you guys are helpful.

Tried this and continue to get the same results.


This returns:


Looks like it:
I am not opposed to booting off usb if it will be significant effort to use another bootloader, and is not considered malpractice. If I were to boot off usb are there best practices I need to be aware of?


@LuckyCyborg
This information looks extremely promising, however I was unable to get things to work.

Copy the /boot/efi/EFI/Slackware/elilo.efi to /boot/efi/EFI/Boot/bootx64.efi and the other files in EFI/Slackware to EFI/Boot.
Then register it to the efi firmware with this
I used Slackware-boot to separate it from the default Slackware that elilo uses.

@colorpurple21859

For the first time I have had something different happen. I followed your instructions precisely. In BIOS I am able to select the new entry that was created. If I select it though the boot instantly fails.

When I boot back into my system and look at efibootmgr I notice that the boot entry that was created by following your instructions is present, though the entry created by eliloconfig is not.

Perhaps what is needed is an edit of elilo.conf.
What is the output for
I suspect you should have: bootx64.efi, elilo.conf, vmlinuz, and initrd.gz; or something similar. The vmlinuz is the image of the Slackware "huge" kernel, which does not depend on modules. The elilo.conf file should be something like:
The "root=/dev/nvme0n1pX ro" needs the X to be the root partition number. The initrd.gz is perhaps unnecessary.

Try the command $ lsblk to find the root partition number, the one with the "/" only. Getting the "huge" kernel to boot is the main objective.