3

Summary: I created a copy of the root file system on a RAID array (with one disk on it), I tried to get the system to boot off that newly copied drive.

Background:

  • 2 disks of the same size in server (sda, sdb)
  • sdb not being used
  • I tried to transition the whole thing to a RAID1 mirror
  • current active partitions:
    • sda1 - boot
    • sda2 - swap
    • sda3 - root (mounted to "/")

I am not sure if it's possible to make a full RAID1 system able to boot off any of the drives, since I do not have KVM access (I can only tell them to help me out of a jam via a trouble ticket)

What has been done so far:

  • Created partitions on sdb to match sda
  • Created new raid1 array (with 1 disk)
  • /dev/md3 consists of 1 disk: /dev/sdb3
  • mounted /dev/md3 /mnt/md3
  • cp -ax / /mnt/md3
  • So now I have matching copies of data on / and /dev/md3

Can I just edit GRUB2 to make /dev/md3 the root? Everything should be OK, right?

I need to be absolutely sure, since I have no KVM access. I looked at /boot/grub/grub.cfg and I saw this entry:

menuentry 'Ubuntu, with Linux 2.6.32-28-generic-pae' --class ubuntu --class gnu-linux --class gnu --class os {
    recordfail
    insmod ext2
    set root='(hd0,1)'
    search --no-floppy --fs-uuid --set 18de6bbd-e46d-4f89-a2c9-fa2e7fa718b7
    linux   /vmlinuz-2.6.32-28-generic-pae root=/dev/sda3 ro   
    initrd  /initrd.img-2.6.32-28-generic-pae
}

So, note the "root=/dev/sda3" part. Can I just replace that with "root=/dev/md3", then reboot??

1
  • 1
    I understand that editing the grub.cfg is not the best way since it will be overwritten by updategrub script... but just trying to get it working for now.
    – timh
    May 25, 2012 at 19:31

2 Answers 2

1

Assuming that the filesystem is directly on /dev/md3 (and you're not partitioning it or using LVM), yes, setting root=/dev/md3 is what you want. Things you should check though:

  1. Rebuild the initrd and check that it contains RAID support (you may need to coax it since the current root isn't on RAID, by adding raid1 to /etc/initramfs-tools/modules).
  2. Make sure that booting from a degraded array[0] is enabled (Ubuntu disables this by default: set BOOT_DEGRADED=true in /etc/initramfs-tools/conf.d/mdadm)
  3. Duplicate the GRUB entry and set a fallback entry in GRUB so that it (hopefully) boots the non-RAID disk if the RAID disk fails to boot (add a set fallback="2" line to /etc/grub.d/40_custom, where the number is the number of the menuentry counted from 0).
  4. Possibly also use grub-set-default --once instead of setting the default explicitly so that rebooting the machine is sufficient to boot the non-RAID disk.

[0]: Your array may actually not be degraded, but you probably want this anyway.

5
  • great info. some clarifications. correct, no lvm. /dev/md3 is a raid array consisting of /dev/sdb3, which is a partition of sdb of type linux raid autodetect. re: #3, I saw different conflicting posts about how to setup the fallback, such as the on here:ubuntuforums.org/showthread.php?t=1195275. Note that I am using GRUB2... When I tested fallback it didnt seem to work. I'll have to look into that more. Re: #4. GREAT IDEA... that way i can just power cycle it if it doesnt work. thanks!
    – timh
    May 25, 2012 at 23:00
  • argh... why cant post code in comments?
    – timh
    May 25, 2012 at 23:02
  • this is the link that said to add the 01_fallback script into /etc/grub.d: translate.google.com/…
    – timh
    May 25, 2012 at 23:04
  • I haven't actually used fallback on GRUB 2 myself, so I'm not sure how and if it works. Using grub-set-default --once should be sufficient (although I haven't actually used this either...)
    – mgorven
    May 25, 2012 at 23:32
  • @timh It looks like that script tries to automatically choose a fallback entry. You should be able to manually select it with a set fallback="2" entry in grub.cfg (or /etc/grub.d/40_custom to do it properly). Entries are numbered from 0.
    – mgorven
    May 26, 2012 at 3:14
1

Unfortunately following mgorvens advice will most likely lead to an unbootable system, the devices in /dev may not match your current booted environment, on top of which you should set root to the UUID of your raid disk, NOT a dynamically assigned /dev entry. Luckily though grub will handle all of this for you automatically, just do this:

sh -c /etc/grub.d/30_os-prober

Assuming you see a menu entry containing your raid device then update grub2 by doing:

grub2-mkconfig > /boot/grub2/grub.cfg

This will update your grub boot menu the right way, you don't want to edit that grub.cfg file manually anyway, as it will most likely get overwritten when grub is updated.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .