grub misinterprets md/raid device

[Max Barry]

Binary package hint: grub2

I have a RAID5 mdadm array on /dev/md0. It is fully functional but I cannot boot from it because grub detects it as "/dev/md/0" (with an extra slash). Running "update-grub", for example, produces a grub.cfg with the lines "set root='(md/0)'". Upon rebooting, grub reports "error: file not found" and drops into a rescue shell.

Some (or all) disks in this array were previously used in a RAID array using mdadm metadata version 0.90. Now, however, they are using version 1.20. Since mdadm puts metadata v1.20 in a different location, I wonder if perhaps there's a ghost of the old 0.90 metadata hanging around, which is confusing grub.

$ sudo mdadm --detail --scan
ARRAY /dev/md0 metadata=1.2 name=eve:0 UUID=98ab8ad1:23e4df2e:d8bb3605:b9be0e1f

$ sudo mount /dev/md0 /mnt/raid
$ sudo mount --bind /dev /mnt/raid/dev
$ sudo mount --bind /dev/pts /mnt/raid/dev/pts
$ sudo mount --bind /proc /mnt/raid/proc
$ sudo mount --bind /sys /mnt/raid/sys
$ sudo chroot /mnt/raid
# ls -l /dev/md*
brw-rw---- 1 root disk 9, 0 2011-02-06 11:14 /dev/md0
# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active raid5 sdc1[1] sda1[0]
      968576000 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
# grub-mkconfig | grep 'set root'
Generating grub.cfg ...
set root='(md/0)'
Found linux image: /boot/vmlinuz-2.6.35-25-generic
Found initrd image: /boot/initrd.img-2.6.35-25-generic
 set root='(md/0)'
 set root='(md/0)'
Found linux image: /boot/vmlinuz-2.6.35-24-generic
Found initrd image: /boot/initrd.img-2.6.35-24-generic
 set root='(md/0)'
 set root='(md/0)'
Found linux image: /boot/vmlinuz-2.6.35-23-generic
Found initrd image: /boot/initrd.img-2.6.35-23-generic
 set root='(md/0)'
 set root='(md/0)'
Found linux image: /boot/vmlinuz-2.6.35-22-generic
Found initrd image: /boot/initrd.img-2.6.35-22-generic
 set root='(md/0)'
 set root='(md/0)'
Found linux image: /boot/vmlinuz-2.6.32-25-generic
Found initrd image: /boot/initrd.img-2.6.32-25-generic
 set root='(md/0)'
 set root='(md/0)'
Found memtest86+ image: /boot/memtest86+.bin
 set root='(md/0)'
 set root='(md/0)'
Found Microsoft Windows XP Home Edition on /dev/sdb1
 set root='(hd1,msdos1)'
done

$ lsb_release -rd
Description: Ubuntu 10.10
Release: 10.10

$ apt-cache policy grub-pc mdadm
mdadm:
  Installed: 2.6.7.1-1ubuntu16
  Candidate: 2.6.7.1-1ubuntu16
  Version table:
 *** 2.6.7.1-1ubuntu16 0
        500 http://mirror.aarnet.edu.au/pub/ubuntu/archive/ maverick/main amd64 Packages
        500 http://au.archive.ubuntu.com/ubuntu/ maverick/main amd64 Packages
        100 /var/lib/dpkg/status
grub-pc:
  Installed: 1.98+20100804-5ubuntu3
  Candidate: 1.98+20100804-5ubuntu3
  Version table:
 *** 1.98+20100804-5ubuntu3 0
        500 http://mirror.aarnet.edu.au/pub/ubuntu/archive/ maverick/main amd64 Packages
        500 http://au.archive.ubuntu.com/ubuntu/ maverick/main amd64 Packages
        100 /var/lib/dpkg/status

[Max Barry (max-maxbarry)]

Additional information here:

http://ubuntuforums.org/showthread.php?t=1681190

[Max Barry (max-maxbarry)]

I should perhaps also mention I tracked it as far as this line:

http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/maverick/grub2/maverick/view/head:/disk/raid.c#L584

But I don't know enough to interpret that code.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Matt Mossholder (matt-mossholder)]

Yeah, this has bitten me too. GRUB2 is looking for md devices to use the new style /dev/md/# device naming, rather than the old /dev/md# style. As a short-term fix, simply creating the /dev/md directory, and creating symlinks to the actual device nodes seems to work.

Example:

mkdir /dev/md
ln -s /dev/md0 /dev/md/0

[Marcus Tomlinson (marcustomlinson)]

This release of Ubuntu is no longer receiving maintenance updates. If this is still an issue on a maintained version of Ubuntu please let us know.

[Launchpad Janitor (janitor)]

[Expired for grub2 (Ubuntu) because there has been no activity for 60 days.]