[Bug 277886] ZFS boot loader gives up too easily on unsupported zpool flags

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277886

Xin LI <delphij@FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |delphij@FreeBSD.org,
                   |                            |mahrens@FreeBSD.org,
                   |                            |tsoome@freebsd.org

--- Comment #2 from Xin LI <delphij@FreeBSD.org> ---
(In reply to Tomoaki AOKI from comment #1)
I think the ask is simply make check_feature() and check_mos_features()
(/stand/libsa/zfs/zfsimpl.c) to always return 0 instead of EIO even if the
feature is not supported, so probably the boot code would emit a lot of errors,
but eventually somehow able to read in the kernel (which is supposed to have
the support, as the upgrade happened when the kernel is running).

There may be some useful scenarios, for example, if a boot code that can't
support zstd compression is used, and boot file system never had zstd
compression, then the boot code should, in theory, be able to have sufficient
ability to boot from the pool.

Personally I don't really like this idea, though, because it is not guaranteed
to work and may expose bugs of the read-only code (because we now broke the
calling contract).  It would be much better to prevent the upgrade from
happening on the boot pool, and only allow it when boot environment is updated,
instead.

If I was tasked to implement something for this, I'd probably do it by
extending zpool utility to ask an OS dependent binary about "Is feature X
supported by the current boot environment" for each read-only incompatible
features, if the pool have 'bootfs' set, and refuse to upgrade (unless -f is
specified) these boot pools if any feature is not supported.

A naive implementation of the checker can be done by doing something like:

1. Gather a list of all partitions that is "freebsd-boot" type or "efi" type
(this is actually not right; the EFI partition should be mounted and the actual
EFI/BOOT/BOOT${ARCH}.EFI should be checked instead), and append /boot/loader
2. Check if the feature string is present in the listed files, and return false
if any of them do not have the string.

-- 
You are receiving this mail because:
You are the assignee for the bug.