systemd-boot updater


If this tool can handle only Manjaro kernels, it should be noted/emphasized and named accordingly (i.e. manjaro-sdboot-updater), or (as my suggestion) make sure the kernel regex can find and manage other distros kernel-names.

Nice work!!


Somewhere in here.


Yes, that was my intention with the next release.

Good idea.

This is an interesting idea. I will look into this as well.

Perhaps create list of possible options and have a config entry for which ones you want generated.

Nice! I need to do an m-a install today. I will try it out.

Somewhere in a future I would like to add the support for this if it is possible. I just haven’t figured out if it is possible. The problem is how to identify the root partition that goes with each kernel.

For now what I have done is add an option that tells it to ignore foreign entries so it can manage your manjaro entries but leave the entries for other OSes alone.


I think autodetecting other Linux installations is a bad idea, for several reasons. For example, since systemd-boot can only launch stuff on the same esp partition, it forces you to share a very small /boot directory between distros.

Instead, we could autodetect other efi launchers to chain load them maybe? That way each distro would use their own bootloader, which could be run from systemd-boot.

But in any case, it is not a sane use case to cater to anyway. Systemd-boot is not suitable for multi booting Linux distros.

But if you are going to add support for different distros, you could maybe probe for fstab and get the root partitions that way? No idea how to pair that data with a right kernel though. You might want to research how os-prober does it for grub.


I have some trouble getting this to work with manjaro-architect. While trying to get it working, I’ve ended up smashing many bugs in refind installation, but so far systemd-boot eludes me. I’ll look into it further today if I get an opportunity (it’s my day off, but everyone is vomiting)


Spend more time with your family, get your priorities right. :grinning:

We can wait. Another day won’t make a difference. Cheers.


I am spending time with them, but sometimes they fall asleep :slightly_smiling_face:


Ho! Ho! Remember home is not church.
Don’t bring your boring work (sermons) home. :rofl:
Your congregation can fall asleep, but when your family do that, isn’t it time to take a break from work? :grin:


Currently I’m actually working in technical customer service for an ISP. Which unfortunately puts more strain on the family than congregation work (less regular and less flexible hours, performance based income etc).


If not, I can check it out tonight after work. The hardware I was using for the install a few days ago needed to be replaced so I didn’t get all the way through the test install with architect.

Can you let me know what filesystem you were using in your testing so I can try to replicate that?

Also, I just has a quick look at the code and it only gets installed if systemd-boot isn’t found. This means that no entries will ever get generated.

I think the flow should be:

  • basestrap systemd-boot-manager
  • check for installation
    • If yes, call sdboot-manage gen
    • If no, call sdboot-manage setup


The test was problematic yes, I already replaced it on the local branch. I was having root on btrfs subvolumes and /boot on fat32. For some reason the esp did not get recognized as fat32.


Did the latest commit you made fix it? If not, I can look at it when I get home in an hour or so.


Not solved yet. Or rather, I do not know, because bootctl doesn’t work for me even if I run it manually. So, I can’t test it.


I tested the latest m-a code you have in master. It worked for me in the unstable branch.

It successfully installed systemd-boot and generated entries.


Okay. So the current situation for bootloaders is

  • grub
    • works
    • has massive (5min on my system, longer on others) delay
    • does not support zstd compression
  • systemd-boot
    • works
    • has hooks to generate entries for new kernels
    • added microcode support
  • refind
    • works
    • added microcode support

So, the rest of the stuff with bootloaders should be fixed with the grub package.


So let me clarify… If I download the new M-a version and chroot into my existing install I can change the grub for systemd-boot?


No, I don’t think so. I believe the work that has been done in m-a is for new installs using m-a.

systemd-boot-manager by itself can be used in existing installs but it won’t convert grub to systemd-boot by itself.

If you want to replace grub with systemd-boot on an existing install, you would need to do that manually from within a chroot environment. You could, however, use the package systemd-boot-manager to install and generate entries for systemd-boot.

There are some caveats to doing this though.

  • systemd-boot needs the kernels to be in the esp so your existing partition may not be large enough.
  • Because of the above, it is usually easiest to mount the esp partition as /boot instead of /boot/efi/. This means moving some files around and remounting your esp partition.
  • Other than that it should be fairly straightforward but I would test in a vm before trying it on a physical install.


Ok! I will try first on a VM…


You don’t have to chroot. You can do it at the OS.
However the main obstacle would be that the $esp for systemd-boot has to be mounted as /boot and grub $esp is mounted as /boot/efi.
After fixing these and changing your fstab, unmount /boot/efi and remount as /boot, issue command " sudo bootctl install". Then create the entries.conf for the OS.


And for optional cleanup, delete grub boot entry and efi files. But preferably only after you have tested that the new bootloader works and you actually want to use it.