On Thu, Dec 02, 2004 at 02:10:20PM +0100, Yoshinori K. Okuji wrote: > 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?
I used the attached patch (or something very similar; I don't have the exact code any more, but I remember it quite well). I added the 0x40 to make sure that if DL was 0x00 the result would still be printable. I had to look up the IBM code page to figure out what the line-drawing character I got on the screen was, but I wasn't too bothered about cosmetic details by that point; DL + 0x40 displayed as 0xC1, and when I added 'decb %dl' just before "/* save drive reference first thing! */", GRUB found its Stage 1.5 perfectly. > BTW, I have a test program for this: > > http://enbug.org/boottest.tgz > > If you can still test the machine, please try it. I'm afraid that I can't reach enbug.org right now (I tried from a number of different network locations), and I have to give the machine back now, so no. :-( I may be able to get it back later for a while, but it will involve paperwork so I'd need to have a good reason. http://lists.gnu.org/archive/html/bug-grub/2002-12/msg00029.html suggests that this test program prints out similar information to what I got in a somewhat more readable form? > > 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. Ah, I see. Hmm. Is there any way that either (a) GRUB could detect the BIOS problem from userspace at grub-install time (I somehow doubt it) or (b) that grub-install could automatically regenerate device.map when the boot drive is changed to avoid the situation you describe above? > 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. Agreed. Sorry that I only had the machine available for such a short time. Thanks, -- Colin Watson [EMAIL PROTECTED] _______________________________________________ Bug-grub mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-grub
