@wolf480pl @cas I just assume they don't want to have to deal with a gazillion of undocumented SBCs that may only get 1 person to once push code that gets accepted, but then "orphaned" and break over time as they may not be willing to build & test every new kernel before release just to enshure it ain't broken!

• Espechally since #ARM doesn't have just a bootcode.bin and #UEFI to boot from, but half a dozen different mechanisms ranging from fixed sector location and -sizes for the initramfs to #uBOOT & #LinuxBoot, #Coreboot and potentially even #OpenFirmware-style #bootcode...
  

It's absolute chaos and one of the reasons I didn't even try to build @OS1337 for the #Pi0W as of today...

@dvl @dch
Not 100% sure about loader.efi, but at least boot1.efi would be affected if any read-incompatible feature(s) is/are enabled and active even on data-only pools.
This is because, in boot1.efi, it sniffs the existence of /boot/loader.efi to determine whether the pool is bootable or not.
loader.efi should need to sniff at least pool name(s), whether it's bootable or not by somehow reading the pool(s).

If you're 100% sure there's not at all a plan to have bootable ZFS (means, use UFS for boot throughout the future), and once confirmed it works as wanted, using gptboot.efi would be the way to go.
It does not sniff ZFS pools (not linked against ZFS codes) and (in contrast with boot1.efi) not obsoleted.

#FreeBSD #loader #bootcode #ZFS #UFS

@josephholsten @Toasterson @marcan @lina @AsahiLinux @Raspberry_Pi @geerlingguy

Eeyupp - it doesn't do #UEFI at all, but instead has a #bootcode - #EEPROM that is updateable.

Tho there are multitudes of boot options depending on the boot media.