Control: found -1 2.04-18 I just hit this bug. It rendered my system unbootable because my root ZFS pool has the new zstd compression feature enabled, and it looks like grub-probe choked on that.
There are two things that I found highly frustrating here: - While my root (/) is on ZFS, my /boot is not, precisely to try to avoid issues like these. In this setup GRUB doesn't need to be able to read the zpool - all that matters is the name of the pool, which can be trivially determined without the need for any kind of subtle low-level probing. It seems like as long as the bootloader/kernel/initrd itself is not stored on ZFS, GRUB should Just Work regardless of the low-level zpool details (such as zpool features). That is not presently the case because /etc/grub.d/10_linux insists on using grub-probe and grub-probe insists on using its own custom low-level ZFS read code just to figure out the name of the zpool. That's just... silly. - The error handling here is appalling. In my case update-grub (grub-mkconfig) *did not even display a single error message*. The "unknown filesystem" error from grub-probe is being swallowed somehow, and /etc/grub.d/10_linux doesn't check that the returned `rpool` looks valid. update-grub will happily generate an obviously garbage, unbootable config with a syntactically invalid root=ZFS= kernel parameter and everything will look fine at first... until you try to reboot! At the very least an error message should be displayed; ideally update-grub should refuse to generate a new config altogether, to avoid replacing a working config with a broken one. By the way, here are steps to reproduce to make grub-probe choke on a ZFS pool with zstd enabled: # dd if=/dev/zero of=/tmp/pool bs=1 count=1 seek=$((128*1024*1024)) # zpool create testpool /tmp/pool # zfs set compression=zstd testpool # /usr/sbin/grub-probe --device /tmp/pool --target=fs_label /usr/sbin/grub-probe: error: unknown filesystem. If the "zfs set compression" step is omitted, grub-probe works. Tested with zfs 2.0.3-8.
