dmraid -r -vvv and dmraid -s -vvv fail to identify any raid disks.

In this setup, my disks are not actually raided together.

If I do need to extract sectors by hand,
dd if=/dev/hde skip=9 count=1
will output sector 9 to stdout, right?

I just had a quick look, and sector 9 on the primary hard disk doesn't
look anything like the structure in dmraid's hpt37x.h. It's possible
that I overwrote this sector a long time ago with grub, and it doesn't
get restored by the BIOS unless I go into the BIOS and change the RAID
configuration. Which indicates that detecting the on-disk format is a
little fragile.

Does `dmraid -r -vvv' or `dmraid -s -vvv' show anything useful for you? I.e. something like:
NOTICE: /dev/sda: nvidia metadata discovered?

htp37x.h mentions a DATAOFFSET of 10
For my NVIDIA fake RAID this is set to 0
In hpt37.c it says:
        /* Data offset from start of device; first device is special */
        rd->offset = hpt->disk_number ? HPT37X_DATAOFFSET : 0;

So please check sector 9 of your first disk and maybe Sector 10 and 19 of your 2nd one.

http://www.mail-archive.com/bug-grub@gnu.org/msg09759.html confirms sector 9, BTW. http://www.wensley.org.uk/raid suggests the entirety of sector 9 except the first 32 bytes is used.

lib/format/htp37x.h in dmraid appears to define a structure for the HPT37x metadata, so maybe we can detect this after all?

A brief glance at this code suggests that the data is all in sector 9, but is in sector 9 of each physical disk on the relevant machine. I can't check this right now, I accidentally did a grub-install hd0 since my last reboot, so once I next reboot I can confirm the metadata's presence on a machine without a RAID setup.

Sector 9 on my second disk (also on the RAID controller) contains nulls and then NULL NULL "Found a array member was" 0x20 x 22, repeated 8 times, up to the 60 bytes of filler mentioned in the dmraid structure. I dunno if this means the ondisk metadata format only applies to the first physical disk (seems likely) and the BIOS uses sector 9 on the other disks for scratch, or what.

I hope that helps?

By the by, everything else in dmraid's ataformat headers stores its metadata offset from the end of the disk, which is why this problem seems localised to the HPT3xx devices.

Do you have any idea on how to check for the presence of that controller?

Can you find the exact sector and size of the affected region?

Can you provide more details on the workaround?  If you embed core.img after the MBR, chances are it'll be overwritten, right?  What offset do we need?

We've moved to GRUB 2 as a development platform.  Please can you check if this bug still applies there, and if it does, reopen it?

Thanks