Upgrading to GRUB2 from GRUB Legacy on RAID1

Upgrading to GRUB2 from GRUB Legacy on RAID1

[Leslie Rhorer]

	Dilemma: GRUB legacy will not upgrade to GRUB2 on my machines.  The
systems were originally built to "fake out" GRUB legacy by using a 1.0
superblock on a pair of RAID1 members and pointing GRUB to one or the other
of the disks so it can chain load from what it thinks is an ordinary primary
partition.  Once initrd loads and md is active, it assembles the arrays and
then the kernel mounts / and then /boot, and booting continues normally.

	The cause: When dpkg instructs grub-pc to configure itself, it fails
because it is unable to reconcile the information in /boot/grub/menu.lst
with the hardware mounted by /etc/fstab.

	The cure? : I was thinking I should be able to comment out the
entries for /dev/md1 in /etc/fstab  and /etc/mdadm/mdadm.conf, and reboot
the system.  Then I think I can

1.  Mount /dev/hda1 to /boot.

2.  Upgrade GRUB, which should now understand both /etc/fstab and
/boot/grub/menu/lst.

3.  Reboot to make sure it works.

4.  Edit /boot/grub/grub.cfg and /boot/grub/device.map to let GRUB2 know it
should be booting from an array and to make sure it is loading the RAID1
module.

5.  Umount /boot and create a new 1.0 superblock RAID1 array using only
/dev/hda1 and a missing member.  Mount the new array as /boot.

6.  Add the new array info into /etc/mdadm/mdadm.conf and change /etc/fstab
back to mount /dev/md1.

7.  Run update-initramfs to copy the new configuration into initrd.

8.  Reboot and make sure GRUB2 can now boot into the new array.

9.  Add /dev/hdb1 into the new array, and re-sync the array.

10. Update /etc/mdadm/mdadm.conf with the full array info, getting rid of
the missing member, and remove the reference to the old array altogether.

11. Run the GRUB update routine to remove the chain-load from GRUB legacy.

12. Run update-initramfs to copy the final configuration into the initrd (if
GRUB update doesn't already do it.)

	Is my thinking correct, here?  Have I missed a step?  Up until step
9, I should be able to easily revert back to my original configuration by
simply removing the comment for the old array, forcing an assembly of the
old array using only /dev/hdb1, add back /dev/hda1, resync the array, remove
the comment from /etc/fstab and run update-initramfs.

Upgrading to GRUB2 from GRUB Legacy on RAID1

[lrhorer]

	I thought I had sent this previously, but I don't see a reflection
copy in my in-box.  Pardon me if this is a duplicate, but OTOH, if it is,
doesn't anyone have any comments or advice?  I'm especially a little fuzzy
around step 4 below.  I think I need to run `grub-setup` or something, but
I'm not clear on the details.

	Dilemma: GRUB legacy will not upgrade to GRUB2 on my machines.  The
systems were originally built to "fake out" GRUB legacy by using a 1.0
superblock on a pair of RAID1 members and pointing GRUB to one or the other
of the disks so it can chain load from what it thinks is an ordinary primary
partition.  Once initrd loads and md is active, it assembles the arrays and
then the kernel mounts / and then /boot, and booting continues normally.

	The cause: When dpkg instructs grub-pc to configure itself, it fails
because it is unable to reconcile the information in /boot/grub/menu.lst
with the hardware mounted by /etc/fstab.

	The cure? : I was thinking I should be able to comment out the
entries for /dev/md1 in /etc/fstab  and /etc/mdadm/mdadm.conf, and reboot
the system.  Then I think I can

1.  Mount /dev/hda1 to /boot.

2.  Upgrade GRUB, which should now understand both /etc/fstab and
/boot/grub/menu/lst.

3.  Reboot to make sure it works.

4.  Edit /boot/grub/grub.cfg and /boot/grub/device.map to let GRUB2 know it
should be booting from an array and to make sure it is loading the RAID1
module.

5.  Umount /boot and create a new 1.0 superblock RAID1 array using only
/dev/hda1 and a missing member.  Mount the new array as /boot.

6.  Add the new array info into /etc/mdadm/mdadm.conf and change /etc/fstab
back to mount /dev/md1.

7.  Run update-initramfs to copy the new configuration into initrd.

8.  Reboot and make sure GRUB2 can now boot into the new array.

9.  Add /dev/hdb1 into the new array, and re-sync the array.

10. Update /etc/mdadm/mdadm.conf with the full array info, getting rid of
the missing member, and remove the reference to the old array altogether.

11. Run the GRUB update routine to remove the chain-load from GRUB legacy.

12. Run update-initramfs to copy the final configuration into the initrd (if
GRUB update doesn't already do it.)

	Is my thinking correct, here?  Have I missed a step?  Up until step
9, I should be able to easily revert back to my original configuration by
simply removing the comment for the old array, forcing an assembly of the
old array using only /dev/hdb1, add back /dev/hda1, resync the array, remove
the comment from /etc/fstab and run update-initramfs.

Re: Upgrading to GRUB2 from GRUB Legacy on RAID1

[Michael Evans]

On Thu, Jun 10, 2010 at 5:40 PM,  <lrhorer@satx.rr.com> wrote:
>
>        I thought I had sent this previously, but I don't see a reflection
> copy in my in-box.  Pardon me if this is a duplicate, but OTOH, if it is,
> doesn't anyone have any comments or advice?  I'm especially a little fuzzy
> around step 4 below.  I think I need to run `grub-setup` or something, but
> I'm not clear on the details.
>
>        Dilemma: GRUB legacy will not upgrade to GRUB2 on my machines.  The
> systems were originally built to "fake out" GRUB legacy by using a 1.0
> superblock on a pair of RAID1 members and pointing GRUB to one or the other
> of the disks so it can chain load from what it thinks is an ordinary primary
> partition.  Once initrd loads and md is active, it assembles the arrays and
> then the kernel mounts / and then /boot, and booting continues normally.
>
>        The cause: When dpkg instructs grub-pc to configure itself, it fails
> because it is unable to reconcile the information in /boot/grub/menu.lst
> with the hardware mounted by /etc/fstab.
>
>        The cure? : I was thinking I should be able to comment out the
> entries for /dev/md1 in /etc/fstab  and /etc/mdadm/mdadm.conf, and reboot
> the system.  Then I think I can
>
> 1.  Mount /dev/hda1 to /boot.
>
> 2.  Upgrade GRUB, which should now understand both /etc/fstab and
> /boot/grub/menu/lst.
>
> 3.  Reboot to make sure it works.
>
> 4.  Edit /boot/grub/grub.cfg and /boot/grub/device.map to let GRUB2 know it
> should be booting from an array and to make sure it is loading the RAID1
> module.
>
> 5.  Umount /boot and create a new 1.0 superblock RAID1 array using only
> /dev/hda1 and a missing member.  Mount the new array as /boot.
>
> 6.  Add the new array info into /etc/mdadm/mdadm.conf and change /etc/fstab
> back to mount /dev/md1.
>
> 7.  Run update-initramfs to copy the new configuration into initrd.
>
> 8.  Reboot and make sure GRUB2 can now boot into the new array.
>
> 9.  Add /dev/hdb1 into the new array, and re-sync the array.
>
> 10. Update /etc/mdadm/mdadm.conf with the full array info, getting rid of
> the missing member, and remove the reference to the old array altogether.
>
> 11. Run the GRUB update routine to remove the chain-load from GRUB legacy.
>
> 12. Run update-initramfs to copy the final configuration into the initrd (if
> GRUB update doesn't already do it.)
>
>        Is my thinking correct, here?  Have I missed a step?  Up until step
> 9, I should be able to easily revert back to my original configuration by
> simply removing the comment for the old array, forcing an assembly of the
> old array using only /dev/hdb1, add back /dev/hda1, resync the array, remove
> the comment from /etc/fstab and run update-initramfs.
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

IIRC Grub 1.97 ('2') supports the 0.90 metablock format but not the
1.0 metablock format.  You might just backup the contents of /boot and
make that small pair of partitions use the older format (re-create
that array).  For /boot 0.90 should be sufficient in most cases.

However, I've not tested grub 2 with mdadm. Only my ubuntu laptop uses
grub2; both gentoo and arch (as of the last time I looked) were still
using grub legacy.

In fact, if grub supports the older metablock format but not the newer
maybe you should file/attach to a bug about it.
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Upgrading to GRUB2 from GRUB Legacy on RAID1

[Leslie Rhorer]

> IIRC Grub 1.97 ('2') supports the 0.90 metablock format but not the
> 1.0 metablock format.  You might just backup the contents of /boot and
> make that small pair of partitions use the older format (re-create
> that array).  For /boot 0.90 should be sufficient in most cases.

	Actually, it's 1.98 in Debian "Squeeze", now, and perhaps higher in
the wild.  You are correct, though.  After getting nowhere on any of the
mailing lists and failing to get a response from the developers, I tried
moving to a 0.9 superblock, and it worked.  Thanks for the response, though.
Anyone who wants to boot from an array with more than 26 elements or any
elements more than 2T in size is hosed...  Fortunately, my boot partition is
only 5G x 2 drives RAID1, and even that is 90% empty.  It only took seconds
to tar the contents of /boot and start testing.

> However, I've not tested grub 2 with mdadm. Only my ubuntu laptop uses
> grub2; both gentoo and arch (as of the last time I looked) were still
> using grub legacy.

	It works, but as you mention, only with 0.9 superblocks.  It is not
at all obvious this is the case from the errors one encounters.  When I
tired my work-around and it STILL did not work, it began to become more
obvious it was the superblock issue.  The thing that gets me is I
specifically asked about the 0.9 bug - had it been fixed? - in the GRUB
mailing list and several places online.  No one answered me, at all.

> In fact, if grub supports the older metablock format but not the newer
> maybe you should file/attach to a bug about it.

	Yeah, I will this weekend if I get a chance.  I'll definitely update
the existing bug report.