Re: Grub Failure when HDD descriptor changes

[Yoshinori K. Okuji]

On Tuesday 22 March 2005 07:41 pm, Molle Bestefich wrote:
> 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.

There was the same idea a long time ago. It could improve the reliablity more 
or less, but it cannot make the device mapping perfect.

For example, you might have two disks which have completely identical data. 
This is possible when you plug in hard disks at the first time.

Another example is that some devices are not recognized by BIOS. Say, you have 
a USB disk and an IDE disk. If BIOS can recognize only the IDE one, Linux 
cannot determine which disk is recognized by BIOS after booted.

To make it more reliable, it would be necessary to gather different 
information, such as I/O ports. You can find my test code in the assembly 
code of GRUB which I gave up because it was extremely hard to make it very 
reliable due to interrupt handling and so on.

> Another, somewhat kinkier approach, would be to load a kernel module
> that took the Big-Kernel-Lock (tm), did a lot of INT 13h'ing to
> calculate unique md5 hashes, undid the kernel lock, and went back into
> Linux space and did the same through the standard interfaces.

You can try it, but INT 13 does not always work in vm86 mode in the same way 
as real mode.

> Also, whom should I ask if I wanted something to be committed to GRUB CVS?

Me.

I appreciate if you could improve it even a bit. The device mapping problem is 
the main source of headache for me. I am looking forward to your patch.

Okuji