Re: /boot/grub/grub.cfg hex number reference
On Wed 13 Mar 2024 at 18:59:30 (+), Gareth Evans wrote: > On Wed 13/03/2024 at 12:50, Michel Verdier wrote: > > On 2024-03-13, Gareth Evans wrote: > > > >> That suggests perhaps something to do with an FS UUID, but it doesn't seem > >> to appear in the output of any of > >> > >> # blkid > > > > Here I have them shown as UUID by blkid > > > > # grep root /boot/grub/grub.cfg > > ... > > search --no-floppy --fs-uuid --set=root --hint-bios=hd1,gpt2 > > --hint-efi=hd1,gpt2 --hint-baremetal=ahci1,gpt2 > > 5210342e-548e-4c4d-a0e9-a5f6d13888d6 > > ... > > > > # blkid|grep -i 5210342e > > /dev/sdb2: UUID="5210342e-548e-4c4d-a0e9-a5f6d13888d6" ... > > > > hint-bios=hd0,gpt3 suggests its your 3rd partition on your first disk. > > > > Do you use raid ? > > Hi Michael, > > I'm currently using a single disk with ZFS, partitioned as I don't know anything about ZFS … > $ sudo fdisk -l /dev/sda > > Disk identifier: 3405... > Device Start End Sectors Size Type > /dev/sda1 48 2047 2000 1000K BIOS boot > /dev/sda2 2048 1050623 1048576 512M EFI System > /dev/sda3 1050624 3147775 2097152 1G Solaris /usr & Apple ZFS > /dev/sda4 3147776 250069646 246921871 117.7G Solaris root … or what Solaris /usr & Apple ZFS and Solaris root mean. [ … ] > So after making some sense of grub-mkconfig.in, it turns out the 16-digit hex > number is returned by > > # grub-probe --device /dev/sda3 --target=fs_uuid > 9cbef743dfafd874 I'd be interested to know what grub-probe --device /dev/sda3 --target=fs thinks the filesystem is. It may just follow what udev says, in which case I'd look at the contents of /run/udev/data/b8\:3 (guessing¹). BTW there's no necessity for the UUID to be 32 hex digits; for example, grub-probe --device /dev/sda2 --target=fs_uuid will give you something more like C027-B627. > Given that the above command fails with > > --device /dev/sda4 > > (which is the running system's /), gpt3 appears to be sda3, ie. the boot > partition, If you say so. > so > > --set=root > > in the grub.cfg search line presumably relates to the root of /boot. Yes, confusingly, AIUI, the root of --set=root is nothing necessarily to do with the root= in the linux line. > I'm still curious as to why it doesn't seem to appear anywhere else, how it > was applied, and what exactly it applies to - a filesystem? The answer to that may lie with ZFS. > This is not aiui the usual form of a UUID either. As mentioned above. > grub-probe.in or grub-install.c might hold answers. AFAIK grub-install requires a system device name (like /dev/sda) or something that points to it (like the /dev/disk/ symlinks). ¹ I've guessed for partition three on the first HDD. For an nvme SSD, it could be /run/udev/data/b259\:3 or some other b-number. It's usually pretty obvious from a directory listing because of the :0 :1 :2 … corresponding partition numbers. Cheers, David.
Re: /boot/grub/grub.cfg hex number reference
> On 13 Mar 2024, at 19:00, Gareth Evans wrote: > > Hi Michael, I'm sorry - Michel
Re: /boot/grub/grub.cfg hex number reference
On Wed 13/03/2024 at 12:50, Michel Verdier wrote: > On 2024-03-13, Gareth Evans wrote: > >> That suggests perhaps something to do with an FS UUID, but it doesn't seem >> to appear in the output of any of >> >> # blkid > > Here I have them shown as UUID by blkid > > # grep root /boot/grub/grub.cfg > ... > search --no-floppy --fs-uuid --set=root --hint-bios=hd1,gpt2 > --hint-efi=hd1,gpt2 --hint-baremetal=ahci1,gpt2 > 5210342e-548e-4c4d-a0e9-a5f6d13888d6 > ... > > # blkid|grep -i 5210342e > /dev/sdb2: UUID="5210342e-548e-4c4d-a0e9-a5f6d13888d6" ... > > hint-bios=hd0,gpt3 suggests its your 3rd partition on your first disk. > > Do you use raid ? Hi Michael, I'm currently using a single disk with ZFS, partitioned as $ sudo fdisk -l /dev/sda Disk identifier: 3405... Device Start End Sectors Size Type /dev/sda1 48 2047 2000 1000K BIOS boot /dev/sda2 2048 1050623 1048576 512M EFI System /dev/sda3 1050624 3147775 2097152 1G Solaris /usr & Apple ZFS /dev/sda4 3147776 250069646 246921871 117.7G Solaris root $ sudo grep root /boot/grub/grub.cfg search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt3 --hint-efi=hd0,gpt3 --hint-baremetal=ahci0,gpt3 9cbef743dfafd874 <-- $ sudo blkid|grep 9cbe $ $ lsblk -o MODEL,NAME,LABEL,WWN,UUID,SERIAL,PTTYPE,PTUUID,PARTUUID|grep 9cbe $ /# ls -R|grep 9cbe some filenames contain a match to the substring searched for, but none match the 16-digit hex number fully. This excludes it appearing in any of the /dev/disk/by-*/ identifiers, which I have also checked separately just in case. I git cloned grub to see if I could make sense of how grub.cfg is generated. $ git clone https://git.savannah.gnu.org/git/grub.git According to NEWS for v1.97: > * update-grub is replaced by grub-mkconfig So after making some sense of grub-mkconfig.in, it turns out the 16-digit hex number is returned by # grub-probe --device /dev/sda3 --target=fs_uuid 9cbef743dfafd874 Given that the above command fails with --device /dev/sda4 (which is the running system's /), gpt3 appears to be sda3, ie. the boot partition, so --set=root in the grub.cfg search line presumably relates to the root of /boot. I'm still curious as to why it doesn't seem to appear anywhere else, how it was applied, and what exactly it applies to - a filesystem? This is not aiui the usual form of a UUID either. grub-probe.in or grub-install.c might hold answers. I will reply again if I discover anything informative. Thanks, Gareth
Re: /boot/grub/grub.cfg hex number reference
On 2024-03-13, Gareth Evans wrote: > That suggests perhaps something to do with an FS UUID, but it doesn't seem to > appear in the output of any of > > # blkid Here I have them shown as UUID by blkid # grep root /boot/grub/grub.cfg ... search --no-floppy --fs-uuid --set=root --hint-bios=hd1,gpt2 --hint-efi=hd1,gpt2 --hint-baremetal=ahci1,gpt2 5210342e-548e-4c4d-a0e9-a5f6d13888d6 ... # blkid|grep -i 5210342e /dev/sdb2: UUID="5210342e-548e-4c4d-a0e9-a5f6d13888d6" ... hint-bios=hd0,gpt3 suggests its your 3rd partition on your first disk. Do you use raid ?
/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
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
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: ")
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
