Lennart Talks Up systemd's SD-Boot + Boot Loader Specification

[skeevy420]

Oh wow, grub capable running systemd! Doesn't sounds weird: boot loader that grown to almost OS would meet system manager that is also almost grown to OS.

No, not really if you think about it.

GRUB is so bloated and supports a bunch of stuff because of how old it is. As file systems and OSs gain features, so did the bootloader because that's how it traditionally worked since they (bootloaders) weren't working off of what the kernel supported like sd-boot does now.

Systemd supports a bunch of stuff because an init system, ideally, should be smart enough to understand WTF it's trying to initialize because the alternative is writing scripts and hoping you don't f*ck up and start stuff in the wrong order.

[SystemCrasher]

Nothing in the UEFI spec suggests you use UEFI this way, and these devices using it in this way says nothing about the UEFI spec since literally any firmware spec can be used this way.

Still, that spec has been designed by wintel clique to fit their bill. It gone as badly as using M$ executable formats to make M$ little favor. Oh, should I tell "MZ EXE" dos stub in uefi things looks so funny, granted DOS can't even boot UEFI ways? And even ARM or RISCV supposed to enjoy that MS's DOS legacy if I got idea right. Despite they were never even able to boot DOS in first place, MSDOS never ran on these.

[SystemCrasher]

Why doesn’t Lennart contribute improvements to Grub?

Oh wow, grub capable running systemd! Doesn't sounds weird: boot loader that grown to almost OS would meet system manager that is also almost grown to OS.

[Sniperfox47]

Right. Just please don't say "There's 0 need to get it signed by Microsoft." if there is millions of devices that enforce Secure boot and require bootloader signed by Microsoft.

There is 0 need to get your bootloader signed by Microsoft *for UEFI*.

You can't take my comment out of the context of the entire conversation we'd been having up to that point lol. The discussion was not about the controversy of these devices, but rather the controversy of UEFI.

Nothing in the UEFI spec suggests you use UEFI this way, and these devices using it in this way says nothing about the UEFI spec since literally any firmware spec can be used this way.

[RussianNeuroMancer]

That's not a thing specific to UEFI.

Right. Just please don't say "There's 0 need to get it signed by Microsoft." if there is millions of devices that enforce Secure boot and require bootloader signed by Microsoft.

[Sniperfox47]

Except you can't sign it yourself on WinRT tablets, Nokia Lumia smartphones and on HP Elite x3. Only bootloader that starting on these devices is one that signed by Microsoft.

I get what you want to say and this is true on most of PC, but not on 100% of PC (WinRT tablets is x86 PC too).

And what does that have to do with UEFI? That these devices don't support anything other than Windows is an issue with these devices, not an issue with UEFI. You can create boot signature requirements with BIOS. You can create boot signiture requirements with any other firmware. That's not a thing specific to UEFI.

Windows RT is not UEFI. Windows Phone is not UEFI. They use UEFI but they don't define it. These devices are small integrated embedded devices with limited TPM capabilities that use UEFI in a non-standard way. That in itself says nothing negative about the spec.

People who hate on UEFI for how Microsoft abuses it are as ridiculous as the people hating on USB-C over the fact that the Raspberry Pi Foundation couldn't be halfassed bothered to follow a circuit diagram properly. A shoddy implementation says nothing about the spec.

[RussianNeuroMancer]

And even if you enable secureboot you can sign it yourself, or using a public key from your distribution. There's 0 need to get it signed by Microsoft.

Except you can't sign it yourself on WinRT tablets, Nokia Lumia smartphones and on HP Elite x3. Only bootloader that starting on these devices is one that signed by Microsoft.

I get what you want to say and this is true on most of PC, but not on 100% of PC (WinRT tablets is x86 PC too).

[Sniperfox47]

I remember the outcry when UEFI was introduced and with all it's problems, bugs and unclear privileges in implementation. And the way it has to be signed(by Microsoft).

What problems are those?

Bugs? Was it really any worse than half the BIOS builds out there?

And what do you mean it has to be signed? It doesn't since UEFI doesn't require secureboot and every motherboard I'm aware of, even really early ones, offer the option to disable it entirely. And even if you enable secureboot you can sign it yourself, or using a public key from your distribution. There's 0 need to get it signed by Microsoft.

Well Fedora didn't even support EFI before 2012 and now some people want to cut "legacy" support for older mainboards or what?

Again, what are you talking about? Nobody's suggesting legacy MBR bootloaders like GRUB be discontinued.

The only argument here is that it's okay to spin a seperate bootloader (sd-boot) for UEFI and makes sense to do it, and the GRUB-EFI is a terrible bootloader and a waste of effort on the developers standpoint.

If you're on a BIOS system keep using GRUB. It does it's thing just fine. It's obtuse and overly complicated, but it works.

If you're on a UEFI system there are much better bootloaders for you than GRUB-EFI.

[Julien Bear]

I remember the outcry when UEFI was introduced and with all it's problems, bugs and unclear privileges in implementation. And the way it has to be signed(by Microsoft).
Well Fedora didn't even support EFI before 2012 and now some people want to cut "legacy" support for older mainboards or what?

[boxie]

MBR is a disk partition layout, EFI is a firmware specification. You've probably switched from MBR to GPT? GPT works without EFI, too.

Well, yes I messed up my terms. All the warnings about MBR/EFI made me follow the bouncing ball from MBR/BIOS to GPT/EFI.