On Tuesday 30 November 2004 21:54, Colin Watson wrote: > I work on the Ubuntu distribution of GNU/Linux. We have a bug report > (https://bugzilla.ubuntu.com/show_bug.cgi?id=3007) with two different > instances of BIOSes that pass the wrong boot drive in DL to GRUB's > Stage 1. Our package is based on GRUB CVS from 20040624, so we have > the fix to DX being clobbered by INT 13h function 41h; I can confirm, > from assembly-level debugging on a problematic system loaned to me > for the purpose of investigating this, that DL is indeed set to 0x81 > rather than 0x80 right from the start of Stage 1.
Could you elaborate on how to debug it? BTW, I have a test program for this: http://enbug.org/boottest.tgz If you can still test the machine, please try it. > It seems to me that the main detrimental effect of such a change > would be to make it a little bit more effort to swap disks around > (which doesn't seem like a huge problem; there are a number of other > things you have to do when making that kind of change). Are there any > other detrimental effects you know of? Otherwise, I'm considering > making this change in a patch to our grub package. Actually, the 'd' option is problematic for users who have multiple disks and try to use fancy BIOS features without knowing what they do. For example, people often tries to set a second disk as a boot disk. In reality, the BIOS assigns the second disk to 0x80. But they just believe that the second disk is always the second disk like under Linux. But, for BIOS and GRUB, the second disk is the first disk logically. So this is completely a mistake, but they usually do not attempt to fix a device map. After all, their systems become unbootable. When we used the 'd' option for all cases, I received many, many same questions about this. So I often had to explain what a device map is, what the relationship between Linux devices and BIOS drives, how impossible it is to fix this problem, etc. So I really hope that we can find a good workaround / fix for this problem. If this is caused by a stupid bug in GRUB, it is very nice. If this is avoided by a simple and generic workaround, it is also nice. Okuji _______________________________________________ Bug-grub mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-grub
