[Tutorial] Convert to systemd-boot

Thanks for confirming my suspicion; I’m staying on grub then.

my loader.conf looks like this:

default a2f05c45b2f0414eaee6f5693c263f16*lts.conf
timeout 0

My current workaround is to set my preferred kernel version as default, and set timeout to 0 to skip the boot entries option entirely

This is slighty off topic and I apologise for the lack of knowledge.

Anyway, I looked into the size of my current /boot and my current size om my personal computer is ~600mb, on my work machine the same is about ~300mb.

The question here are the files: initramfs-linux-fallback.img and initramfs-linux.img.

I’m guessing that the initramfs-linux.img is the important one. But the fallback one, is that one created by grub? Will systemd-boot and dracut create those as well?

I’m kinda hoping the answer is no because otherwise I’ll have to increase the size of my boot-partition as it’s too small and I’m always reluctant to do that due to the risks of loosing all data.

They are both created by either dracut or mkinitcpio depending on which one you have installed/configured.

The same files will be created but they will be at a different location if you use our systemd-boot setup.

It is common to have to increase the size of the EFI partition when switching to systemd-boot if you have a small one to start with.

1 Like

Could an additional partition mounted at /boot be an alternative here if the ESP mounted at /efi is too small?

This is what it says in ArchWiki:

  • mount ESP to /efi and additionally mount an “Extended Boot Loader Partition” (XBOOTLDR) to /boot. This can be useful when a previously created ESP is too small to hold multiple boot loaders and/or kernels but the ESP cannot be easily resized (such as when installing Linux after Windows to dual boot). This method is supported by at least systemd-boot.

We use kernel-install with a BLS layout so I probably wouldn’t recommend mounting it to /boot but it should be possible to use an XBOOTLDR partition. However, I have never tested it.

1 Like

Damn, I was afraid of this.

I have the 300 mb efi partition that EndeavourOS gave me automatically before systemd-boot was default.

To my disgrace, I am yet to try the latest development on systemd-boot + dracut on EnOS.
I converted a while back, an arch system according to the “old” manual way so I am still stuck in that thinking.

1 Like

I wasn’t able to make XBOOTLDR work. I set the appropriate uuid and efi variables using bootctl, but apparently dracut doesn’t support it yet (though I did only a quick check on their bugtracker, no guarantee how current that info is). In the end I ended up reshuffling other partitions and extending the EFI partition.

The dracut change is pretty great, its easy to work with and generates images really quick.

It takes some tweaking on arch wiki guides and reading dracut docs to do some things but dracut is so easy its not a problem.

You should definitely try it :+1:

1 Like

Sure. I will give it a try. I have a spare Arch system with Grub so I can test on that.

I would like to learn the manual way first to see what happens “behind the scene” before starting using EnOS’ scripts. But it does work with Grub as well, doesn’t it?

And thanks for the encouragement!


1 Like

I am following the ArchWiki for Dracut and I have used

sudo dracut --hostonly --no-hostonly-cmdline /boot/initramfs-linux-zen.img

to create an initramfs for the currently running kernel. After regenerating of grub.cfg, I can use this image to boot up the linux-zen kernel.

Since this one is a spare/test system, I’ve got several other kernels installed. I seem not to find what flag should I use with dracut for creating initramfs for all the other installed kernels with the same config as the currently running. I would appreciate a hint on this one.

This script generates them for your all your kernels:

Also, the eos-dracut package would work just fine on a standard Arch system as well. It handles generating initrds using hooks when needed.

1 Like

Great! Thank you!

So there is nothing like mkinitcpio -P for dracut?

Also, I have put the kernel’s boot parameter in /etc/dracut.conf.d/cmdline.conf but runnig:

# dracut --print-cmdline

shows only:

root=UUID=2b46b99b-5340-4377-bb67-45d8d48db65b rootfstype=ext4 rootflags=rw,relatime


seems to have been picked up from /etc/fstab.

However cat /proc/cmdline shows them.

Also, another question: with the kernel parameters given in /etc/dracut.conf.d/cmdline.conf, do I still need them in /etc/default/grub?

Not that I know of, which is why I wrote that script.

I have never put my kernel params in the dracut config directly like that.

You would have to test but I would assume you would still need them in grub. At least the ones needed to load the kernel/initram image.

Of course, if you were using grub to boot a unified kernel image that wouldn’t apply but that probably isn’t what you are doing.

1 Like

Sure, I guessed that much. And thanks for the script and pointing it out.

/etc/dracut.conf.d/cmdline.conf is where it is indicated in ArchWiki so I went with that.

Or how about

–hostonly-cmdline: Store kernel command line arguments needed in the initramfs


I guess I need to test some variants.

No. That would be another experiment.


With --hostonly-cmdline I can see the following in the output of dracut:

dracut: root=UUID=2b46b99b-5340-4377-bb67-45d8d48db65b rw intel_pstate=passive lsm=landlock,lockdown,yama,integrity,apparmor,bpf zswap.enabled=0 nowatchdog

how many kernels do you have installed?
I had a 300MB partition and had 2 kernel installed and it was enough to convert from GRUB to systemd-boot with dracut, but before doing that I did a backup for the whole /boot partition then removed the kernel images.

Initrd size varies significantly depending on you have installed. The Nvidia drivers alone are usually 50-60mb per initrd.

I have mainline and lts.

On my private machine (with nvidia card) it amounts to about 600mb (this also includes Windows).

Same things installed on my work machine but there is about 300mb

Boot partition on both was 260mb.

I was surprised to see the size as well.