grub should support dmraid fakeraids

[Tormod Volden]

Setting up grub is a pain if you have installed to a "fakeraid" which uses the dmraid package. It seems like the grub utilities have some support for the software raids (which appear under /dev/md*) but not for dmraid (which appear under /dev/mapper).

There are plenty of things to be fixed in the installer for dmraid support, but I would like to track the grub part here.

[Tormod Volden (tormodvolden)]

This patch adds some dmraid support to update-grub, at least as much as for the software raids:

If update-grub detects your root on /dev/mapper it will check if it is a dmraid, and then decode which real disk this resides on. (Currently, it will pick the first disk from the raid set.)

For upgrade-grub to write out the correct #groot from this, the real disk has to appear in device.map, for instance:
hd(0) /dev/sda

Making upgrade-grub to directly interpret a raid device in device.map and not worry about the linux name of the real device is work-in-progress:
hd(0) /dev/mapper/your_raid_device
I am not even sure that this should be done, depending on what other utilities might use device.map for.

[Phillip Susi (psusi)]

I do not understand the problem you describe here. I have no trouble installing grub on a fakeraid. Also you do NOT want grub to install to /dev/sda, you want it to install to the /dev/mapper device. Of course, grub assumes that hd0 is /dev/sda, so to install it you do need to edit device.map to point it to the correct mapper device instead.

[Tormod Volden (tormodvolden)]

Thanks, I guess some of my assumptions are wrong. I never understood the full usage of device.map, is it only used by grub when installing itself to a boot sector? I mean, when grub is booting, hd(0) is not the raid device but one of the disk. Or does the fakeraid BIOS correctly present the raid as hd(0)? What is hd(1) then? I supposed that the first cylinder on the first drive would equal the first sector on the raid device anyway, whether it is RAID-0 or RAID-1.

Anyway, IIRC from when I wrote the above, update-grub would just fail and not install grub to the raid, if just specifiying the raid device. Which again made grub-installer on the installer CDs fail. This is the real problem I wanted to treat here. I will check again with feisty when I have some time, maybe next week.

[Phillip Susi (psusi)]

Yes, device.map is only used by grub to figure out the relationship between linux kernel device names and bios device numbers. Grub uses the notation (hd0) to name the first hard disk in the system, (hd1) for the second, and so on. To the bios the first hard disk is identified as device 80h to the int13 disk service interrupts. When installing though, grub has to open the device and go through the kernel to access the disk so it needs to know the correct device name to open that corresponds to hd0. That is where device.map comes in. The fakeraid bios handles requests for bios disk 80h correctly to provide access to the raid as if it were just one big hard disk.

When you say update-grub would fail if specifying the raid device, do you mean editing device.map to point hd0 to the /dev/mapper device? Also could you be more specific about it failing? Such as any error message it gives? If device.map is set up to correctly map the device to hd0 everything should work.

[Tormod Volden (tormodvolden)]

> The fakeraid bios handles requests for bios disk 80h correctly
But what is on hd(1) then? Exactly the same raid device, but appearing twice? I guess this is what has been confusing me into thinking grub sees the raw disks.

> Also could you be more specific about it failing?
This was some time ago, and I would have to try again. I thought I had tried that mapping as well (since I mention it in comment #1). But looking at the update-grub script: it tries to convert the root (or boot) device to a grub root device. I think it failed converting my /dev/mapper/my_raid3 to (hd0,2) and instead returned (hd0,0) (the default, failover). Maybe the more lucky ones among us have their boot partition on (hd0,0) and then they won't experience this bug.

Anyway, for sure, running the installer CD things did not work, because it didn't know how to handle having root on /dev/mapper/my_raid3.

[Phillip Susi (psusi)]

(hd1) is the second hard disk in the sytem, which you won't have assuming you only have one raid set and no other disks.

I seem to remember having to change the default from (hd0,0) myself when I first installed grub, but it was so long ago I forget now. Looking at the code though, I think that is the case. It looks like it will need modified to not bail out and default to (hd0,0). Defaulting to hd0 is fine, but it should try to extract the partition number if it can.

[Tormod Volden (tormodvolden)]

> (hd1) is the second hard disk in the system, which you won't have assuming you only have one raid set and no other disks.

Well I do have. From BIOS/grub they seem identical, that's why I thought I saw raw devices. When I plug in a USB stick, it becomes (hd2).

> Defaulting to hd0 is fine, but it should try to extract the partition number if it can.

Yes, and that's exactly what my patch tried to do.

[mobiusNZ (mobiusnz)]

Grub supports fakeraid fine - you just need to teach it a little.

From the grub prompt, run

device (hd0) /dev/mapper/[the_raid_entry]

Then find /boot/grub/stage1 as normal.

Could the update script not do this?

[Gaetan Nadon (memsize)]

Thank you for taking the time to report this issue and helping to make Ubuntu better. Examining the information you have given us, this does not appear to be a bug report so we are closing it and converting it to a question in the support tracker. We appreciate the difficulties you are facing, but it would make more sense to raise problems you are having in the support tracker at https://answers.launchpad.net/ubuntu if you are uncertain if they are bugs. For help on reporting bugs, see https://help.ubuntu.com/community/ReportingBugs .
BugSquad