RFC: systemd-boot vs GRUB on openSUSE Slowroll

English Install/Boot/Login
1

After my lengthy trial to solve a Suspend/Resume/Hibernation for a Intel Ultra 5 Laptop in conjunction with Deepseek, I ended up deep in the new systemd-boot realm. At the end, I asked Deepseek for a summary report as a memory note. I hope it can assist fellow member of this forum in their own quests one day.

:clipboard: Summary: systemd-boot vs GRUB on openSUSE Slowroll

:key: Core Concept: Boot Loader Specification (BLS)

systemd-boot implements the Boot Loader Specification, a standardized way to organize boot entries. Instead of a single monolithic configuration file (like grub.cfg), each boot entry is a separate .conf file.

:open_file_folder: Key Directories & Files

Path Purpose
/boot/efi/ EFI System Partition (ESP) mount point (VFAT)
/boot/efi/EFI/systemd/ systemd-boot binaries (systemd-bootx64.efi, shim.efi)
/boot/efi/EFI/opensuse-slowroll/ Kernels + initrds for each snapshot
/boot/efi/loader/entries/*.conf Boot entries (one .conf per kernel/snapshot)
/boot/efi/loader/loader.conf Global settings (timeout, default entry)
/etc/kernel/cmdline Central kernel command line (used by sdbootutil)
/etc/sdbootutil.conf sdbootutil configuration

:vs: Major Differences: systemd-boot vs GRUB

Feature GRUB systemd-boot
Configuration Single grub.cfg (generated) Multiple .conf files (one per entry)
OS Detection os-prober scans all partitions No auto-detection; only entries on ESP
Kernel Location Can be on encrypted /boot Must be on unencrypted ESP (VFAT)
Multi-OS Support Yes (detects Windows, Ubuntu, etc.) Limited (manual entry required)
Btrfs Snapshot Support Via grub-btrfs Native (entries per snapshot)
Boot Speed Slower (more complex) Faster (minimalist)
Secure Boot Works via shim Works via shim
Firmware BIOS + UEFI UEFI only
Command-line Tools grub2-mkconfig, grub2-install bootctl, sdbootutil, kernel-install
Customization Highly flexible Limited (minimalist design)

:hammer_and_wrench: Key CLI Tools

Tool Purpose
bootctl Low-level systemd-boot management (status, install, update)
sdbootutil openSUSE-specific wrapper for managing entries, snapshots, and kernel parameters
kernel-install Standard BLS tool for adding/removing kernel entries
efibootmgr Manage UEFI firmware boot entries (NVRAM)

:memo: How Boot Entries Are Generated

  1. Kernels installed → Files placed in /boot/efi/EFI/opensuse-slowroll/
  2. sdbootutil reads /etc/kernel/cmdline for global kernel parameters
  3. Entry .conf files are auto-generated in /boot/efi/loader/entries/
  4. Each entry corresponds to a Btrfs snapshot
  5. bootctl displays the active boot entries

:warning: Key Limitations Discovered

Limitation Impact
No os-prober equivalent Ubuntu doesn’t appear in menu; must be added manually
ESP space constraints Multiple kernels + initrds fill small ESP (260 MB)
Encrypted swap + Secure Boot Hibernation requires Secret Key (/sys/firmware/efi/secret-key/regen)
Manual chainloading for other OS Need .conf entry pointing to \EFI\ubuntu\grubx64.efi
Kernel parameters via /etc/kernel/cmdline Centralized, but only affects new entries

:arrows_counterclockwise: Workflow Differences

Action GRUB systemd-boot
Add kernel param Edit /etc/default/grub → update-grub Edit /etc/kernel/cmdline → sdbootutil mkinitrd
Detect new OS os-prober + update-grub Manually create .conf in /boot/efi/loader/entries/
Remove entry Edit /boot/grub/grub.cfg (not recommended) Delete .conf file from loader/entries/
Set default GRUB_DEFAULT= in /etc/default/grub default= in /boot/efi/loader/loader.conf

:bulb: What This Means for You

  • systemd-boot is leaner and faster but less flexible for multi-OS setups
  • openSUSE’s integration with Btrfs snapshots is seamless and powerful
  • Manual intervention required for Ubuntu detection (unlike GRUB’s os-prober)
  • Encrypted swap + Secure Boot caused hibernation issues (kernel lockdown)
  • XBOOTLDR partition would solve ESP space constraints if needed

:brain: Tools & Commands Recap

# View boot entries
bootctl status

# List all entries
ls -la /boot/efi/loader/entries/

# Add kernel parameter permanently
echo "resume=/dev/mapper/swap_crypt" | sudo tee /etc/kernel/cmdline
sudo sdbootutil mkinitrd

# Manually add Ubuntu entry
sudo nano /boot/efi/loader/entries/ubuntu.conf
# Content: title Ubuntu, linux /EFI/ubuntu/grubx64.efi

# Remove rEFInd leftovers (if any)
sudo efibootmgr -b 0004 -B   # Replace with actual boot number
2

Simply stating this doesn’t do justice to other limitations consequent:

  1. Forcing all kernels and initrds per computer onto one separate filesystem can be a seriously dubious configuration for multibooting of more than just Linux plus Windows. A “generous” initially sized ESP could easily turn grossly inadequate to task trying to fit more than 2-3 kernels per installation.
  2. The non-native VFATs have their own limitations, not the least of which is absent symlink support.
  3. Have fun customizing/manually maintaining entries, which Grub facilitates (/etc/grub.d/40_custom and /etc/grub.d/41_custom+/boot/grub2/custom.cfg). IOW, the system for practical purposes depends on automation.
1 Like
3

Your absolutely right. I feel uneasy as well with the path the UAPI specification https://uapi-group.org/specifications/ is guiding us. But with my own endeavor to create and AI stack on for the Inter Ultra 5 architecture, I ended up installing Slowroll & Ubuntu 26.04. And Slowroll installed the systemd-boot for me.

4

Because it’s the default, but you didn’t have to let it.

1 Like