I don’t actually want to remove grub, I’m going to keep it around as sort of an “advanced boot options” menu but day to day I probably only need my linux-zen kernel. I was looking at this post (EFIstub Tutorial? - #2 by dalto) and the Arch Wiki page ( https://wiki.archlinux.org/title/EFISTUB#Using_UEFI_directly) but I didn’t get a sense of where I should put my custom kernel parameters, I have to use one to make sure my laptop keyboard works right every time, so I need to append “i8042.probe_defer”. I’ve also got “loglevel=3 nowatchdog nvme_load=YES” sitting in there, might be nice to just pull them all in.
If you look at the example from the arch wiki:
efibootmgr --disk /dev/sdX --part Y --create --label "Arch Linux" --loader /vmlinuz-linux --unicode 'root=PARTUUID=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX rw initrd=\initramfs-linux.img' --verbose
It looks like the kernel params are here: 'root=PARTUUID=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX rw initrd=\initramfs-linux.img'
That being said, I have never tried it myself
1 Like
ok I’ll try sticking it in there and seeing what happens (and this is why I’m keeping grub around, heh).
Well, that’s interesting. it’s not working at all. efibootmgr shows the new entry until I power off, then it goes away. I’ll have to see if something is read only somewhere in the BIOS, this is quite annoying.
I’m going to put the add command I’m using in just in case anyone spots anything wrong with it.
# efibootmgr --disk /dev/nvme0n1 --part 1 --create --label "EndeavourOS" --loader /vmlinuz-linux-zen --unicode 'root=PARTUUID=115e14e8-db06-40b9-8639-6934372d846e resume=PARTUUID=3cbbdf01-e7a7-4fa9-a24f-48180d6f4b45 rw initrd=\initramfs-linux-zen-failback.img loglevel=3 nowatchdog nvme_load=YES i8042.probe_defer' --verbose
This is irrelevant to the correctness of the executed command, which looks fine (backslash is not needed, it should be converted by efibootmgr).
Similar behavior is reported several times and has to do with vendor’s UEFI implementation. In such cases, we use the default/fallback installation method, but I suppose it is not what you actually want.
OTOH, efibootmgr has some bug reports, so it maybe a bug, but needs investigation and testing.
Are you sure there is no other same label among the rest of the entries?
Also, do you remember if you have used the default/fallback location method for your grub installation, or other thing that might be related?
There’s only two other entries, the endeavouros-2000 grub entry, and the UEFI failback pointing to.
Looks like the kernels are actually in /boot rather than /boot/efi, which is the mounted EFI partition. Missed that before, that’s likely the problem. I don’t recall there even being an option for a default or failback during grub installation. I suppose I could move the kernels and change the mount point and then be able to do this…carefully of course.
I see the opposite: Change the command parameters to reflect the correct partition and image path.
-l | --loader NAME
Specify a loader (defaults to \EFI\arch\grub.efi)
In your case, you don’t need *.efi loader, but the kernel itself.
/boot/vmlinuz-${KERNEL}
The drive and partition should be the one that has /boot, usually root partition (/), and the path as above.
Unless you have a separate /boot partition mounted in fstab.
Yeah, I thought I made that clear above. P1 is mounted as /boot/efi. Which would make /boot part of the root partition.
/dev/nvme0n1p1 300M 608K 299M 1% /boot/efi
I think I was wrong. Archwiki suggests the drive/partition should be the ESP, so this suggests you should mount your ESP to /boot .
I apologize for the confusion. It is a long time I have done this and remembered wrong.
Always read the docs for the correct info. 
Hey, no problem. I’m getting the impression that the EFI really SHOULD have been mounted as /boot but it wasn’t. It’s something that’s changable but that’s a lot more drastic than adding another EFI entry. Anyone know if my system just installed wierd for some reason?
It’s a fact! 
Edit: Actually, you can also mount to /efi as well
Read
What exactly do you mean to ask?
Why it got mounted to /boot/efi instead of /boot. I’m worried about breaking something down the road potentially.
This is how the EnOS installer does it.
If you want something different, you have to do it manually (the Arch way ).
If you modify system settings without enough knowledge/experience, or RTFMing, then it is possible to break your system.
If you don’t, then everything will be fine, until … it breaks for unexpected reasons, like the grub issue.
Always keep backups for your valuable data!!!
All the important stuff is backed up, no problem there. I don’t want to lose the work setting up the system though.
So it sounds like Endeavour isn’t really compatible with the Arch Wiki EFISTUB article…that’s fine. Something I wanted to explore but if it can’t be done then it can’t, not the end of the world. Maybe it’s time to look at unified images and dracut…more moving parts that way but I can give it a pretty splash image. 
1 Like
Ok, so after looking at this, I think I know what I want to do (@dalto and @petsam catch me if I’m wrong, I’m exploring some interesting territory here as RHEL handles kernels differently). I think what I want to do is use kernel-install-mkinitcpio and the script from here to get a kernel image into my EFI partition. Then I can boot from it directly from UEFI if I want to. I can just skip the cleanup steps so I can maintain access to my grub bootloader with the alternate kernels, since I really only want my primary zen kernel to get this option, and I’ll go through grub for anything fancy.
I suppose I could use kernel-install-dracut but I have mkinitcpio installed now and installing dracut will remove it. I hear dracut is “better” somehow but I might not use any of the better. I’ll have to read up more on both first.
Assuming your installation already contains “vmlinuz” and “initramfs” files in your /boot directory, why not copy them to your EFI/ESP partition?
If it works and boots you can decide if you want to transfer all the /boot files and change the mount point to /boot instead of /boot/efi with appropriate modification in fstab.
rEFInd can effectively perform an EFISTUB boot without having to move files or modify mount points.
Because I’m overthinking it?
1 Like
Exactly this is the problem, if I interpret correctly. You should first define the problem you want to solve, with good specificity, and after that, try to find a solution.
In a general thought, and as I am also a computer user 
, I think the main problem is trustworthiness of my HW/SW and prepare for a possible disaster.
The disaster can be anything, not only the bootloader.
Many experienced users advise keeping backup of your valuable data, no matter how well your system and hardware are configured/set up.
This solves both hardware and software failures issue.
IMHO, for software (system) failures, a restore facility would be a quick solution. I would prefer a dedicated partition with minimal software, that would serve as what we usually do with a USB Live ISO, like chrooting, saving data from a failed partition/drive, etc. This could be a partition on the existing drives, or a USB that you dedicate for this task.
But you can try and do whatever you like, it’s allways fun to discover new things 
Yeah, part of this is the joy of tinkering…but the bootloader is not something to tinker with lightly. Plus I’m just trying to make sure to avoid breakage, if I break one boot path I have an option for another. Another thing I think i noticed is that the kernels need to be on a snapshotted volume in order to roll back a bad kernel update…but then again, that’s why I keep an LTS kernel around on this (I’m the same way on my servers, always keep two kernel versions installed on RHEL, just in case).
Anyway, I’m also considering not messing with it. I keep going back and forth in my head on whether I really want to get into this, it should be fine, and I have my Chromebook if I really need something when I break the EOS setup. Maybe I should just wait for the weekend when I have plenty of time and bandwidth to hack away at it instead of multitasking.