Closed ghost closed 3 years ago
ghost
commented
3 years ago Of course, an alternative is using a boot loader that has full-fledged boot loader support. This way, /boot will no longer be separated from /. This project is ZFSBootMenu. But as this is a 3rd party project that has limited presence on distros, it's not used by official ZFS guides.
csdvrx
commented
3 years ago Hello
Arch does many things right - including explaining how to use an EFI payload using systemd stub+vmlinuz+initrd (+- cmdline to overcome some bios UEFI bugs), stored directly on the EF00 partition: https://wiki.archlinux.org/index.php/EFISTUB
Still, I can understand why someone may prefer to have a friendly boot menu, and refind is even more user friendly that grub.
However, having a separate ZFS boot pool just for that boot menu seems like a useless complication, only done to satisfy grub brokenness instead of adding a feature-complete ZFS support to grub (or refind).
In the 21st century, I personally believe we should deprecate grub and go full on with EFI. There is litteraly no reason (besides the pretty menu) to use grub:
recovering from a broken initrd is then easy, if 2 versions of the payload are kept at all times (current + previous known good) and both are registered with efibootmgr or refind: when deploying a new kernel version (or updating the initrd), if it fails to boot, one can select the previous one if the initrd includes efibootmgr or if the new payload is added as a "next boot" (temporary default) until it's confirmed to have booted correctly.
protecting the payload from tempering can be achieved with TPM, by signing the EFI payload with MOK keys: https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface/Secure_Boot#Using_your_own_keys
protecting the / key can be achieved by not storing the key inside the payload, but by prompting for the password instead - which is what LUKS does (there are various password prompters, some of which are graphical)
Yes, this requires doing things slightly differently (ex: efibootmgr in the initrd), but it is possible- I have scripts to do all this.
libreboot/coreboot can embed a payload in the flash, which make it much harder to tamper with - so unless the kernel can't fit in, there is no need to use Seabios to then use grub
grub can also be embedded in the flash as the default coreboot payload - but the few people doing something as exotic should consider fixing grub incomplete ZFS support instead of forcing it down everyone else throat!
Of course, an alternative is using a boot loader that has full-fledged boot loader support. This way, /boot will no longer be separated from /. This project is ZFSBootMenu. But as this is a 3rd party project that has limited presence on distros, it's not used by official ZFS guides.
I didn't know about ZFSBootMenu - even better if there is now a bootloader that has a feature-complete ZFS support!
I will have a closer look - if it can prompt for a dataset key, keeping a encrypted /boot dataset on the root pool might be a simpler solution for those who prefer keeping their vmlinuz and initrd separate.
Still, even leaving ZFS aside, I strongly believe that EFI payloads are simpler, so the initrd script should have efibootmgr, if only to revert to the previous EFI payload should pivot_root fail for any reason.
I also believe that coreboot should use UEFI - even if it's bloated and not perfect, it's a standard, and there are free options like tianocore: https://github.com/tianocore/edk2/blob/master/License.txt
Hi, I'm the maintainer of official Arch on ZFS installation guide and a boot environment manager. I will try to explain why a separate boot pool is necessary.
First, let me make this clear:
/bootmust be on ZFS. Period. Without this, you won't be able to recover from a broken initrd, as illustrated by this issue. Nothing is more convenient than rolling back system with a simple boot menu selection.With
/booton ZFS, GRUB must be used as it's the only bootloader that has ZFS support, albeit partially. rEFInd can be made to support ZFS via a 3rd party EFI driver, which in turn is a wrapper of GRUB ZFS code. So there's the compatibility issue. To be able to use all available features on/, a feature-limited boot pool needs to be created.A benefit of not storing anything except GRUB in ESP is the ability to protect initrd from tempering. With GRUB, it's possible to encrypt both boot pool and root pool, thus preventing attacks to initrd. An unencrypted initrd is trivial for an attacker to modify: she only needs to slip a piece of script into it to get your root pool key.
Also, GRUB provides support for both UEFI and BIOS boot, the latter you considered as worthless and obsolete. However, I have encountered some users who opt to use libreboot firmware to avoid non-free and bloated UEFI. The former only supports traditional BIOS booting.