SystemD-Boot Adoption by Linux May Cause Problems

[MarioG-X]

Dakanji, this may be of interest to you. You may want to follow this issue I opened, it’s opensuse/tumbleweed but seems other distros may be implementing. A big pain if not resolved by the Linux folks. Affects what’s in or I should say no longer in /boot.
https://bugzilla.opensuse.org/show_bug.cgi?id=1226122

[dakanji]

Thanks. Cannot wrap my head around the subject though. Might need to go upstream.
Let me know if/when there is a clear and straightforward change that can be done.

[MarioG-X]

dakanji, you may want to follow this (long) issue because they are asking me questions like "does refind support snapshots" which I had to make assumptions about. They also want to make sure you maintainers are aware of the Linux (ALL distros apparently) are moving to sdboot. See my posts for today about assumptions regarding snapshots and secure boot which I can't answer.

[dakanji]

Took a quick look and don't know what sd-boot etc is. If the stuff is regular bootable stuff in normal locations, then might possibly be found.

Otherwise, will have to wait for upstream to tackle the problem if they insist on turning things on their heads and wantonly breaking stuff. Didn't realise Linux was like that ... might just be this one going rogue I suppose.

As an aside, RefindPlus is one word and has no space between Refind and Plus.

[MarioG-X]

Forgot to mention I sent the same info to Rod at Refind. According to the Opensuse people, all Linux's are converting to sdboot to support snapshots, secure platforms and disk encryption. Sounds like Refind is going to need big changes because even if Opensuse uses my "compatibility boot install mode", other distros will not. I will be testing sdboot when they officially add it (it's beta for now) and let you both know what happens.
BTW, RefindPlus is not the only thing autocorrect "fixes", I need to keep an eye on that. I think it's a GitHub thing since it does not happen here.

[dakanji]

Sounds like rEFInd/RefindPlus are going to need big changes

I don't think so.

Arch Linux apparently already has sd-boot and is also able to distribute rEFInd without issue

• https://wiki.archlinux.org/title/systemd-boot
• https://wiki.archlinux.org/title/REFInd

Not sure when Arch put it in, but I see Ubuntu apparently added sd-boot back in 2012.
This means tons of distros based on these already have sd-boot in place and everything works without issue.
It is probably the case that almost every distro out there already has this and your fav one is just playing catch up.

The point therefore is that breaking stuff for sd-boot is not a REQUIREMENT but a CHOICE, presumably an unconscious one in this case but more on that later.

if Opensuse uses my "compatibility boot install mode", other distros will not.

From what I can see, ignoring that sd-boot has been in place on some key distros without issues, I think the whole "problem" here might not be rEFInd/RefindPlus related.
That is, you have some specific wants and your preferred distro has made some changes that impact these.

The changes they have made do not fundamentally impact running RefindPlus, emphasis on fundamentally, but you will need to make changes to fit.
From my skim through the issue, it appears the main "problems" are:

• Their installer/updater overwrites Bootx64.efi when you do not indicate you do not want a bootloader.
  • This appears to be a systemd default and you need to either indicate you do not want a bootloader or handle the boot coup afterwards.
    • A boot coup is when an item, not wanted as a default boot item, takes over the start up process.
    • This rogue item is then booted instead of an expected item whenever the unit is started.
  • Handling boot coups is an inherent part of using rEFInd/RefindPlus and there is a page dedicated to this in the rEFInd docs
    • Boot coups are not considered to be breaking rEFInd/RefindPlus but an inconvenience to be managed
• Their installer/updater does not populate /boot when you indicate you do not want a bootloader.
  • It seems somewhere else, /boot/efi perhaps, is populated instead.
  • While you might have an issue with that due to partitioning etc needs, rEFInd/RefindPlus do not and will happily work.
  • So whether /boot or some other location is populated with what needs to be booted is not really an issue for rEFInd/RefindPlus
  • Worse case, you add that location to the scan list.

So, from what I can see, there is nothing inherent in the sd-boot implementation that requires any changes to rEFInd/RefindPlus.
This is not to say they shouldn't make different CHOICES with how their installer/updater does things

I might be wrong though and Upstream, which is hardcore Linux, might feel something needs to change.
In this case, it will be adopted here

EDIT.
You might want to refer the chap that said rEFInd is not distributed officially by any distro to This Wikipedia Link on Its Adoption.
I see Arch, Debian, Ubuntu and Gentoo. Pretty sure all these "Backbone Distros" all already have sd-boot going.

[MarioG-X]

Wow, thanks for all that info! I added a link in that thread to your comments. Sounds like it may not be so bad, just an extra ESP for each linux, and add option to not modify NVRAM. Previously installing TW without a boot manager worked. That no longer works so you have to pick one, sdboot would be OK except it modifies nvram. Yes I could put an extra hour or two each time to fix refind, RP, and opencore, which is often due to Tumbleweed updates to kernel, etc. If they add the option to install sdboot and not update nvram like in grub, that would be much better.

[dakanji]

I suppose it will have to wait for what Upstream thinks to be 100% as I am not particularly a Linux Guy but my impression is that things should work.

The nvRAM bootorder change is a nuisance that many Linux distros appear to come with and an option to skip this would be great indeed.
The "compatibility" style setup might be a good idea and easy to do since you said it just needs activating an option. The installer could do this.

The really bad stuff is overwriting BOOTx64.efi but from what I could gather, this decision was made by Systemd and perhaps downstream devs just have to go with the flow.

I saw on the Systemd site that they wrote that they are aware this could wipe out Windows bootloaders but they didn't seem to give two figs. From other posts by systemd haters that I saw elsewhere, the decision to just wipe stuff out like that is not surprising.

As you pointed out in the openSUSE issue thread, Systemd just assumes it is the only thing present and everything else be damned. Windows style as you said.

It could be that a downstream installer/updater preserves any existing BOOTx64.efi files before overwriting with the systemd-bootx64.efi file.
If they do, you could go in afterwards and manually restore easily but I don't think they would.

[MarioG-X]

Thought you might to see my update, your pointing me to the boot coup page really helped simplify things. The great news is that RefindPlus works perfectly with systemd-boot here.
https://bugzilla.opensuse.org/show_bug.cgi?id=1226122#c66

[dakanji]

Thanks. Good to know.

[mwilck]

Here's the "chap that said rEFInd is not distributed officially by any distro". 😄 ¹

It is true that on openSUSE, the boot loader installation is special, in particular for sd-boot. We have created a special tool, sdbootutil, to help with that. The reason is that one of the key features of openSUSE is the ability to boot from previous btrfs snapshots. EFI file systems don't support snapshots, so we had to come up with additional functionality to be able to boot snapshots with sd-boot.

Footnotes

1. That's not quite what I said, my statement was that "not a first-class citizen in most Linux distro" (which isn't the same thing as being distributed, especially for a boot loader), but even that may be wrong. I admit I did only a superficial search, and only found the Ubuntu ppa. Sorry for that. ↩

[dakanji]

Nice of you to stop by.

I gather that the feared issue(s) did not materialise. I suppose that, in hind sight, this was not surprising given that SD-Boot is actually the now obsolete GummiBoot taken forward. A search of the rEFind/RefindPlus codebase will reveal multiple references to GummiBoot.

They even share the same "RubberBoat" icon...
https://github.com/dakanji/RefindPlus/blob/GOPFix/icons/os_gummiboot.png and https://github.com/dakanji/RefindPlus/blob/GOPFix/icons/os_systemd.png

Of course having an icon meant that systemd was actually already well understood and catered for.
https://www.rodsbooks.com/efi-bootloaders/gummiboot.html

---

As for BtrFS Snapshots, rEFInd, and RefindPlus by extension, can boot such but they need to be added to and removed from user defined stanzas as they appear and disappear.

Would be a pain to do manually but there is a tool to automate things: https://github.com/Venom1991/refind-btrfs. It is Arch focused in terms of packaging etc but I suppose can be installed on any other Linux type being Python based.

Anyway, thanks again for taking the time to drop a line!

[mwilck]

Wrt openSUSE's efforts to ship rEFInd, first and foremost it depends on some community member to create a package (as I told @MarioG-X already ;-) ).

Whether it will ever be a first-class citizen among the bootloaders supported by the distribution is currently not likely (it would need to be embraced by the distro architects, which are currently busy integrating sd-boot+sdbootutil), but packaging it would obviously be a prerequisite for taking further steps.

[MarioG-X]

Hi Dakanji, Martin asked questions about RefindPlus I cannot answer, would you mind answering the 3 questions below? I will post your response (or link) in that forum. Thanks!

1. > Am I understanding correctly that rEFInd will not chain-load sd-boot, but will detect and boot the kernel(s) installed by sd-boot directly?

No, it appears that Refind DID find sd-boot, and I tested it. So far so good.

2. > How does rEFIind handle secure boot? For secure boot to do what it's supposed to, rEFInd should refuse to load any kernel (or other EFI binary)

3. > Also, I'm wondering about the kernel command line, which is ususally configured in /etc/default/grub. Does rEFInd have some logic to obtain the command line suitable for the given distribution from the distro's config files, or does it use the same command line for all kernels it finds?

[dakanji]

@mwilck and @MarioG-X ... It seems this item has run its course from a RefindPlus point of view and that things should now be funnelled to rEFInd directly.
However, here are some responses for what they are worth.

Package Manager Support

While looking through some old commits into rEFInd, the heavy lifting for the first time it got packaged seemed to have been done by someone from Debian. Presumably provided a base for subsequent packaging for others. Definitely one for the rEFInd project to take on (if interested) given the maintenance burden.

Direct/Indirect Kernel Loading

SystemD-Boot is just a bootloader and can therefore be chain-loaded, if a user wants, or a kernel loaded directly (that is, via the stub loader) if wanted. No difference to how things work with Grub.

Secure Boot Handling

Only signed stuff is loaded. Note that Shim hooks the UEFI LoadImage function and that descendant images basically load stuff via Shim (in simplistic terms).

Setting Kernel Options

I assume Command Line refers to Options. If so, then yes, these are either obtained dynamically from the distro's files or statically supplied by the user in program config files.

[dakanji]

🤡 Can't resist a Parthian shot at dear @mwilck 🤡

On this:

my statement was that "not a first-class citizen in most Linux distro"

That was a part of your statement indeed but your very next sentence was...

_{There's a PPA ... but no major distribution seems to ship it as an} official _{package, or even support it} officially _{as a boot loader}.

[mwilck]

Point taken. :-)

But are there distros that support it officially as a boot loader? In the sense that the distro installer would offer it as an alternative to, say, grub or sd-boot, in the boot loader configuration screen?

[mwilck]

SystemD-Boot is just a bootloader and can therefore be chain-loaded

@MarioG-X, would this be an option for you? It would be a cheap way to be able to boot from snapshots, for example, without rEFInd having to learn the entire logic that is necessary to support that feature.

No difference to how things work with Grub.

Forgive me, I know rEFInd only from what I gathered from @MarioG-X. I have zero practical experience with it.

Shim hooks the UEFI LoadImage function

I'd forgotten about that. Thanks for pointing it out.

I assume Command Line refers to Options. If so, then yes, these are either obtained dynamically from the distro's files

So reEFInd can parse grub.cfg? I'm impressed, seriously.

[dakanji]

Distros that support it officially as a boot loader

Every now and then, I get tempted to install Linux before giving up with my eyes glazed over after looking at some of the billion bewildering options and watching videos of people banging on about having to test Option 1,000,001 with the Gnome Desktop instead of the KFC Desktop or whatever they call it (Sprinkled with Cinnamon somethings apparently).

I mean, first you have a gazillion variants and each one has multiple options??? I end up sticking with a few I have on a Ventoy stick that a I play with now and then.

Anyway, I went through such a phase a few weeks ago and came across a video of one that had rEFInd in the setup screen as an option but can't recollect which one it was. Safe to say that no, it is not typically offered.

Parsing Config files

What it actually reads is a Linux kernel options file created by the installer or, if absent, automatically generated from /etc/fstab. Can also be generated by running a supplied mkrlconf script which parses /proc/cmdline. It previously got the options from Grub.

Example from someone's log:
Loading 'vmlinuz-6.7.4-1-liquorix-amd64' ... Load Options:- 'root=UUID=03a50d2d-fce0-4f8e-ab6c-9b4f509307f8 ro rootflags=subvol=@rootfs quiet initrd=@rootfs\boot\initrd.img-6.7.4-1-liquorix-amd64'

[mwilck]

I guess this is now moving off-topic... true, the high flexibility and configurability of Linux is daunting for novice users. Maybe you should try openSUSE one day 😁 Except for the partitioning, you'll hardly have to deviate from the defaults the installer offers.

But actually, the same should hold for most modern distros targeted at and users, like Ubuntu and its derivatives.

Perhaps you're watching the wrong channels on youtube 😁

What it actually reads is a Linux kernel options file created by the installer

That must be something specific to certain distros, I've never heard about it.
The default options for grub are stored under /etc/default/grub in a simple VAR="value" format, but reading that file requires support for native Linux file systems such as ext4 or btrfs. Only grub.cfg with its weird syntax is stored on the ESP.

Guessing options from fstab may work for determining the root FS, but not much more. And fstab must be read from native Linux file systems as well.

[dakanji]

That must be something specific to certain distros

"Installer" was referring to the rEFInd Installer which populates the Options file by running the mentioned script. The fstab bit is a minimal fallback if that was not done.

The script can also be directly run by users to properly populate the file and the file can be manually amended if wanted.
The script actually used to get the options from Grub but now parses /proc/cmdline

I guess this is now moving off-topic

It had run its course a while back as was stated earlier indeed

[MarioG-X]

dakanji and Martin:
As per my comment https://bugzilla.opensuse.org/show_bug.cgi?id=1226122#c66, RefindPlus was able to boot successfully, three different ways TW was installed without having to do any RefindPlus configuration.

1. It was able to boot TW installed with no boot manager as it always has
2. Also installed with systemd-boot, it found systems-boot, booted it, and SD booted TW
3. Finally, I reinstalled with grub2 EFI and RefindPlus could boot grub2->TW, and it also found TW /boot and could boot directly.

So far, I don't think anything needs to change in RefindPlus. Only TW needs to add an option to installer to not modify NVRAM when selecting sdboot. Turning off security boot was recently added and I tested.

However, I am not able to test secure boot since I don't have a machine with TPM. I use Macs.

[mwilck]

Thanks!

[dakanji]

can't recollect which one it was

Finally found which one it was .... CachyOS.
Shows rEFind, SystemD-Boot, Grub and something called AI-SDK Refind or similar as bootloader options when installing in UEFi mode.
Looks like it defaults to Grub for MBR. Did not notice option to skip Bootloader.

For reference for myself later.
Will take a closer look at some point.