On Fri, 2004-06-25 at 10:05 -0500, Matt Domsch wrote: > On Fri, Jun 25, 2004 at 10:53:45AM -0400, Jeremy Katz wrote: > > On Thu, 2004-06-24 at 15:40 -0500, Matt Domsch wrote: > > > Patch below against 2.6.7-bk(current) gives mbr_signature for first > > > six BIOS disks. > > > > Seems to work, at least for two (all that I have handy on a test machine > > right now). > > Cool. I realized last night that we sell servers with 12 disks in the > main 7U chassis, not counting any external storage. So I'm reworking > to code to allow storing MBR signatures for up to 16 disks. There's > no real BIOS limitation at 16 or lower, but in practice it's rare to > see more BIOS disks than this, and it takes 4 bytes of the real mode > boot_params block per signature we might want to store, so I don't want > it to get out of hand. That works for me. > > Unfortunately, the mbr_signature on both of those disks > > (and the sig on the first from before rebooting into the newer kernel) > > is 0x00000000. So I guess these don't have any guarantee of uniqueness? > > Right. The uniqueness guarantee has to come from whatever writes the > signatures to the disk in the first place. There should have been in > Rez's code a little chunk which, when it detects non-uniqness among > the disks visible to Linux, it writes unique signatures to those > disks, then reboots, such that when we restart, all the disks have > unique signatures. Hmmm, I didn't look at eddsupport.c that closely as I guessed it was just reading and correlating. I guess I should have :/ Having a reboot like that is pretty much a non-starter because there's no way to guarantee that the user will get rebooted back into the installation. Instead, a good error message is probably the best that can be done. And probably also include a silly little program to write out unique sigs that could be run for people who so desire. > fdisk and parted presently always write zeros to the 4-byte signature > field at offset 0x1b8 in the MBR. Dell's factory install tools will > write a unique signature to each BIOS-visible disk, so we're good > there. Anaconda will need similar code. Well, for anaconda to do it the best thing is actually to get parted doing so. I'd rather not have to have a weird hack in anaconda for this as it requires keeping track of things like what partition table type it is and only doing it if we're on MS-DOS. Whereas parted already knows this when it goes to create a new partition table and we'd just need to update the initial MBR_BOOT_CODE it writes out (I'm guessing that's the bit that the signature is included in from quickly looking) Jeremy
