[bugs #9486] stage1 boot_drive is set to 0xFF at GRUB setup-time, preventing stage2 from loading

[Yoshinori K. Okuji]

This mail is an automated notification from the bugs tracker
 of the project: GNU GRUB.

/**************************************************************************/
[bugs #9486] Latest Modifications:

Changes by: 
                Yoshinori K. Okuji <address@hidden>
'Date: 
                Fri 07/16/2004 at 11:42 (GMT)

------------------ Additional Follow-up Comments ----------------------------
0xFF is normal. It just means that the boot drive is determined  by your BIOS. 
It is passed from your BIOS via the register DL.







/**************************************************************************/
[bugs #9486] Full Item Snapshot:

URL: <http://savannah.gnu.org/bugs/?func=detailitem&item_id=9486>
Project: GNU GRUB
Submitted by: Eric Mumpower
On: Mon 06/28/2004 at 21:56

Category:  Booting
Severity:  Major
Priority:  5 - Normal
Item Group:  Software Error
Resolution:  None
Assigned to:  None
Originator Name:  Eric Mumpower
Originator Email:  address@hidden
Status:  Open
Release:  0.95
Reproducibility:  Every Time
Planned Release:  


Summary:  stage1 boot_drive is set to 0xFF at GRUB setup-time, preventing 
stage2 from loading

Original Submission:  Hello. I'm having a problem with version 0.95 of 
grub-install not reliably
creating a functional stage1 sector. In particular, I believe the problem is
that GRUB (both natively and as the grub shell) is not correctly
substituting the boot_drive byte into the boot sector it creates.

I'm using the standard version of GRUB 0.95 (as downloaded from the GNU ftp
site), on a Debian 'stable' x86 system, configured with "./configure
--disable-auto-linux-mem-opt", and built with gcc 2.95.4 and binutils
2.13.90.0.18. (In case it's relevant, I also see this problem when using the
Debian "unstable" version of GRUB, which is version "0.94+cvs20040511".)

The computer in question has four IDE disks; this is the contents of my
device.map:

> (hd0)   /dev/hda
> (hd1)   /dev/hdc
> (hd2)   /dev/hde
> (hd3)   /dev/hdg

If I install the Debian package of GRUB 0.91 on this system and run
"grub-install /dev/hda", it results in a functional boot loader. If I then
install GRUB 0.95 and run "grub-install /dev/hda", the boot loader no longer
works: the system only prints "GRUB Hard Disk Error".

Inspection of the resulting boot sectors in both cases suggests that the
problem is that the correct value for boot_drive is not being spliced into
the boot sector:

When using GRUB 0.91, the boot sector (which itself is based on stage1
version 0.91) has the byte 0x80 at offset STAGE1_BOOT_DRIVE (0x40), and has
no problem finding its stage2 data.

When using GRUB 0.95, the boot sector (based on stage1 version 0.95) has the
byte 0xFF in the stage2_sector byte, and fails with the above error.

If I boot from a GRUB 0.95 floppy, run "root (hd0,0)" and "setup (hd0)", and
reboot, the problem remains.

However, regardless of whether I used the shell or the native mode to
install the boot sector, if I dd off the broken 0.95 boot sector, change the
byte at offset STAGE1_BOOT_DRIVE from 0xFF to 0x80, and write it back to
disk, the system once again boots from stage1 to stage2 without difficulty.

I have attempted to look at the stage2 internals to understand what has
changed since GRUB 0.91, but without great success.

Can you tell me how the boot_drive_mask: address is used in version 0.95 of
stage1/stage1.S?


Follow-up Comments
------------------


-------------------------------------------------------
Date: Fri 07/16/2004 at 11:42       By: okuji
0xFF is normal. It just means that the boot drive is determined  by your BIOS. 
It is passed from your BIOS via the register DL.













For detailed info, follow this link:
<http://savannah.gnu.org/bugs/?func=detailitem&item_id=9486>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/