[Top][All Lists]

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

Re: Grub Failure when HDD descriptor changes

From: Jason Thomas
Subject: Re: Grub Failure when HDD descriptor changes
Date: Wed, 23 Mar 2005 09:10:06 +1100
User-agent: Mutt/1.5.6+20040907i

On Tue, Mar 22, 2005 at 03:00:58PM -0500, pjones wrote:
> On Tue, 2005-03-22 at 19:41 +0100, Molle Bestefich wrote:
> > Oh, but there is a way.
> > 
> > You could, at boot-up, calculate a md5 hash based on the first sector
> > of every disk.  If there's a duplicate hash, load the last sector of
> > every disk also and calculate the md5 based on both.  If there's still
> > duplicates, add one more sector from the head of the disk.  Continue
> > till you have completely unique hashes, or, a (user-definable) maximum
> > number of sectors to traverse has been reached.
> >
> > When Linux has finished bringing up IDE drivers and device-mapper
> > devices, scan the disks again.  (The bootloader should probably
> > include information next to the md5 hashes on how many sectors it had
> > to scan).  There you go, Linux can easily tell which BIOS disks map to
> > which Linux disks.  :-).
> This idea's been entertained in a rather wide swath of different
> methods.  It doesn't work.  If you're installing the OS and you've got
> two identical disks, in both geometry and data (that is, disks that
> Seagate says passed their burn-in tests, or that were just retasked from
> an existing raid1 setup which haven't been artificially made unique),
> you get a collision.  And that's the very time you need to know where to
> install a bootloader.

What about Serial Numbers from the drives? Do they all have them, are 
they unique?

Why can't we use a combination? Look for the serial number, if missing 
look at the data.

But how does this work when installing? Nothing has had a chance to do this yet.

Something really needs to be done.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]