Does anyone know what the 16-digit hex number (truncated below to 9cbe...) refers to in /boot/grub/grub.cfg, where it makes several appearances?
# grep 9cbe -A2 -B2 /boot/grub/grub.cfg <snip> if [ x$feature_platform_search_hint = xy ]; then search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt3 --hint-efi=hd0,gpt3 --hint-baremetal=ahci0,gpt3 9cbe... <--- else search --no-floppy --fs-uuid --set=root 9cbe... <--- fi <snip> That suggests perhaps something to do with an FS UUID, but it doesn't seem to appear in the output of any of # blkid # lsblk -o MODEL,NAME,LABEL,WWN,UUID,SERIAL,PTUUID,PARTUUID # zfs get all bpool|grep 9cbe # zfs get all rpool|grep 9cbe # zpool get all bpool|grep 9cbe # zpool get all rpool|grep 9cbe The previous hex number appeared in a grub error ("no such device: <hexnum>") after a failed update-grub, either after recreating the boot partition or the ZFS boot pool on it, or both. This caused a delay during boot of approx 10s while being invited to "press any key to continue" immediately. After running update-grub, the hex number was replaced with another in grub.cfg, and the error message and boot delay disappeared. For info: There is currently a bug in grub whereby if a ZFS boot pool is snapshotted at the top level, the compression type "inherit" can result in the grub error "compression algorithm inherit not supported", and a broken boot process, which is what I was sorting out when I noticed this. https://github.com/openzfs/zfs/issues/13873 https://savannah.gnu.org/bugs/index.php?64297 According to some comments on github, it doesn't seem to be definitively fixed in grub 2.12, not that I have tried. Snapshotting boot pool datasets is said to be OK. Thanks, Gareth