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.
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.
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.
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-bootshould 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.
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. Robur gregi in lupo, robur lupo in grege.
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
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.