Re: install on multiple disks [success]

[Ross Boylan]

I'm happy to report success.  I did grub-install /dev/sdb,
grub-install/dev/sdc and then shut down the VM and removed the old sda
(so that the old sdb became sdb, etc).  The system rebooted
successfully.

The one hiccup was that md1 was missing one element; the logs show that
well before any grub changes the virtual drive had failed (I guess
something is not quite right with the VM, because the same thing
happened a few days ago).  So I think that was unrelated.

A few minor comments below.


On Wed, 2012-12-26 at 11:19 +0400, Andrey Borzenkov wrote:
> On Wed, Dec 26, 2012 at 2:56 AM, Ross Boylan <address@hidden> wrote:
> >> > The online manual is cryptic.  It suggests
> >> > grub-install /dev/sdb
> >> > might work but....
> >> > My /boot is on a separate partition, also known as /dev/md0
> >>
> >> Well ... current GRUB2 support MD disks so in this case you do not
> >> need to do anything special. I have no idea whether grub 1.96 supports
> >> it. If not, you are likely out of luck.
> > RAID1 should, and has been, working either way.  That is, /dev/sdb2
> > looks the same as /dev/md0, except maybe for some control information at
> > the end.
> >
> 
> You misunderstand. When I say "current GRUB2 supports MD" it means
> exactly that - GRUB2 provides native drivers, it assembles MD array
> and is using it, and not individual disks. It applies not only to
> RAID1 but to other RAID levels as well.
I'm not sure whether the grub 1.96 on the VM ended up using the raid
array (aka /dev/md0) or one of its components (/dev/sda2), though I
think I  saw grub mention the RAID as it came up.

My earlier comment was addressed not to your remark that GRUB2 supports
MD but to the caution that 1.96 might not.  I was pointing out that,
even if it didn't, things should work because the  components of my
RAID1 were usable solo.  I think that had I used one of the newer 1.x
RAID metadata formats with the RAID superblock at the start the
partition might not work outside of the array.  My disk has the old 0.90
md raid metadata, which is at the end of the partition.

> 
> >> 3. It also stores code in core.img to search for device where
> >> /boot/grub is located at runtime. It normally does it by searching for
> >> filesystem UUID.
> > This is the part that concerned me: getting the right disk and directory
> > in this search.
> >
> > I assume that means it will look for the RAID, not the underlying
> > physical disk.  Or maybe the filesystem on the RAID?
> >
> 
> Yes, exactly. It will assemble RAID and search for filesystem. This is
> similar to mount by UUID in Linux. Physical name of device does not
> matter - filesystem will always be found.
> 
> > So if it's looking on a separate boot partition, it should search
> > for /grub, whereas if everything's on one partition it would need to
> > search for /boot/grub.
My grub.cfg ended up with
set root=(hd0)
search --fs-uuid --set 647cf7fe-b6f3-49d6-ba0c-569a9513f44a
where 647cf.... is the UUID of the file system on the RAID.

I think this means hd0 is the fallback if the UUID search fails (since
the man says --set sets environment variable root be default).

Maybe that shows grub did run off the RAID, since (hd0) alone may not be
enough to find /boot, which is on (hd0,gpt2).

> >
> 
> 
> grub-install knows it and computes correct paths during installation.
> 
> 
> > What I'm looking for is something that will really boot even if I change
> > which disk is first;
> 
> grub2 makes it much more robust than grub legacy.
> 
> > Of course, if grub 2 uses the RAID device md0 or the filesystem on it
> > that will be insensitive to the physical disk changes I'm contemplating,
> > and so maybe it will just work.
> >
> 
> Please understand that I always refer to current grub2, which is
> version 2.00. Version 1.96 is ... I do not know, over three years old.
> So you are really better off to ask on your distribution forums or
> update grub2 if possible.
Understood.  Thanks for your help.

It might be nice to clarify some of these points in the documentation,
e.g., that --boot-directory refers to the path used during the
installation, not during the actual boot, or that grub should work even
if the physical drive location/order changes.  I may have stated those
items too broadly.

FYI, it looks as if even the upcoming Debian release (wheezy?) is not
quite 2.00, which is only in unstable.  It has 1.99-23.1.  It's possible
it incorporates backports of more recent code.

Ross