Re: Should setup be reverted always to pass 'd' to install?

[Colin Watson]

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                                    address@hidden