[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

/boot/grub/grub.cfg hex number reference



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


Reply to: