[ALL] Systemd-boot

Is there any helper for Yast or w/e suse uses to do system config?
Because i want to drop Grub as soon as possible.

I had successfully migrated to systemd-boot on my previous kubuntu setup using my own script to automate new kernel and ramdisk changes…

You would have to set it up and maintain it yourself.

In Yast Boot Loader, you should set the boot loader to “Not managed” so that Yast does not interfere with what you are doing.

And then, after any kernel update, you will have to do some maintenance.

My opinion: I don’t like systemd boot at all. I do not want it on my system. I have both KaOS and Solus installed somewhere, and using systemd boot. And I do not like how they boot.

A couple years ago this question was asked on Reddit
https://www.reddit.com/r/openSUSE/comments/7kx06s/why_doesnt_opensuse_use_systemd_boot_instead_of/

I just checked the ArchWiki page for systemd-boot which I’ve found fairly reliable for generic documentation on various technical topics,
https://wiki.archlinux.org/index.php/systemd-boot

And the ability to boot to snapshot is not mentioned so it’s a good guess it’s still missing.
That’s a significant feature that GRUB2 supports.
I haven’t looked closely at systemd-boot, but somewhere in there supposedly it’s possible to chainload it to GRUB2 instead of replacing GRUB2.

TSU

No, kernel RPM directly calls script that adds/removes bootloader entry.

There are two options to automate maintenance (that won’t be overridden by next update)

  1. Create new bootloader-type scripts in /usr/lib/bootloader and set corresponding LOADER_TYPE in /etc/sysconfig/bootloader. It may still have some unwanted side effects when YaST is called (I am not sure how YaST will react to unknown loader type) and needs small hack so kernel RPM actually calls bootloader - it checks for known configuration files. Advantage is, this could be submitted for inclusion in perl-Bootloader as it is pretty much self contained and has low regression potential.

  2. RPM with trigger script that runs after kernel RPM installation/removal. Note that this script will not have all information that bootloader script gets, still this should be enough to ensure new kernel is present as bootloader option.

The former is certainly preferred and kernel maintainers may even agree to relax current checks.

Ok let me ask this then, is it possible in suse to make use of the following:


/etc/kernel/postinst.d
/etc/kernel/postrm.d
/etc/initramfs/post-update.d

Because then i could just update my script i wrote to be more general and able to work for other distributions like suse etc also…
I could fe. as i had planned make use of an /etc/default/kernel and/or /etc/kernel/cmdline to make it possible to be configured outside of that script…

Thanks for the very nice links :good:
Yes it is possible to chainload grub, i actually used such an entry as possible fallback on my old setup while using Kubuntu and developing my script linked in previous reply…
I have no idea how the boot to snapshot functionality works yet because im still totally new to suse, but if grub can do it so should other loaders be able to…

No, it is not.

What the hell :open_mouth: why not?
IIRC :That is functionality from the base kernel install stuff (from source)…
>:(…so how does one hook into those stages in suse?

https://forums.opensuse.org/showthread.php/542959-ALL-Systemd-boot?p=2954833#post2954833

Yes i noticed that (even quoted it before), but could not convert it into a how-to do that in practice because im illiterate when it comes to suse+rpm but opposite wrt Linux in general…

After being given the link to the dracut wiki in another thread the first pointer of interest i found is:

> dracut --print-cmdline
 rd.lvm.lv=Linux/suseTumbleWeed 
 root=/dev/mapper/Linux-suseTumbleWeed rootfstype=btrfs rootflags=rw,relatime,space_cache,subvolid=266,subvol=/@/.snapshots/1/snapshot,subvol=@/.snapshots/1/snapshot

which will be very useful to build-up the kernel options for use by sd-boot in a loader-entry config…
These options can be directly used in the loader-entry config for a particular boot-entry.

But i’m completly lost at moment when it comes to what/how to create a new bootloader-type script in /usr/lib/bootloader .
I could really use help with that.
The main part i need help with would be (for now) to copy the current (or fresh created) kernel and initrd into the ESP after everything is done to them, eg. as last step in the whole process of dracut.
Because those are the main things needed for sd-boot, the loader-entry config(s) can be created/changed/etc after these two files are in place on the ESP…
That is actually the main part of my script i wrote for kubuntu

I’m going to do a manual copy of those files and a manualy created loader-entry config to see if i can boot TW using sd-boot without grub as a test. (Which should work)

At the very least you need to implement config script that is called by kernel RPM to add/remove new kernel. Existing scripts (grub2/u-boot) actually happily ignore any options that kernel RPM passes to this script; if you need to parse these options, look at “rpm -q --scripts kernel-default” for bootloader_entry calls.

Please see here why im dropping openSUSE at this point…
Thanks and goodluck all.

Do I understand it correct that it’s not possible to use systemd-boot?
(I’m fine by manually copying initrd and vmlinuz to the EFI-partion after each update).

I really like to use SD-B on my Debian boxes…but now I wanna move to openSUSE but SD-B is a must-have.

On Debian I just run bootctl --path=xxx install

If you don’t mind configuring it yourself, then you should be able to do that.

I think you need to disable secure-boot (I don’t think sd-boot supports that).

bootctl install

should install sd-boot into your EFI partition.

Go into Yast bootloader. It has boot choices. The options are:
GRUB2
GRUB2 for EFI
Not managed

Set it to “Not managed”. That way the system won’t get in your way with trying to update the boot loader.

As an alternative to using Yast, you could manually edit “/etc/sysconfig/bootloader” and set

LOADER_TYPE="none"

You will probably have to manually create the initial sd-boot configuration. Looking at how Debian configures it should give you an idea of how to do that. And then you will need to update the copy of kernel and initrd in the EFI partition after every kernel update. If you forget to do that, you will just boot the previous kernel. But don’t let it get too far behind.

I have never tried doing this. I don’t like sd-boot, though I do have “Solus” and “KaOS” using it.

Yes, I got it working! Just as easy as on debian :slight_smile:
TriMoon wrote SUSE was hardcoded tightly to GRUB so I started to loss faith :open_mouth:

But I’m up and running :slight_smile:

What is “vmlinux-5.3.18-lp152.57-default.gz” (13,2MB)?
vmlinuz-5.3.18-lp152.57-default”, which I use for booting, is only 8,61MB?
I would guess the former was a compressed version, but it’s bigger?

I’m not actually sure. It’s been a long time since I last compiled a kernel.

It might be the kernel as compiled, with symbol table and all. The “vmlinuz-*” file will be modified as an image file easy loading into memory.

The answer is:

**3400G:/mnt/boot #** file vmlinuz-5.3.18-lp152.57-default     
vmlinuz-5.3.18-lp152.57-default: Linux/x86 Kernel, Setup Version 0x20d, bzImage, Version 5.3.18-lp152.57-default (geeko@buildhost) #1 SMP Fri Dec 4 07:27:58 UTC 2020 (7be5551), RO-rootFS, swap_dev 0x8, Normal VGA 
**3400G:/mnt/boot #** file vmlinux-5.3.18-lp152.57-default.gz  
vmlinux-5.3.18-lp152.57-default.gz: gzip compressed data, was "vmlinux-5.3.18-lp152.57-default", last modified: Sat Dec  5 08:19:42 2020, max compression, from Unix, original size modulo 2^32 79755872 
**3400G:/mnt/boot #**