Re: [RFC][PATCH] unique sigs in the msdos label

[Matt Domsch]

On Sat, 26 Jun 2004, Andrew Clausen wrote:
> On Fri, Jun 25, 2004 at 05:38:11PM -0500, Matt Domsch wrote:
> > I've got Linux kernel code which tries to determine what the BIOS boot
> > disks are by storing the "mbr_signature" field (offset 440 in the MBR,
> > which is at the end of the boot_code section) for each of the
> > int13_dev8x devices, and presenting this to userspace through
> > /sys/firmware/edd/int13_dev8x/mbr_signature.  Then userspace can read
> > the MBR itself from /dev/{sda,hda,...}, compare the signatures, and
> > match disks.  This works if system-unique values are stored in each
> > disk's mbr_signature field in the MBR, and doesn't rely on BIOS EDD
> > 3.0 to be available, or if available, correctly implemented. :-)
> 
> What about partition tables that were created by Microsoft?

Windows NT and later store their own 32-bit unique signature here at 
partition table creation, and the "Disk Administrator" (older NT) or 
"Disk Management" (>=W2K) tools ensure they're unique across the system.  
If you've ever moved a disk from another system into yours and run these 
tools, you'll see it prompt you to write a signature to the disk, and 
maybe reboot.

NT keeps track of the mapping between BIOS device and NT's device name 
using these in dynamic registry entries, populated at system boot.

http://support.microsoft.com/default.aspx?scid=kb;en-us;227704
describes how and when they write signatures.
 
> This is only going to be a problem with >1 disk anyway, right?

Right, and in general, > 1 disk on multiple disk controllers.

> If there is >1 partition table, aren't the partition tables going
> to be different, anyway?  Use memcmp?
> I guess this could be useful for RAID mirrored disks?

Not necessarily.  One could easily generate the same partition table for 
sd[bcdefgh] in an 8-disk system where you put software RAID across them.


My particular concern is determining which disk BIOS believes is the boot 
disk.

Consider this scenario (not terribly uncommon):

Dell PowerEdge server.
* Adaptec RAID-on-Motherboard controller, two disks in hardware RAID1, so 
they appear as a single disk to BIOS and to Linux.  BIOS set to boot from 
this.

* LSI RAID add-in card, configured with one or more logical drives.
BIOS enabled or disabled, whichever.


Linux installers load device drivers in some order.
1) If we get lucky, the aacraid driver is loaded first, so our BIOS boot
disk becomes /dev/sda, then megaraid driver with logical drives on /dev/sdb.
2) If we get unlucky, the megaraid driver is loaded first, so the
non-boot-disk is /dev/sda, while our boot disk is /dev/sdb.

The OS installer writes to /dev/sda of course, and all goes
swimmingly, until the system is rebooted, at which point it fails to
boot because the boot loader is on the wrong disk.


The same scenario plays out with multiple LSI add-in cards and only
one driver (megaraid) loaded, as the driver doesn't even know which
controller/disk combo BIOS is using as the boot disk.

We sell a lot of such scenarios.  A human can intervene, and with some
trial-and-error (moving cards in PCI slots, unplugging cables during
install and then plugging them in later, disabling BIOS on various
adapters, ...), get it all right.  Automated factory install processes can't.


The unique signature is used such that having obtained it from the
int13 real mode call, and comparing against what is read under Linux
protected mode, Linux userspace can create a mapping of
linux-disk-name <-> BIOS device number, and thus can know where to
install to.

Thanks,
Matt

-- 
Matt Domsch
Sr. Software Engineer, Lead Engineer
Dell Linux Solutions linux.dell.com & www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com