Web lists-archives.com

Re: drive names and UUIDs, was Re: Intresting dd fsck grub uuid fstab action




On Thu 01 Jun 2017 at 12:24:28 (-0400), Fungi4All wrote:

> Why don't just skip all this that we are in perfect agreement with and go to the juicy part.
> After all uuids are unique and fstab are all correct, updating-grub would mix match uuids in writing
> its grub.cfg
> Two uuids on the same entry! Over and over again.... till I edited it out to the correct ones and it all worked.
> Why does everyone choses to skip on this issue and keeps explaining me over and over
> what I have well understood by now?

Well, we don't have a lot of evidence. But we do have a tiny bit:

if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos3 --hint-efi=hd0,msdos3 --hint-baremetal=ahci0,msdos3 --hint='hd0,msdos3' UUID on sda3 XXX
else
search --no-floppy --fs-uuid --set=root UUID on sda3 YYY
fi
insmod png

Not a lot of context, and also edited and unindented, so the best
I can do to try to find what wrote this is to grep "platform_search"
and that comes up with /usr/share/grub/grub-mkconfig_lib in grub-common.

Within this file are these lines (starting around l.169):

  # If there's a filesystem UUID that GRUB is capable of identifying, use it;
  # otherwise set root as per value in device.map.
  fs_hint="`"${grub_probe}" --device $@ --target=compatibility_hint`"
  if [ "x$fs_hint" != x ]; then
    echo "set root='$fs_hint'"
  fi
  if fs_uuid="`"${grub_probe}" --device $@ --target=fs_uuid 2> /dev/null`" ; then
    hints="`"${grub_probe}" --device $@ --target=hints_string 2> /dev/null`" || hints=
    echo "if [ x\$feature_platform_search_hint = xy ]; then"
    echo "  search --no-floppy --fs-uuid --set=root ${hints} ${fs_uuid}"
    echo "else"
    echo "  search --no-floppy --fs-uuid --set=root ${fs_uuid}"
    echo "fi"
  fi
  IFS="$old_ifs"

I'll let the shell experts come up with ideas about how ${fs_uuid}
produces two different substitutions within three lines.
I have made one assumption, that these lines from grub.cfg are from
sections 00 throught 10.

Once you reach section 30, things are different. Although I still
would not expect to see the disagreement in UUIDs quoted above,
I wouldn't be surprised if the UUIDs in the lines   linux /boot/vmlinuz…
bore no relation to the other UUIDs because _this_ linux… line is
copied directly from grub.cfg files scattered elsewhere on the disks.

I can illustrate this with the following. Here's the first menuentry
(top level) in my wheezy partition, freshly generated, but then doctored
by inserting "doctored" in the title and zeroing the first two digits
of the UUID throughout this entry. (This grub.cfg is never actioned
because the MBR doesn't point to it.)


### BEGIN /etc/grub.d/10_linux ###
menuentry 'doctored Debian GNU/Linux, with Linux 3.2.0-4-686-pae' --class debian --class gnu-linux --class gnu --class os {
	load_video
	insmod gzio
	insmod part_msdos
	insmod ext2
	set root='(hd0,msdos2)'
	search --no-floppy --fs-uuid --set=root 0097eef1-c934-4b8f-a76b-4b084d6cf6f0
	echo	'Loading Linux 3.2.0-4-686-pae ...'
	linux	/boot/vmlinuz-3.2.0-4-686-pae root=UUID=0097eef1-c934-4b8f-a76b-4b084d6cf6f0 ro  quiet
	echo	'Loading initial ramdisk ...'
	initrd	/boot/initrd.img-3.2.0-4-686-pae
}


Now here are the first two menuentries in section 30 of my jessie
partition (which the MBR points to), generated after the above.
The first menuentry is the top-level one, the second is the
duplicate inside the submenu.

### BEGIN /etc/grub.d/30_os-prober ###
menuentry 'Debian GNU/Linux (7.11) (on /dev/sda2)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-simple-dd97eef1-c934-4b8f-a76b-4b084d6cf6f0' {
	insmod part_msdos
	insmod ext2
	set root='hd0,msdos2'
	if [ x$feature_platform_search_hint = xy ]; then
	  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos2 --hint-efi=hd0,msdos2 --hint-baremetal=ahci0,msdos2 --hint='hd0,msdos2'  dd97eef1-c934-4b8f-a76b-4b084d6cf6f0
	else
	  search --no-floppy --fs-uuid --set=root dd97eef1-c934-4b8f-a76b-4b084d6cf6f0
	fi
	linux /boot/vmlinuz-3.2.0-4-686-pae root=UUID=0097eef1-c934-4b8f-a76b-4b084d6cf6f0 ro quiet
	initrd /boot/initrd.img-3.2.0-4-686-pae
}
submenu 'Advanced options for Debian GNU/Linux (7.11) (on /dev/sda2)' $menuentry_id_option 'osprober-gnulinux-advanced-dd97eef1-c934-4b8f-a76b-4b084d6cf6f0' {
	menuentry 'doctored Debian GNU/Linux, with Linux 3.2.0-4-686-pae (on /dev/sda2)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-/boot/vmlinuz-3.2.0-4-686-pae--dd97eef1-c934-4b8f-a76b-4b084d6cf6f0' {
		insmod part_msdos
		insmod ext2
		set root='hd0,msdos2'
		if [ x$feature_platform_search_hint = xy ]; then
		  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos2 --hint-efi=hd0,msdos2 --hint-baremetal=ahci0,msdos2 --hint='hd0,msdos2'  dd97eef1-c934-4b8f-a76b-4b084d6cf6f0
		else
		  search --no-floppy --fs-uuid --set=root dd97eef1-c934-4b8f-a76b-4b084d6cf6f0
		fi
		linux /boot/vmlinuz-3.2.0-4-686-pae root=UUID=0097eef1-c934-4b8f-a76b-4b084d6cf6f0 ro quiet
		initrd /boot/initrd.img-3.2.0-4-686-pae
	}


We can see here that the menuentry title and the linux boot line
(at least) have been copied from wheezy's grub.cfg. (If the UUID
0097… happened to match any filesystem present, the system would
obviously boot into it.)

On a laptop like mine, where the UUIDs (and LABELs) have been stable
for several years, and both systems have had grub.cfg rewritten
many times, all the data therein is in mutual agreement. But if
you alter the UUIDs, the alterations have to propogate through
section 10s, for want of a better expression, before they can be
copied into section 30s.

Cheers,
David.