@mkukri --- >>> The question is, are we going to backport the fix to 2.06 and push that to the updates channel, or can this wait for the 2.12 SRU sometimes after April? >>> What does that mean? Option #1 -- The cherry picked Grub2 2.12 ZFS related commit code gets applied to Grub2 2.06 as a patch? Option #2 -- After April, when Grub2 2.12 gets published and released as a "stable release update," that it also gets released to Jammy and Mantic? But you said it has the potential to break Jammy? I'm not seeing that in my tests yet, but I believe you. **** Here is how I see the logic of this, but it means nothing, as I am not in the decision process, but: For option 1, that would take time anyways, and the Noble April Release is less than 2 months. So option #2 would be about the same wait with a whole lot less work involved by everyone. *** Until then, I have three working work-arounds for this non-booting error: Work-around #1-- The above work-around, which you say may break some things. Work-around #2-- I do have another work-around, that involves booting from an Installer LiveUSB. Backing up the content of bpool to a created backup directory "somehwere" (size needed is less than 2GB), saving the old UUID that was used in the old dataset name to a file. I used another USB Flash drive. Destroy the old bpool pool. Create the new bpool with these explicit creation options: >>> zpool create \ -o ashift=12 \ -o autotrim=on \ -o cachefile=/etc/zfs/zpool.cache \ -o feature@async_destroy=enabled \ -o feature@empty_bpobj=active \ -o feature@lz4_compress=active \ -o feature@multi_vdev_crash_dump=disabled \ -o feature@spacemap_histogram=active \ -o feature@enabled_txg=active \ -o feature@hole_birth=active \ -o feature@extensible_dataset=disabled \ -o feature@embedded_data=active \ -o feature@bookmarks=disabled \ -o feature@filesystem_limits=disabled \ -o feature@large_blocks=disabled \ -o feature@large_dnode=disabled \ -o feature@sha512=disabled \ -o feature@skein=disabled \ -o feature@edonr=disabled \ -o feature@userobj_accounting=disabled \ -o feature@encryption=disabled \ -o feature@project_quota=disabled \ -o feature@device_removal=disabled \ -o feature@obsolete_counts=disabled \ -o feature@zpool_checkpoint=disabled \ -o feature@spacemap_v2=disabled \ -o feature@allocation_classes=disabled \ -o feature@resilver_defer=disabled \ -o feature@bookmark_v2=disabled \ -o feature@redaction_bookmarks=disabled \ -o feature@redacted_datasets=disabled \ -o feature@bookmark_written=disabled \ -o feature@log_spacemap=disabled \ -o feature@livelist=disabled \ -o feature@device_rebuild=disabled \ -o feature@zstd_compress=disabled \ -o feature@draid=disabled \ -o feature@zilsaxattr=disabled \ -o feature@head_errlog=disabled \ -o feature@blake3=disabled \ -o feature@block_cloning=disabled \ -o feature@vdev_zaps_v2=disabled \ -o compatibility=grub2,ubuntu-22.04 \ -O devices=off \ -O acltype=posixacl \ -O xattr=sa \ -O compression=lz4 \ -O normalization=formD \ -O relatime=on \ -O canmount=off -O mountpoint=/boot -R /mnt\ bpool ${DISK}-part3 >>> Set the UUID VAR from the old UUID stored in the file, then recreate the bpool filesystem datasets >>> zfs create -o canmount=off -o mountpoint=none bpool/BOOT zfs create -o mountpoint=/boot bpool/BOOT/ubuntu_$UUID >>> rsync the old bpool contents back into the new bpool... Export the new bpool and reboot. Work-around #3-- Is to back up and reinstall, telling the user not to do any snapshots of bpool until this problem is resolved. Work-arounds #1 & #3 make no changes to the pool options. Work-around #3 has the risk of losing the user data. Work-around #2 is a whole lot of work, and has the highest risk factor of them all... And the options used are different than was installed... But it works with Grub2 2.06. @Mate: What do you think on this? What should 1fallen and I tell Users until April?