Re: In a multiboot context (2 Ubuntu and 2 Windows OSes), Grub shows a very surprising behavior. Is this a bug ?

[Arbiel Perlacremaz]

Hi

Le 05/04/2012 22:50, Jordan Uggla a écrit :
> First, please don't send html email to help-grub (or to most other
> technical mailing lists). It often makes it more difficult to read and
> in this case has messed with the proper indentation of replied
> messages with '>'.

I'm really sorry for that. I have just changed  back the setting in my 
account parameters to avoid using html.
> On Thu, Apr 5, 2012 at 10:25 AM, Arbiel Perlacremaz
> <address@hidden>  wrote:
> > Grub sits on the MBR of each drive and, as long as we have been able to
> > understand, each Grub instance points to a unique grub.cfg, which sits on
> > drive 1.
>
> This last sentence is unclear, but what the boot info script output
> shows is that each drive has grub installed to its mbr,

I agree with you on that point

> drive's grub is configured to read a grub.cfg contained on their own
> drive, i.e. every time you change which drive is booted from the BIOS
> you are changing which grub.cfg is read.

I'm afraid, I do not agree with you on that second point. I'll tell you 
why after a first question :
For an unknown reason, the user's main hard drive is sdc. This is the 
drive through MBR of which he generally boots his PC, and which holds 
his both GNU/Linux partitions. His second drive, the one with W7, is sdb 
and the third one, with W8, is sda.

This is a fact we did not analyze. Can this type of confusion lead to 
unexpected results, as Grub is concerned ?

Now, let's return to the grub.cfg files. The reasons why I do not agree 
with you are the following :

1) the report clearly states that there are no grub.cfg file neither on 
sda1 nor on sdb1

2) at a given stage of our discussion, I stated that booting through MBR 
of the drives was not equivalent to booting through the grub menu 
entries, and that, having no indication on the contents of sda1 and sdb1 
grub.cfg files, I could not analyze the situation. The user answered 
that he was certain that they were not grub.cfg files on these drives. 
And this is confirmed by the report summary. He however gave a false 
reason, stating that those partitions were NTFS.

3) so we came to the phrasing of the summary : for sda1 et sdb1, it 
reads "core.img is at this location and looks in partition 1 for 
/boot/grub" whereas for sdc1, it reads "core.img is at this location and 
looks for (,msdos1)/boot/grub on this drive". They are two important 
differences in the phrasing
a) "/boot/grub" versus "(,msdos1)/boot/grub"
b) " in partition 1" versus "on this drive"

We discussed these points and came to the conclusion that the second 
phrasing was to be understood as it reads : "this drive" meaning the 
very drive the line of the summary is refering to, and that the other 
phrasing, ambiguous, cannot mean anything but "looks on a partition 1 of 
a unspecified drive, different from the drive the present line is 
refering to".
If the three situations were the same, each grub using its own grub.cfg 
file, why should the phrasing be different ?
> > Here is the bootinfo report
>
> You'll notice that there are a total of 5 menu entries relating to
> Windows from the various grub.cfg files. From sdc1's
> /boot/grub/grub.cfg we have:
>
> menuentry "Windows 7 (loader) (on /dev/sdb1)" --class windows --class os {
>      insmod part_msdos
>      insmod ntfs
>      set root='(hd1,msdos1)'
>      search --no-floppy --fs-uuid --set=root 439C8E7F4DCFF3BB
>      chainloader +1
> }
> menuentry "Windows 8 (loader) (on /dev/sda5)" --class windows --class os {
>      insmod part_msdos
>      insmod ntfs
>      set root='(hd0,msdos5)'
>      search --no-floppy --fs-uuid --set=root CE80A4F080A4E067
>      chainloader +2
> }
I have to admit that I did not give a single watch to sdc6's grub.cfg 
file, as I could not figure out how this file could be involved as no 
grub points to it.

>  From sdc6's /boot/grub/grub.cfg we have:
>
> menuentry "Windows 7 (loader) (on /dev/sda1)" --class windows --class os {
>      savedefault
>      insmod part_msdos
>      insmod ntfs
>      set root='(hd0,msdos1)'d
>      search --no-floppy --fs-uuid --set=root F64836B14836710B
>      chainloader +1
> }
>
> menuentry "Microsoft Windows Seven (sda1)" {
>          set root=(hd1,1)
>          chainloader +1
> }
> menuentry "Microsoft Windows Seven (sdb1)" {
>          set root=(hd2,1)
>          chainloader +1
> }
>
>
> Every one of these is different, pointing to a different partition.
> (The last two menu entries are manually added ones which don't search
> by UUID, making them unreliable)
>
> My guess is that the user is simply confusing menu entries which have
> very similar titles but which are not in fact the same.

This assumption is quite reasonable as more often than never, users have 
difficulties to clearly state what the read on the screen, what the 
behaviour of the PC really is.

However, in the present case, I would reject this assumption. The user 
handles a three-drive four-OS configuration, and he surely is not a 
newbee. I ran several tests and always described the results with accuracy.

I had him write a custom.cfg file to add new entries in the Grub menu to 
run additionnal tests without the risks of defiguring his regular 
grub.cfg. I did it right. After a few tests, he came back stating that 
his custom.cfg file was as follows :

menuentry "Windows 7 (loader) (on /dev/sdb1)" --class windows --class os {
    insmod part_msdos
    insmod ntfs
    set root='(hd1,msdos1)'
    search --no-floppy --fs-uuid --set=root 439C8E7F4DCFF3BB
    drivemap -s (hd0) ${root}
    chainloader +1
}
menuentry "Windows 8 (loader) (on /dev/sda1)" --class windows --class os {
    insmod part_msdos
    insmod ntfs
    set root='(hd0,msdos1)'
    search --no-floppy --fs-uuid --set=root F64836B14836710B
    drivemap -s (hd0) ${root}
    chainloader +1
}

and that selecting these lines, I could boot into W7 or W8 without 
difficulties.

I don't know the precise working of "drivemap -s". I thought this would 
swap the names of the drives, in which case, both lines should chainload 
to the first sector of the same (hdo) drive, and then should lead to the 
same booting.

And also, those entries result in rebooting the PC from the MBR of the 
specified drive, that is though, as if booting from drive sdc.

There is a last question. As you can see, the W8 entry of sdc1's 
grub.cfg file has grub read 2 sectors. Is that correct ?

The report I posted is the second report the user provided us with. He 
ran a first report before "installiong BCD to Windows 8". I don't know 
exactly what this means. The single effect I noticed of this 
"installation" (copying the file ?) is that, in his first report, the 
Windows 8 entry had Grub read only 1 sector.
>

I remain anxious to get comments from you, as the situation appears to 
me to be quite unexplainable.