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

[Colin Watson]

Hi,

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.

I notice the following comment in stage2/builtins.c, before code that
would cause the setup command always to pass the 'd' option to the
install command:

  /* This code was used, because we belived some BIOSes had a problem
     that they didn't pass a booting drive correctly. It turned out,
     however, stage1 could trash a booting drive when checking LBA support,
     because some BIOSes modified the register %dx in INT 13H, AH=48H.
     So it becamed unclear whether GRUB should use a pre-defined booting
     drive or not. If the problem still exists, it would be necessary to
     switch back to this code.  */

(I suspect this should say "INT 13H, AH=41H", by the way.)

It seems clear from multiple reports and my personal experience
debugging GRUB on this loaner machine that the problem does still exist
despite the workaround that was applied for the BIOS modification of DX.
Would you therefore consider switching back to the currently disabled
code in setup_func, so that those of us maintaining distribution
installers that use grub-install can have grub work automatically on a
few more machines?

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.

Thanks,

-- 
Colin Watson                                    address@hidden