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

[starshipeleven]

And they made it like that because they wanted to support _every_ use case in a single boot loader. I mean, I agree, it _is_ a small OS — but it's not complicated because they wanted it to be complicated, it's complicated because it does too much, and doing everything they want it to do basically _requires_ a small OS.

Yes, I'm saying that they added a bunch of useless garbage to what should have only been a bootloader. Same issue of Xorg.

Meanwhile it is unable to do basic stuff like scanning on boot for bootable systems (unless it is scripted to do so, see SuperGrubDisk iso files), it's GUI sucks, and relies on static configuration.

[caligula]

and a lot of legacy BIOS implementations can't boot from GPT.

OTOH, GPT allows having a compability mode where you have both MBR and GPT structures on disk. Also half of the boot process can reside on a GPT disk, since BIOS routines are not used after the kernel has been loaded and started.

[starshipeleven]

I can't wait until ARM UEFI become the norm, i would love to kill uboot with fire and dance naked around it while it burns

uboot can boot UEFI linux with dts support since 2016 or something.

The issue is the hardware manufacturer that does not give a shit, which is also the cause for "ARM UEFI becoming the norm" remaining a dream.

[caligula]

GRUB is only complicated because it's trying to support every bit of hardware (BIOS, EFI, etc) from the last few decades, dealing with an accumulated history of edge cases. So yeah, it wouldn't necessarily be a bad thing to have one specialised EFI loader and one specialised next-gen loader, etc, if that makes them easier to maintain than a consolidated codebase that tries to support everything.

GRUB has a plugin architecture with sound drivers. It's an overcomplicated POS.

[skeevy420]

Just for future reference, GRUB won't boot any modern version of ZoL unless you force the creation of the pool to the oldest version(5000) but if you ever upgrade your pool be prepared for a surprise, also GRUB won't boot encrypted roots, etc. etc. etc.

If you have a recent UEFI system(even my b85/970fx oldest motherboards work like a charm with sd-boot) use sd-boot, this little wonder even boot ZFS through ISCSI.

I can't wait until ARM UEFI become the norm, i would love to kill uboot with fire and dance naked around it while it burns

It should work, we just have to either use a ZFS passphrase set to prompt (we should get nagged when the initramfs tries to mount it) or create the zpool with a key file and use that in the initramfs to unlock root and then encrypt /boot with a LUKS passphrase so you don't defeat the purpose of encryption with an auto-decrypted root. GRUB also doesn't support LUKS2 so, yeah, keep that in mind as well. I don't have step-by-step instructions for those so don't ask. Just stuff I've read over the past couple of months from random places I don't remember.

Either method is major pain in the ass for people forced to use GRUB and, with the current state of GRUB and ZFS, IMHO, we're better off going with AnyOtherFS and LUKS1 for /boot and AnyOtherFS and LUKS2 for the of root and ZFS for non-standard directories like my /multimedia directory that's a zpool with all my games, music, and videos -- that's coming from someone using ZoL since the 0.6 series.

As much as I love ZFS, it's a freaking hassle to use as root or boot.

[skeevy420]

Michael

I have no idea why my most offensive posts almost never get flagged and stuff that shouldn't be offensive at all does

FWIW, I think it's funny that the filter is sentient with an odd sense of humor.

[skeevy420]

Maybe you should establish a computer museum?

See posts 15 and 28 of this thread and you might get a good laugh at my expense.

[AsuMagic]

If Poettering wants to improve the quality, he should submit patches that do so. It is less work (and less wasteful and disruptive) than starting his own boot loader.

Not when GRUB is just bad by design.

[Sniperfox47]

Eh with the Linux kernel EFIstub I no longer need bootloaders, so whatever

i mean, unless you want a way to conveniently edit kernel parameters before boot. My motherboard has a decent UEFI boot selection, but I still use rEFInd so that if something goes weird I don't need to manually edit the boot entry for my Linux distro.

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

BIOS and EFI/UEFI are firmware specifications. Yes.

MBR and GPT are disk partition layouts. Yes.

But you're missing the point that MBR and EFI are both boot file specifications, where MBR is the boot record of an MBR *or GPT* disk and EFI has a standard for specially identified partitions with files in it.

You can have an MBR on a GPT disk and boot it from a UEFI firmware.

You can have an EFI partition on an MBR disk.

MBR has two meanings. The Master Boot Record itself, and the type of partition layout designed to contain it.

[beniwtv]

i mean, unless you want a way to conveniently edit kernel parameters before boot. My motherboard has a decent UEFI boot selection, but I still use rEFInd so that if something goes weird I don't need to manually edit the boot entry for my Linux distro.

I can still edit the parameters via EFI shell - or even manually run the Linux kernel from withing the shell. You can even have am EFI shell on a USB key or another partition should your motherboard not come with one.