systemd-boot updater


#1

I am not sure how many people are using systemd-boot with Manjaro but I have put together a package of scripts and hooks that will manage systemd-boot for Manjaro so I don’t have to do it manually.

It does a couple of things:

  • Updates systemd-boot when systemd is updated
  • Manages systemd-boot entries as kernels are added, removed or updated

It currently supports any normal filesystem such ext3/ext4/xfs/etc and also btrfs and zfs.

Next I am going to look at what it takes to get LUKS support added.

If anyone is interested in this let me know and I will look into getting it uploaded somewhere.

Also, if there is any other root filesystem I need to look at adding, let me know.


#2

I think it deserves a place :slight_smile:


#3

Make sure you add root NTFS support for all the Windows refugees who just can’t live without their Windows file systems. HA HA, just kidding. :smile:

Nice work with all those scripts.


#4

I’d like the systemd-boot simplicity but I don’t know why with Architect I’m unable to install it… There’s a way to remove Grub and install systemd-boot in a safer way? I make a forum search but nothing comes up.
Thanks!


#5

Thanks! Thats so cool!
It’s already more mature, when it managed to remove entries compared to my script :joy:


#6

This would be awesome. Might help a lot of people dump GRUB2.

Nice work.


#7

Yep - I’ll take some of that…


#8

@dalto good to know.
Is that the same script as ‘bootctl update’?
How about ‘bootctl install’? Is that in the pacman hooks too?


#9

If you upload the script and the hooks in a git repo I can probably package it and add it to the repos.


#10

Could you at the same time make it into the script of “bootctl update”?
And make the script “bootctl install” create a loader.conf?
My systemd-boot has other (non-systemd-boot) OS’s efi files copied to systemd-boot’s $esp so that systemd-boot can boot these as well. Hopefully this script can also detect and create entries for them.

Thanks.


#11

What can I say? :wink: :slight_smile:


#12

Thanks that sounds great.
For 2019, i’ve decided to switch my workstation to systemd-boot.
Your scripts would be very welcome :+1:


#13

Looks like this got posted after was asleep last night.

Glad to see there is a lot of interest. I am at a conference all day but I will answer all the questions tonight when I get home in about 8 hours.


#14

How does this compare to grub scripts? I don’t use grub scripts at all. I have my own grub.cfg that I use. That’s all I use , beside grub-boot.


#15

I’ll see what we can do. I have currently limited time for scripting, but on long term I would like to create a pacman hook for a script that creates boot entries for the installed kernels in an installation. Probably call bootctl update as the first step and then amend entries as necessary.

I had already planned on doing something like this, but if @dalto does the main scripting, it will likely get done faster. I can just contribute to the script and package it.


#16

I have done quite a few m-a systemd-boot installs. You might start a separate thread with the problems you are having so we can help you troubleshoot it.

At the moment, the only time it calls bootctl update is when systemd gets updated. In my testing, I haven’t come other times when it is needed. Are there any other time it needs to be updated?

I thought about it, but I wasn’t sure that installing a package to manage systemd-boot should install the bootloader.

What do people think about that? Should it trigger an install or should it not?

Excellent! Does it belong in the manjaro gitlab or should I use a create it somewhere else?

Isn’t bootctl a binary? I took the approach of creating a script that wrapped bootctl and added automation for Manjaro.

I could certainly create a function that automated that process. Although, there isn’t really much to automate.

Currently, the script doesn’t do this. It does, however, have configuration options that determine whether it should delete existing entries and create new ones or ignore existing entries.

In order to create entries, I need information about the root filesystem in the target OS. Is there sufficient info the efi to determine this? If so, I should be able to script it.

I haven’t looked at the grub-mkconfig extensively but systemd-boot is fundamentally simpler than grub is so there is much less to do.

That is pretty much exactly what it does. I built this with m-a in mind. As soon as I get LUKS support added and get it tested with lvm it should be capable of being dropped into m-a and we could just remove the section that creates the entries in install_systemd_boot().

It already detects installed microcode and handles that in the entries.


#17

When the kernels get upgraded, say from linux4.19 to 4.20.

Currently ‘bootctl install’ just copies efi files to bootx64.efi and generates an efibootmgr file.
Nothing more. If it makes a loader.conf, I think that will be better. It (now) has to be created
manually. We can think of loader.conf like /etc/default/grub (just much less functionality) and puts in parameters, like timeout, default entry.
‘bootctl update’ after ‘bootctl install’ does nothing new.

Yes, you’re right. It needs mapping of target OS and just the efi file does not provide this.
Which brings up an interesting question.

Do you have more than one OS for your systemd-boot? Your script, therefore, I think, does not work for more than 1 OS. I hope very much that I am wrong.

I have 2 OS’s natively in systemd-boot. I installed a Manjaro in systemd-boot (without grub). Then I made it boot 2 other Manjaro OS’s (natively in grub). Then I added to it efi files from other non-manjaro distros so that systemd-boot can also boot them. I could have added their kernels but I added the efi files so I do not have to keep revising them. And manually made their entries.conf.
loader.conf is made manually and seldom changed.

ps: I also think your (existing) script would, in my case, make all ‘kernels’ boot to the same target OS. It is okay for me to continue this manual method. It is not very much of a hassle.
Oh… naturally, I can boot the systemd-boot OS’s using grub as well. And most of the time, I do.
I share this systemd-boot $esp with my refind $esp. All co-existing and all working. But as said, I use grub most of the time. [ grub ~ 97%; systemd-boot ~2.5%; refind <.5%]. Once these are working, I once in a while test them out.

[EDIT] - re: microcode.
If enabled, an automatic generation of entries will make a double ‘initrd’ line. And would not be required for other non-manjaro distros. But I guess having microcode called up twice in these distro’s should not disastrous.

Ah… the pitfalls of not running with the pack. :rofl:
Robur gregi in lupo, robur lupo in grege.


#18

I now realize that systemd-boot is for efi and NOT bios boot. It won’t work for me:
ArchWiki:
systemd-boot , previously called **gummiboot** (German for: 'rubber dinghy'), is a simple UEFI [boot manager] which executes configured EFI images


#19

Interesting, I didn’t need to do this in any of my testing. Simply adding the new entries was sufficient. It is only certain kernels that require this? It would not be a big deal to call bootctl update after the entries are created.

I can create an install wrapper that installs systemd-boot and creates a loader.conf and an initial set of entries.

At the moment, the script is intended to manage boot entries for Manjaro. It can, however, be configured to allow those entries to live in parallel with custom entries. So if you had manual entries for one linux distro it is capable of ignoring those and just managing the manjaro related entries.

If it is possible to discover those other OS entries it would not be a big deal to have the microcode lines only applied to Manjaro. We just need to figure out if it is possible to discover them in a reasonable way.

This is the downfall of becoming an expert in something, you start doing things because you can. :grin:


#20

Only if we ought to. Not because we can.

People (and countries [1]) that subscribe to
" The strong do what they can and the weak suffer what they must."
will do upon themselves what they did to others [2].

[1] - taught in Sandhurst and West Point.
[2] - what they did to others, they finally do it to themselves - thucydides on the fall of Athens.