> unfortunately Christophe's patch only work for linear device-mapped devs (eg. lvm2) > and Gerte's patch only works for mirrored device-mapped devs (dmraid) > we would nee a good mix of those two patches. Thanks, Luca! Perhaps it's time to try GRUB again. Every time I've touched GRUB, I've been burnt badly. Seems to me it's destined to write random data to weird places on the disk and overwrite critical structures. Guess there has to be a way to make GRUB behave itself though, since there seems to be people using it :-). *Sighs*. I only need to tell the bootloader that this-and-that device corresponds to BIOS device 0x80. No remapping of sectors or any such fancy is needed. It's hard to believe that this is still a problem.. Not to mention that the preferred way to do this in Linux is still to take a wild guess!! (That goes for both GRUB and LILO, I think?) I know that Linux does not have any guarantees wrt which order the BIOS chooses to activate disk controllers. I know that often, there isn't a disk-level signature in the MBR accessible thru INT 13h / from boot loader code. But let's make one up ourselves and save every Linux user on the planet some pain. Just take the first big hunk of data off each disk on bootup, using INT 13h, and calculate a MD5. When the kernel has finished bringing IDE drivers and device-mapper devices up, do the same thing once again. Compare signatures, and you've got a perfect bios<->linux drive map. Only error situation that can occur is that you have two disks with exactly the same signature. That's an easy situation to handle: Bail out with an error, and leave them out of the drive map. Better yet, include both, so applications can see there's a problem and present a choice to the user. I see how there might be a potential problem with RAID1 arrays. On some controllers, the metadata lives near the end instead of at the disks' head, and a md5 of the first data chunk of the mirrored disks would be identical. Simple to solve. Calculate the md5 based on data from both the beginning and end of the disk. One could even make the algorithm account for all current and future RAID controllers with different offsets by adding a number to the signature that indicates how many sectors the boot loader code had to compare from the beginning and end of each disk before it had unique signatures. Needless to say, there should be a (perhaps adjustable) maximum on how many sectors the boot loader would be allowed to traverse. What's the problem with this approach? Why hasn't it been done yet? I imagine I'm overlooking some major technical difficulty, or perhaps the idea has been patented? If you know of any prior discussion on this topic, I'd be interested in a pointer..
