bugGNU GRUB - Bugs: bug #9486, stage1 boot_drive is set to 0xFF...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

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

Submitter:  Eric Mumpower <nocturne>
Submitted:  Mon 28 Jun 2004 09:56:07 PM UTC
   
 
Category:  Booting Severity:  Major
Priority:  5 - Normal Item Group:  Software Error
Status:  None Privacy:  Public
Assigned to:  None Originator Name:  Eric Mumpower
Open/Closed:  Closed Release:  None
Release:  0.95 Reproducibility:  Every Time
Planned Release:  None

Sat 15 Dec 2007 12:54:27 PM UTC, comment #2: 

We've moved to GRUB 2 as a development platform. Please can you check if this bug still applies there, and if it does, reopen it?

Thanks

Robert Millan <robertmh>
Group administrator
Fri 16 Jul 2004 11:42:07 AM UTC, comment #1: 

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.

Yoshinori K. Okuji <okuji>
Group administrator
Mon 28 Jun 2004 09:56:07 PM UTC, 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?

Eric Mumpower <nocturne>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by robertmh (Posted a comment)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2007-12-15 robertmh Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-4b48.
    Corresponding source code