Re: Two systems -- supposed to be the same, but booting with grub differently. What'd I miss?

[Dale R. Worley]

address@hidden writes:
> What did I miss or forget?

Here are some possibilities:

> I've got two machines. Both are supposed to be configured the same:
> Linux, with grub2 booting, with everything on a RAID-1 array.

You say they "are supposed to be configured the same".  What does that
mean?  Read literally, you aren't even asserting that *you* think they
are configured the same.  A more useful comment would be "As far as I
can tell, they are configured the same."  But that's not true.  Perhaps
you mean

    The only differences in their configurations that I can find are:

        -- system 1's "/boot" partition is on a RAID array config'd as v1.0 
metadat; system 2's is v1.2
        -- system 1's got Grub2 installed in BOTH MBR & boot sector of both 
RAID disks; system 2's got it only installed in MBR.

(This criticism may sound harsh, but you're evidently quite fluent with
English, and so readers will interpret the exact phrasing of your report
quite carefully, and so you have to write it carefully and accurately.)

This is a question about the behavior of Grub, but you don't list the
grub.cfg contents.  And given the various installations of Grub, have
you verified which grub.cfg is being executed?  (If you have no other
way to tell, modify the menuentry names in all grub.cfgs and see which
names show up on booting.)

    (1) System1
    ------------------------
    cat /proc/mdstat
            Personalities : [raid1]
            md1 : active raid1 sda2[0] sbd2[1]
            ...
            md0 : active raid1 sbd1[1] sda1[0]
            ...

The presence of "sbd1" and "sbd2" puzzles me.  Are these correct?  Or are
they a sign that you've edited the bootinfo output?  If the latter, what
else might you have changed *and not told us about*?

The size of the md1 pseudo-drives are vastly different:  487205888
blocks vs. 975581888 blocks.  This means that the disks on the two
systems are different in size or configuration.

The fact that the md0 and md1 devices are listed in different orders in
/proc/mdstat is a sign that the device configurations on the two systems
are *not* the same.

Exactly what is the point at which the delay occurs?  You say "right
after the Grub menu", but strictly, that means *after* Grub displays the
menu but *before* it accepts your input.  I suspect that the delay
happens *after* you select the menu item but before Linux starts up
itself.  Can you provide us details to help narrow down what step in
processing this happens at?

I see in my grub.cfg menu entries like this:

        menuentry 'Fedora 19 (3.14.27-100.fc19.x86_64) (Hobgoblin00-RootF19)' 
--class gnu-linux --class gnu --class os $menuentry_id_option 
'osprober-gnulinux-/vmlinuz-3.14.27-100.fc19.x86_64--188c0958-d8f1-41dd-a64c-d7f468c80737'
 {
        insmod part_gpt
        insmod ext2
        set root='hd0,gpt2'
        if [ x$feature_platform_search_hint = xy ]; then
          search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2 
--hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2 --hint='hd0,gpt2'  
9c2021d3-d105-41b1-b805-ff88c399c943
        else
          search --no-floppy --fs-uuid --set=root 
9c2021d3-d105-41b1-b805-ff88c399c943
        fi
        linux /vmlinuz-3.14.27-100.fc19.x86_64 root=/dev/Hobgoblin00/RootF19 ro 
rd.md=0 rd.dm=0 vconsole.keymap=us rd.lvm.lv=Hobgoblin00/Swap rd.luks=0 
vconsole.font=latarcyrheb-sun16 rd.lvm.lv=Hobgoblin00/RootF19 rhgb quiet 
LANG=en_US.UTF-8
        initrd /initramfs-3.14.27-100.fc19.x86_64.img
        }

These are the command that Grub will execute after I've chosen an entry
and before Linux proper is booted.  Note the "search" commands, which
tell Grub to search all the disk devices for particular partitions.

The fact that Grub waits for 2 minutes and then continues suggests a
time-out of some operation that is failing.  In this situation, I would
guess that Grub is searching for a disk partition, and it is waiting for
some disk device that it attached to some controller to become ready,
and then giving up and going on.  Or perhaps there is an extraneous
"search" command in grub.cfg that is looking for a partition that
doesn't exist, but for some reason the booting proceeds successfully
without it.

All of this suggests that Grub believes that there is a different set of
disk controllers on one system than on the other, or that the
controllers are configured to report a different set of disks.  I'd
check inside the boxes to see if there are additional disk controllers
present in one, or if jumpers or switches or dangling cables show that
one system deceives Grub into thinking there is another disk that isn't
there.  Also check the BIOS settings for any differences -- one may be
set to turn on some sort of disk capability that there is no actual disk
for.

Dale