Re: EDD disksigs for disks other than 0x80

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Kickstart]     [Fedora Users]     [Fedora Legacy List]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]
  Powered by Linux