Ubuntu's ZFS Trajectory Is Going From Exciting To Even More Exciting

[starshipeleven]

Is simple, BIOSes are hard, dumb and never had any sort of standard to do handoff to boot the the kernels

Sorry what? They read from MBR, you put your bootloader code there.

so projects like GRUB growed into such monsters because they had to replicate kernel functions to set an environment good enough to handoff the boot process to the kernel.

For example:

• Grub actually need a proper filesystem to read the filesystem where the boot partition is to be able to exec the kernel, if the filesystem doesn't match it cannot handoff the boot to the kernel because it cannot see it, see is a circle.

This is the whole point of second-stage bootloader code. I'm not sure what is wrong with a bootloader having filsystem drivers to read the kernel from a partition.

It's total bs like rich commandline environment for scripting support, sound support and other things that have no bearing in a bootloader, but are of course available in GRUB.

It also needs to hack around the very basic old-school garbage display interface provided by the BIOS to have a semblance of GUI when in fact it still is a text-mode bootloader.

is not that easy for the GRUB to keep current.

Not really. Bootloaders need a much smaller and simpler driver, in most cases they only have/need read-only drivers, and high performance or concurrent access is not important either so you can write cheap and simple code.

It's more like ZFS developers just don't care about GRUB, or GRUB developers don't merge things for years (which is a known issue), and everyone else accepts this because it's just easier to make a boot partition than write code or force GRUB devs to do their job faster.

For BSD for example they use their own bootloader https://reviews.freebsd.org/source/s...ad/stand/i386/ for both BIOS and UEFI
I don't know if they support all features required, but afaik all serious NAS appliances using ZFS are using a dedicated root partition (either with or without ZFS), where they can probably not enable anything the bootloader does not support.

For everything else (Linux/Mac) they make boot partitions, or keep the root filesystem separate from the data filesystem.

UEFI on the other hand is really dumb and simple with a proper standard,

Dumb and simple my ass. It's a whole OS with an API for EFI applications to show a good-looking GUI, and driver support. https://efi.akeo.ie/

so basically you need a fat32 partition on GUID that contains the loader and a kernel, then the kernel and initramfs do wathever they need to do to boot,

This is also called "boot partition". A partition that is mounted as the /boot folder and contains kernel and initramfs and other boot-critical files.

[starshipeleven]

you can do it as long as you create the pool with version 5000 and never run zpool upgrade -a, once you enable encryption/largednodes/special_small_blocks among others grub stops seeing the partition and bye bye boot.

Also i'm not sure if proxmox is using an older version of ZoL to avoid breaking grub like 0.6.9 series or is using another implementation through FUSE

Proxmox is using modern ZoL but it is using a dedicated root partition (RAIDed or not), where it does not enable any feature Grub does not like.

The ZFS storage pools are different.

[DrYak]

BTRFS, ZFS, Stratis, & LVM+LUKS, basically every & all Linux advanced file system, have issues in regards to bootloaders, supported features, and works everywhere/universal -- Pick two, nothing modern and up-to-date on Linux applies to all three.

Which is why they went for grub-in-ext4. If you have more than one distro (say ubuntu {zfs}, opensuse tumbleweed {btrsfs}, fedora {stratis} and whoever is Bcachefs' sponsor), and grub is a zfs partition, only ubuntu would be able to change it's configuration.
If grub is on an ext4 partition any other OS would be able to change it. You could even edit your boot setup from Windows (using some ext4 drivers).

Is simple, BIOSes are hard, dumb and never had any sort of standard to do handoff

Well actually, they have some standards, it's just that this standard is so old and simple that it's nearly useless in the modern world (It can't be aegued. They ARE "hard and dumb")

- They load sector 1 of the boot drive
- They jump into it (while leaving a couple of information like the drive number)
- BIOS interrupts are available for some basic i/o (hence the name). Such as 13h for a few sectors read and write (and 10h for pushing some characters to the screen).
That's it.

It might have seemed acceptable back when 8-bit microcomputers were the norm and IBM PC was a powerhouse with its 16bits.
(Hey lots of early IBM PC games were booters: this first sector just further load other sectors and that's the whole game memory image. No filesystems or partitions whatsoever)
But it's completely in-adequeate nowadays. Basically you need to carve a whole loader out of basic BIOS calls.
Hence GRUB as you said.

But from that point of view BIOS are standard, they just are completely anachronistic, only providing you functionality straight out of the 1980s.

UEFI on the other hand is really dumb and simple with a proper standard

UEFI isn't all that dumb. UEFI is basically it's own mini-OS, somewhat like GRUB.
It doesn't stick to basic "load a sector and jump" and "BIOS int calls to read/write sectors".
It has a notion of filesystems, files, executable commands. It can even optionally have a shell.
Booting a kernel is literally just executing an efi executable which happens to be the kernel.

The only difference with GRUB is that UEFI isn't as advanced it can only read FAT32 partitions.
But they both cover the "being its own mini OS" part.

[starshipeleven]

The two prominent ones for desktop users are systemd-boot and GRUB. systemd-boot basically omits any non-systemd distribution

complete bullshit, systemd-boot is completely unrelated to systemd init https://wiki.archlinux.org/index.php/Systemd-boot

How come it isn't possible to sort of emulate the UEFI method by having the mbr load an interface and init kernel from a fixed-size fat32 or ext4 partition and then using that init kernel+ramdisk for feature support?

Are you aware of this revolutionary concept called "boot partition" https://docs.fedoraproject.org/en-US...mmend-x86.html https://en.opensuse.org/SDB:Partitioning ?

Which was available as far back as 9 years or more as a way to work around bootloader limitations? https://superuser.com/questions/6601...boot-partition

https://askubuntu.com/questions/6490/is-a-boot-partition-necessary-anymore

[linuxgeex]

re: the whole grub issue... I miss the days when I just configured the bootstrap devices as NOT modules, and set the root partition via KConfig, then ran `make zimage; cat zimage >/dev/boot` (which was a symlink to the device with the MBR) and that was it.

That booted very fast becuase the BIOS loaded the kernel directly, and the kernel loaded init directly. All the system config choices were made before boot time so there was nearly no probing necessary, no dependency checking, no initializing of 100 irrelevant modules just in case.

Of course, you didn't have a boot menu, your failover options were much more limited, your recovery options were much more limited, and every time you wanted to change a kernel commandline option you had to rebuild the zimage and write it to the boot volume. If you had boot hardware that depended on a driver that had to be built as a module then you needed to use an initrd, but then you could append it using `cat zimage initrd /dev/boot`but there was no sanity check for whether the boot volume was large enough to hold the kernel and initrd lol.

[Chugworth]

Wait, why are we still worrying over boot loaders? Now that we have UEFI (or at least, properly implemented UEFI), there's no need for them. Just use the EFISTUB method. And if you want to select from from multiple operating systems, use the system's boot menu.

[stormcrow]

[stuff]

UEFI on the other hand is really dumb and simple with a proper standard, so basically you need a fat32 partition on GUID that contains the loader and a kernel, then the kernel and initramfs do wathever they need to do to boot, hence systemd on UEFI is able to boot anything simply because the handoff is done form the UEFI to the kernel directly and the kernel knows exactly what to do from there regardless of features

That's the ideal. The reality is there's just as much brokeness with UEFI implementations as there was BIOS. I'd love to get rid of Grub, too, but I doubt you'll get rid of it and rely on UEFI's boot sequence without a working shim to adjust for quirks when it's just as likely to have problems as BIOS+Grub. Case in point, I have an MSI AMD Ryzen board that used to fail to boot if it had more than one EFI entry on the FAT32 partition. It would silently drop to the firmware config screen. Took MSI several months to fix that and only after I pointed out the bug would affect multiple Windows installations as well as non-Windows OSes. It was a silent fix too. They never acknowledged the bug. It just magically got fixed in a firmware upgrade.

[starshipeleven]

Wait, why are we still worrying over boot loaders?

raw UEFI is fine for basic setups, but if you want to boot into a snapshot, or a FreeBSD's ZFS "boot environment" equivalent, or whatever is Stratis's equivalent you will still need something better.

And if you have a RAID, relying on UEFI stub is a pain in the ass as you would need to update the same EFI partition in all your drives and keep it updated every time you update the kernel. While with (decent) bootloaders like rEFInd this EFI partition is static, do it once use forever.

Also the amount of UEFI firmware that still sucks out there is staggering.

[Cherijo]

Wait, why are we still worrying over boot loaders? Now that we have UEFI (or at least, properly implemented UEFI), there's no need for them. Just use the EFISTUB method. And if you want to select from from multiple operating systems, use the system's boot menu.

UEFI hasn't been implemented universally for that long. There are still perfectly viable systems out there that exist and rely on BIOS. I'm personally running a NAS based on my 10+ year old Q6600 on a P45 Mobo. I already had it sitting around, and it's perfectly capable as a local media NAS still for my needs. That means if it's on my network, it needs good, current, relevant security patches and a modern OS if at all possible. Hence, we still need bootloaders that play well with BIOS.

[johnc]

I wonder if they will be making some kind of Time Machine-like application for desktops.