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.
