systemd Lands SD-Boot, Its EFI Boot Manager & Stub Loader

[phoronix]

Phoronix: systemd Lands SD-Boot, Its EFI Boot Manager & Stub Loader

A few weeks ago I wrote how systemd developers were planning to add Gummiboot as a UEFI boot manager to systemd. Now, following the just-released systemd 219, they've gone ahead and added their initial code for providing systemd with a EFI boot manager...

http://www.phoronix.com/scan.php?page=news_item&px=systemd-SD-Boot-EFI-Boot

[BlackStar]

Phoronix: systemd Lands SD-Boot, Its EFI Boot Manager & Stub Loader

A few weeks ago I wrote how systemd developers were planning to add Gummiboot as a UEFI boot manager to systemd. Now, following the just-released systemd 219, they've gone ahead and added their initial code for providing systemd with a EFI boot manager...

http://www.phoronix.com/scan.php?pag...-Boot-EFI-Boot

Finally, a sane way to manage bootloaders.

GRUB2 configuration sucks beyond imagination.

[duby229]

Finally, a sane way to manage bootloaders.

GRUB2 configuration sucks beyond imagination.

I don't care much for grub2 either. I'm still using grub0.97 on bios systems. I am using grub2 on efi systems, but I don't like it much.

If only systemd would put it's component parts into their own repositories and make them function outside of systemd. I do like the idea, but I don't like the implementation.

[xeekei]

I'm more of a Syslinux guy myself. I don't got any UEFI systems yet, but I'll try Gummiboot when I get one.

[blackout23]

So will gummiboot be removed from it's original source on the freedesktop git repo? I wonder what will happen with the gummiboot Arch Linux package, which I have currently installed. Really great EFI Loader just as KISS as Syslinux which I use on my BIOS systems.

[Ericg]

So will gummiboot be removed from it's original source on the freedesktop git repo? I wonder what will happen with the gummiboot Arch Linux package, which I have currently installed. Really great EFI Loader just as KISS as Syslinux which I use on my BIOS systems.

What happens to gummiboot is up to Key Sievers since he is the author of gummiboot. I'm going to -guess- that it will be dropped in favor of sd-boot, but if someone wanted to pick up gummiboot they could.

[zanny]

Pretty much the only good thing about UEFI is how it can stub load kernels. Why the hell are the systemd guys trying to go backwards here? Every EFI implementation needs to provide its own boot menu, having two by having another boot loader after it is redundant, wasteful, and stupid.

It is also complacent of every Linux desktop to continue just pushing grub2-efi on everyone even though we have had stub kernel boot support for years. Generate EFI table entries for the current kernel, the fallback, and the old versions, or at least let people pick that option in GUI installers.

Yes, I realize most EFI implementations are completely broken so this "feature" doesn't actually work. For example, my Asus z87 motherboard cannot have more than one EFI table entry or else it overrides the first one with the newest one. Then again, I have never had booting fail on this system in two years due to kernel updates or anything in my initrd, and I'm wondering why the practice is still in place of having all these redundant kernels around or even fallback ramdisks when you could just throw the maintenance tools in the primary ramdisk (my initramfs is 3.4MB, my fallback is 18MB, peanuts to an SSD or even a reasonable mechanical disk). I have not yet encountered an EFI implementation that cannot have at least one entry in its EFI table that is preserved across boots, which would let you boot your kernel.

At least make it an option, the technology has been around for years and nobody is using it, yet I have used EFI boards from Asrock, MSI, Asus, and Gigabyte and all of them at least let you enter one table entry and boot it. If there is no adoption there is also no reason for these companies to make their EFI boot tables not broken as hell.

No idea why anyone thinks its a good use of time to write another redundant step in the boot process and inject it in systemd, though.

[adler187]

I don't care much for grub2 either. I'm still using grub0.97 on bios systems. I am using grub2 on efi systems, but I don't like it much.

If only systemd would put it's component parts into their own repositories and make them function outside of systemd. I do like the idea, but I don't like the implementation.

The code is from Gummiboot, which already exists outside of the systemd repo and doesn't need systemd at all, so I don't understand your point.

[duby229]

The code is from Gummiboot, which already exists outside of the systemd repo and doesn't need systemd at all, so I don't understand your point.

You don't get the point of this announcement,

The point is that gummiboot is now going to be sd-boot. Which means that further improvements are going to happen in a systemd specific environment. Sure someone can fork gummiboot right now while it still makes sense to do so, but most of the time forks are bad. All a fork would do is cause even more duplication of effort. Systemd causes enough of that already, we certainly don't need more.

[gnufreex]

I will move to systemd haters camp if it this stuff is installed by default in Fedora instead of GRUB.