How best to implement systemd-boot support for Manjaro kernels

systemd
systemd-boot

#1

With Manjaro architect we have systemd-support at installation time. right after that the user needs to create loader files for systemd-boot for every new release by themself.
Since systemd-boot is so much slimmer and easier to manage, compared to grub, on UEFI setups. I think we should have it supported by our kernels.

I was trying to make a alpmhook / script for it but I’m stuck at 2 points.

  1. get the UUID of the root partition. Since I don’t want to utilize the fstab (since I dont know if there is even a fstab, or if it has a UUID in it, I cant use it at all)
  2. deal with the “is it a systemd-boot or a grub setup”-issue.

I also don’t want to enforce it, since this whole thing is a EFI only solution. But would you like to have this feature in Manjaro?


#3

To install systemd-boot, at terminal.
Feature is present in all systemd OS’s.

sudo bootctl install

For more details, see this.
Perhaps that link may need some updates and new features.


#4

It’s also easy to switch from grub to it. But this will not fix that you always need to create the loader file yourself, per kernel (+fallback).


#5

loader.conf is created once. Usually no need to create/amend .
I think you mean the entry.conf for the different kernels.


#6

exactly :blush:


#7

To expound, “bootctl install” is to create a efibootentry and a efi-file “/EFI/systemd/systemd-bootx64.efi”. We will still need to create entries.

Personally, I agree systemd-boot is quite simple though refind can automatically detect efi-files at boot and present the boot entries for them. We just have to manually create entries for systemd-boot. And systemd-boot is fast, very fast. refind is pretty though.

That said, I still think grub is simplest (yet powerful and automatic). The complexity that people find - and I understand what they are saying - is due to ‘clever’ OS developers trying to use the capabilities of grub’s facilities to further extend grub’s reach into areas that are not necessary; by the use of extraneous /etc/grub.d/ (like 01_menu_auto_hide) and grubenv variables (like boot_indeterminate and boot_success). Oh, and we can make grub very pretty too, and in much more many forms.

To reiterate, that is my personal opinion and I have no interest to influence what people choose for the bootloader. Just glad we in linux are spoilt for choice. (I choose to use grub, just not Manjaro’s)
[Except for cheesecake - “There is no alternative!” - to quote Margaret Thatcher]


#8

I dont want a pro/con refind vs grub vs bootctl in here. Its just to have supported, what is offered by a official installer we ship.


#9

Parse the output of blkid.


#10

Thanks. I found just yesterday night the command:

findmnt / -o UUID -n

sometimes it’s just to easy :joy:


#11

I’ve moved this from a #manjaro-development:feature-request to a #manjaro-development discussion so we can put together how this can be done before making it into a request.


#12

OK. So a quick summary what is needed:

  • UEFI (of course)
  • mount <efi> /boot #not a must have, but a very strong recommendation.
  • loader files for kernel and fallback (sitting in /boot/loader/entries/*.conf

We only need to generate new loader files for new installed kernel, new installed and UCodes. We also need to remove them on kernel/UCode uninstallation.
So there is also no need to re-generate them after a mkinitcpio.

One example for my 4.20 loader is:

/boot/loader/entries/manjaro-4.20-x86_64.conf

title	Manjaro
version	4.20-x86_64
linux	/vmlinuz-4.20-x86_64
initrd	/intel-ucode.img
initrd	/amd-ucode.img
initrd	/initramfs-4.20-x86_64.img
options	root=UUID=cbe62a0b-ddf0-47b7-b9de-2ee9b2ac59a5 silent rw

Version string will only be shown, when there is more than one entry with the same title.

given that - I think its the best to have an alpm hook for every single kernel that

  1. generates a loader on kernel(self) installation time
  2. updates the loader on change of amd/intel Ucode
  3. uninstalls the loader on kernel(self) uninstallation time

#13

Btw Solus has systemd-boot, and as far as I remember by default $esp’s mount point is /boot/efi there. Also they make use of clr-boot-manager or how it’s called I don’t remember. I mean, no need to invent the bicycle if it’s already implemented somewhere.
Below are some thoughts of mine, feel free to disagree:
Using /boot as $esp just because of one more bootloader (in fact not the most feature-rich or unique) is somewhat not thoroughly thought of, and may cause a mess, especially in people’s heads. There are really few people who like to tinker with their bootloaders, and for the absolute majority such things should be just as reliable as possible with no need for manual intervention (even Grub gets broken from time to time according to the forum’s posts).
I had no intention to offend anyone, sorry for being rude, the above are just my thoughts regarding so-called bootloader.


#14

Using /boot to mount $ESP is what architect sets up. I dont want to deal with that or change already installed systems, since it works fine. Also I dont have plans or any need to convert people from grub to Systemd-boot (SDB). Grub people will still get /boot/efi and thats just fine how it is. :grinning: This is entirely only for the SDB path of installations (or for people who want to switch over).

Thats why I like SDB. It’s just a simple loader, nothing more, no special setting or beautiful backgrounds to create, no rebuilds, no nothing. You set it up one time and it will work until you want to try a new kernel.

Thats the excapt point why I use SDB for me and my family, instead of GRUB. I’m sick of having errors, missing filesystem support, a broken boot because of some config changes or fighting of multiple linux grub implementations. But that is not the topic in here. Again - I dont want to replace Grub in Manjaro. I only want to have actual support for it in manjaro, because you can install manjaro right now with support for it.

Is there something wrong with it? :thinking:


#15

Hmm, since you want to use the systemd bootloader, it doesn’t matter much that you need a mounted / and/or /usr.
I prefer base commands coming with the bootloader itself.


#16

I need to get the UUID of root (/) for the loader file. It’s not that I need a mounted root but I dont know how to point out what root is to get the UUID from somewhere else.


#17

Just to contribute to this brainstorm:

  • In general, to make systemd-boot an easy to use for non-experts, you need to create the respective AI of grub (grub.d/xx-section and /etc/default/grub parameters) in hooks.
  • to bypass caveats of multiboot similar distros, you might set creation of loaders even for upgrading same kernel, using minor version in loader names.
  • consider resume/suspend/swap parameters
  • consider lvm/luks or other special partition types/fs
  • check or enforce systemd usage in mkinitcpio
  • check esp size to contain several kernels, especially considering multiboot scenarios
  • include settings means, like /etc/default/systemd-boot (don’t know if there is one already)
  • take advantage of * capability in loader title

…more to come when available… :stuck_out_tongue_winking_eye:


#18

Setting root=UUID=<UUID> doesn’t work for all filesystems. Setting it this way would break some systems.

How about having a settings file somewhere that can populate the options line? Then we could pull that in with every new kernel.


#19

@openminded https://github.com/clearlinux/clr-boot-manager looks like a nice tool, but requires changes to how we handle kernels in general. So I dont know if we should do this.

I also dont know if Grub is still supported by this, but if yes, this could be something nice to have for the grub side too. (still no plans for this on my end)


#20

Is silent a new (to me) option, or you wanted to say quiet?


#21

blkid and check for a unique marker, eg a file /etc/profile or so?