GRUB problem with /boot on RAID 1

English Install/Boot/Login
#1

Hi, all.

I’ve got a relatively simple filesystem layout. I have a half-gig RAID 1 /boot, some swap, and the rest of my disks in a RAID 1 / partition.

Here’s an example of my grub session, where I try to install. I’m taking my kernel parameters from /boot/grub/menu.lst.

*grub> root (hd0,0)
Filesystem type is ext2fs, partition type 0xfd

grub> kernel /vmlinuz-2.6.27.7-9-default root=/dev/md1 resume=/dev/disk/by-id/ata-WDC_WD2500KS-00MJB0_WD-WCANKF763144-part2 splash=silent showopts vga=0x348

[Linux-bzImage, setup=0x3000, size=0x271ce0]

grub> initrd /initrd-2.6.27.7-9-default

Error 16: Inconsistent filesystem structure
*

#2

I have a similar setup. Grub cannot handle a RAID filesystem; error #16 means grub can find the partition but “the filesystem type cannot be recognized by GRUB.” With grub, you need to treat the array you mount on /boot as individual partitions. (You can of course use an array in the root phrase on the kernel line; grub isn’t using that, it’s just passing it to the kernel as is.) So make sure your /boot/grub/device.map uses sda for (hd0). This is my device.map:

(hd0)   /dev/sda
(hd1)   /dev/sdb
(hd2)   /dev/sdd
(hd3)   /dev/sde
(hd4)   /dev/sdc
(hd5)   /dev/sdf

My /dev/md0 array, mounted at /boot, consists of sda1 and sdb1. This is an extract from my menu.lst:

    root (hd0,0)                                                        
    kernel /vmlinuz-2.6.25.18-0.2-default root=/dev/disk/by-label/md-root resume=/dev/sdd6 splash=silent showopts vga=0x317                                                                                              
    initrd /initrd-2.6.25.18-0.2-default

Hope that helps.

#3

Hm, I see nothing changing. I’ve got device.map thinking of hd0 as sda:

/boot/grub # cat /boot/grub/device.map
(hd0)   /dev/sda
(hd1)   /dev/sdb

But I’m getting that same error:

grub> initrd /initrd-2.6.27.7-9-default 

Error 16: Inconsistent filesystem structure

My set-up sounds sufficiently similar to yours that I’d expect it to work for me if it works for you.

Is there any chance that it’s failing because I’m booted from the disk onto which I’m trying to install? I’m not at the box presently, but I will be tonight, and I can test that theory - unfortunately, I have no remote console on the thing (it’s a desktop) so it’ll be a few hours before I get the chance to try it from external media. And at that, I’m grasping at straws :slight_smile:

I remember at some point in the past the notion that my initrd had to have MD drivers built into it, and I notice that you’re using an older initrd and kernel than I am. Is there any chance that my initrd doesn’t have the MD stuff built-in? I’m using what I got from the net install CD for 11.1.

Thanks in advance for any additional light you can shed. If worse comes to worse I’ll break the raid for the boot partition and just duplicate it by hand whenever it changes, but that seems like a silly thing to have to do. :slight_smile:

Thanks again.

#4

I’m afraid I don’t have a good answer. Some things I would try:

Boot from a grub floppy. The grub shell standalone uses a different method of finding the disks than when run from the OS. You can create a floppy without device.map and menu.lst, the shell will then use the bios map. Doubtful this will help, but I have found it a useful tool.

The initrd would need to have the underlying disk controller and filesystem drivers of course, but AFAIK not for RAID 1 - that’s built into the kernel mainline now. But I would rebuild the initrd anyway.

Use mdadm to check the md0 superblock, e2fsck on the md0 filesystem.

That’s all I can think of, short of breaking the array. That would at least tell you whether it is the RAID that is getting in the way somehow. If you can’t use the vanilla boot partitions either, then the problem is elsewhere. Might be interesting to create a copy of /boot on another partition, and use it for the grub root command.

Let us know what you find.