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
