You don’t. You can remove them with efibootmgr
To be clear, the endeavouros entries can be removed.
Can I remove the (all of the?) folders after removing the entries out of efibootmgr?
Also re: dual booting/ Windows 10, I followed the beginning here: https://vectops.com/2022/02/dual-booting-arch-linux-and-windows/
mount /dev/sdXN /mnt # replace 'sdXN' accordingly to your Windows' disk address
cp -r /mnt/EFI/Microsoft/ /efi/EFI/Microsoft/
I did not create the /efi/loader/entries/windows.conf file (I did this previously but then rolled back with Timeshift because I then had two Windows 10 boot entries)
I just ran bootctl update but I don’t even know if this was necessary.
tl;dr: manually copying the EFI/Microsoft/ files from the different windows SSD to my linux SSD made the boot entry appear in systemd-boot!
I mean, you shouldn’t remove all of them but you can remove the ones associated with grub.
1 Like
GRUB can also detect Windows bootloader in other disks, systemd-boot can’t.
This confirms it I guess that systemd-boot does NOT detect Windows if it’s on a different disk but you can just copy the EFI files from one disk to another.
Now I am happy, everything is working! Thank you again for your help.
2 Likes
I am noticing that, if I’m using the display port output on my AMD graphics card (and I’m booting “cold” as opposed to rebooting with my monitor already powered up) my monitor doesn’t wake up until after the boot menu has timed out and gone. While it still eventually boots, I never see my Motherboard logo or the systemd-boot menu. If I switch from DP to HDMI, the monitor wakes up much faster and it works just fine. It was working that way with either DP or HDMI with GRUB. Just trying to figure out what may have changed.
I am not sure. Systemd-boot should be getting loaded until after the logo so it shouldn’t impact what happens before that. Did you make any BIOS changes trying to deal with the grub issue?
Not that I’m aware of and, even with my broken grub, it was still waking up quickly with DP. My motherboard does not natively support DP so I’m thinking it’s just waiting for the graphics card to wake up first. I’m looking at my monitors power settings as well to see if there’s something I can do there.
UPDATE: I think I’ve resolved my issue and it’s hardware related, nothing to do with this. Grub was probably waiting for my graphics card to come online because, well, it was displaying graphics. Regardless of whether DP or HDMI is connected though, if I reboot, the monitor does not go into sleep mode and I get the motherboard logo and menu. If I manually power the monitor on first from a cold boot, same results. As I said before, my low-endian motherboard does not natively support DP. So, my monitor is not waking up because it needs my graphics card to come online first (or I need to wake it up myself). So, if I really need the menu, I can either manually power the monitor on first or set a long enough timeout in loader.conf to give the graphics card time to come online first.
UPDATED UPDATE:…and now, it’s just working correctly with DP. Further online research indicates it may be a known issue with MSI widescreen monitors (some suggest getting a better quality DP cable than the stock one that comes with it). In any event, it’s a hardware thing…
My my such recent activity. Can’t imagine why, must be a coincidence 
Can this be made to work with my Timeshift BTRFS snapshots? I used the procedure in Discover to set it up but that obviously assumes grub and is need to replace the service updating the grub configuration with something else? Haven’t found much on this yet. I know I’ve seen snapper integration with rEFInd but nothing for this yet. Or dors systemd boot pick up the snapshots automatically?
I always had this problem but with an NVIDIA GPU, GRUB and my MSI monitor (and I guess still now with systemd-boot). Switching to HDMI solves my issue as well. I made this (very confusing) thread a while ago trying to solve the issue. But I could never fix this problem.
But for you it seems like it worked with GRUB but stopped working with systemd-boot?
For now my solution is to 1) turn on my monitor before I turn on my PC and 2) I increased the /efi/loader/loader.conf timeout time by a bit and spam Arrow Down & Arrow Up when I boot so that I am still in the select boot screen when my monitor finally displays a signal over DP.
1 Like
@dalto just did a full reinstall of EOS and on systemd-boot.
Currently i have 3 kernels installed (Arch 5.14.1 lts and Linux-amd), my question is, when i reboot i don’t get a “boot menu” where i can choose which kernel i want to use. I think it’s possible from what i read online but since this is the first time i use systemd-boot i have no clue ho to do.
Hope someone could put me on the correct path for this.
Thanks!!
What is the content of your loader.conf file? The default timeout value in loader.conf is “0” and the manpage says:
“The menu will not be shown by default (the menu can still be shown by pressing and holding a key during boot)”
2 Likes
#timeout 3
#console-mode keep
ok i see … i overlooked the #
will change and try
Ok that was the issue, # removed and the menu appeared!!
@mbod thanks for opening my eyes on this one!!
2 Likes
Hi @dalto , thanks for this clear tutorial.
I have just installed systemd-boot with kernel-install method, and all good. Could reboot without issue.
Then, as I have LUKS, I followed your instructiions below:
But when I run sudo mkinitcpio -P I got a bunch of errors:
==> Building image from preset: /etc/mkinitcpio.d/linux-lts.preset: ‘default’
→ -k /boot/vmlinuz-linux-lts -c /etc/mkinitcpio.conf -g /boot/initramfs-linux-lts.img
==> ERROR: specified kernel image does not exist:/boot/vmlinuz-linux-lts' ==> Building image from preset: /etc/mkinitcpio.d/linux-lts.preset: 'fallback' -> -k /boot/vmlinuz-linux-lts -c /etc/mkinitcpio.conf -g /boot/initramfs-linux-lts-fallback.img -S autodetect ==> ERROR: specified kernel image does not exist:/boot/vmlinuz-linux-lts’
==> Building image from preset: /etc/mkinitcpio.d/linux.preset: ‘default’
→ -k /boot/vmlinuz-linux -c /etc/mkinitcpio.conf -g /boot/initramfs-linux.img
==> ERROR: specified kernel image does not exist:/boot/vmlinuz-linux' ==> Building image from preset: /etc/mkinitcpio.d/linux.preset: 'fallback' -> -k /boot/vmlinuz-linux -c /etc/mkinitcpio.conf -g /boot/initramfs-linux-fallback.img -S autodetect ==> ERROR: specified kernel image does not exist:/boot/vmlinuz-linux’
==> Building image from preset: /etc/mkinitcpio.d/linux-zen.preset: ‘default’
→ -k /boot/vmlinuz-linux-zen -c /etc/mkinitcpio.conf -g /boot/initramfs-linux-zen.img
==> ERROR: specified kernel image does not exist:/boot/vmlinuz-linux-zen' ==> Building image from preset: /etc/mkinitcpio.d/linux-zen.preset: 'fallback' -> -k /boot/vmlinuz-linux-zen -c /etc/mkinitcpio.conf -g /boot/initramfs-linux-zen-fallback.img -S autodetect ==> ERROR: specified kernel image does not exist:/boot/vmlinuz-linux-zen’
Anyway I did reboot OK, but still without asking my encryption password, when your tutorial says that as this point I should have been asked for the password.
What do you advice in this situation ? Should I forget about the previous errors and use cryptsetup to delete the crypto_keyfile… or is there a way to debug those errors ?
Thanks in advance
I had the same issue (almost). My issue was about setting the default kernel to boot to.
As usual @dalto helped me with it here → [Tutorial] Convert to systemd-boot - #160 by limotux
Doing this I could boot by default to the LTS kernel not the default kernel while still having an option to boot to default kernel or to fallback.
I hope this adds some benefit for you.
1 Like
I think the issue would be related to your EFI partition but it is full, that is why kernel images cannot be stored on this partition.
Can you check how big is size of the EFI partition?
Well, I got it sorted. The issue was with the old presets in mkinitcpio.d , so I just re-installed the 3 kernels I use (Linux, Zen and LTS), then ran again sudo mkinitcpio -P and voila, no error and my passord was asked at reboot 
No the EFI partition is big enough. But I just got it sorted (see my last post above). Thanks anyway !
You cannot reliably boot off a snapshot with systemd-boot.
I need to modify the instructions. Re-install your kernels. That will fix the mkinitcpio presets.
EDIT: Oops looks like you already figured that out.
2 Likes
@dalto I have linux linux-lts and linux-zen kernels installs (all with corresponding headers too) and if I add all those kernels up, it comes to about 518MB (not including the headers).
[scott@EndeavourOS ~]$ du -sh /boot
179M /boot
[scott@EndeavourOS ~]$ sudo fdisk -l
[sudo] password for scott:
Disk /dev/sda: 238.47 GiB, 256060514304 bytes, 500118192 sectors
Disk model: HFS256G39TND-N21
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: B02B050B-EEF0-AE4C-A2D4-5B4D213CB602
Device Start End Sectors Size Type
/dev/sda1 4096 618495 614400 300M EFI System
/dev/sda2 618496 481648511 481030016 229.4G Linux filesystem
/dev/sda3 481648512 500103449 18454938 8.8G Linux swap
[scott@EndeavourOS ~]$
I’ve confused myself a little bit, do I need to have my EFI be bigger than my du -sh /boot from just one kernel or for all three (not sure if I need to include headers into that too or not)? I typically switch between linux and linux-lts for testing making sure there’s no bugs running wild. Given the situtation of things and reading more about systemd-boot, I’m curious and very tempted to give this systemd-boot a go though I’ll admit.