3

I've been trying to get my raid to boot from grub2 for about 2 days now and I don't seem to be getting closer. The problem appears to be that it doesn't recognize my raid at all. It doesn't see (md0) etc. I'm not sure Why or how to change this. I'm using mdadm, 2 device (essentially a raid1) raid10,f2, which is currently degraded.

I have tried adding the raid and mdraid modules with grub install along with others. I've tried several variation on grub-install such as grub-install --debug --no-floppy --modules="biosdisk part_msdos chain raid mdraid ext2 linux search ata normal" /dev/md0

I've been searching the net for an answer to what I haven't done but no luck. On my other drive which I plan on removing the raid is initialized and mounted fine on boot, but it's not the boot/root for that setup. My grub.cfg isn't recognized by grub since it can't read the raid partition so I'm not posting that. md0 is not listed in my /boot/grub/device.map.

xenoterracide
  • 1,476
  • 2
  • 12
  • 26

3 Answers3

2

Don't forget GRUB2 is still in a development stage, so if you want to use it... it is at your own risk.

Given the above, I think you'd be best advised to get the latest source and compile to see if that fixes any issues you may be seeing. You should be using version 1.9.6 at least, as the docs say, and make sue your raid is built using the v0.90 mdadm metadata superblock.

For example, to create a "-l 10" RAID1 device for the /boot file system, with "-n 4" disks and "-x 0" spares:

mdadm --create -e 0.90 -n 4 -x 0 -l 1 /dev/md2 /dev/sda2 /dev/sdb2 [/dev/sdc2 /dev/sdd2 ...]

And in testing with mdadm v3.2.3, grub 1.99-21ubuntu3, only the boot file system needed metadata 0.90, not the root. And raid10 didn't work after a disk was removed, so example is raid1 above. (another question related to raid10 here)

gbjbaanb
  • 3,852
  • 1
  • 22
  • 27
  • 2
    grub1 never left the development stage... some gnu projects seem to do that... anyways it was the fact that I wasn't using 0.90 for metadata. I set those on root/boot and now it works fine. – xenoterracide May 16 '10 at 13:50
0

Updating for current software versions (Ubuntu 14.10):
Grub2 2.02~beta2-15

I set up my partitions and made md devices on them, then ran mkfs on them. THEN I started Ubuntu's installer (ubiquity). (If you don't mkfs first, ubiquity insists on partitioning your md devices. IDK if grub will handle a partition table inside an MD on a partition.)

With / (including /boot) on XFS on a RAID10,f2 of 2 disks, GRUB has no problem booting, even when on disk is missing. (There is currently, or was, a bug where GRUB thinks a RAID10 is unusable if it's missing 2 devices, without checking WHICH two devices are missing. So there are cases where Linux would have no problem using a degraded RAID10, but GRUB's simple check fails.)

(XFS notes: grub2 2.02 beta2 does NOT support XFS's new mkfs.xfs -m crc=1 metadata format. Don't use that on the filesystem that includes /boot until you get a patched GRUB.)

I tested with a chunksize of 32kiB for my RAID10,f2 to make sure vmlinuz and my initrd were not contiguous on disk. I didn't test with a configuration that would require GRUB to read from multiple disks to get a complete file, though, so I still don't know if that's supported. (I think not though: I tested from the GRUB command line (after normal.mod was loaded, not from a grub recovery console).

ls (md/0)
blah blah holds an XFS filesystem
ls (md/1)
<machine reboots instantly>
 or booting with only one disk connected:
error: failure reading sector 0xb30 from `fd0'.
error: disk `md/1' not found.

(Intel DZ68DB mobo, disks on the mobo's SATA controller (set to RAID, not AHCI, in case that matters)) So I guess it's looking for a partition with the right UUID to complete the RAID0.

My RAID10,f2 used the default metadata 1.2 format (located at 4kiB from the start of the partition). Since grub understands md devices these days, you don't need the old practice of hiding your md superblock at the end of the partition (which you could get with format 1.0, as well as 0.9 I think.) I didn't test if grub also supports the ddf or imsm (BIOS raid metadata formats used by some mobo controllers).

Both my disks had GPT partition tables, with a EF02 Bios boot partition before the first "regular" partition. (from sector 40 to 2047). Grub uses it to put the stuff it needs to read RAID and XFS, but that doesn't fit in the 512B boot sector.

Don't RAID your bios boot partitions. You need to grub-install each /dev/sdX independently, so you can boot any of your disks. Doing that also writes what grub needs to the BIOS boot partition on that disk. update-grub doesn't touch the bios boot partition, it just rebuilds the menu and initrd from config files. Only grub-install touches the boot partition, and like I said, needs to be run on each disk anyway.

Testing actually booting with one HD removed: Ubuntu gives an interactive option to skip mounting filesystems that aren't available. (I had /var/cache on RAID0). But after telling it to skip, it's fine.

Peter Cordes
  • 457
  • 4
  • 10
0

For anyone scrolling down this far, I had this issue trying to get Ubuntu 16 / 14 to boot off of a 24 disk SW RAID 10.

The key turned out to be setting the /boot partition to RAID 1; Grub apparently doesn't like RAID 10. The rest of the system, the swap partition and the root partition ("/"), were set to RAID 10.

Locane
  • 409
  • 1
  • 7
  • 20