grub guessed BIOS disk order incorrectly

Bug #30967 reported by Rick DeNatale on 2006-02-09
Affects Status Importance Assigned to Milestone
grub (Ubuntu)

Bug Description

Installed Ubuntu 5.10 on a system with both SCSI disks(2) and IDE disks(2).

Installation was to the first SCSI disk.

The file /boot/grub/menu.lst needed to be changed to allow successful booting.

I had to change several occurences of the line

root (hd2,0)
root (hd0,0)

I also changed

# groot=(hd2,0)
# groot=(hd0,0)

I had this same problem on this machine when I originally installed ubuntu 5.04, but didn't report it then. I just ran across it again when I needed to rebuild the machine after the boot drive failed.

Note: I'm not certain of the actual "package" name, this is the installer on the breezy install CD

Barry deFreese (bddebian) wrote :

This is likely a hardware issue. Most machines will always boot from IDE first and SCSI second. If grub did a default install to the MBR, it probably installed it on the IDE disk.

Changed in grub:
status: Unconfirmed → Needs Info
Rick DeNatale (rick-denatale) wrote :

No, the MBR was installed on the correct (SCSI) disk. It was /boot/grub/menu.lst which was generated incorrectly by the install.

I don't buy that most machines will always boot from IDE first and SCSI second. If that were true it would be impossible to boot from SCSI if an IDE drive was bootable.

On my machine setting the BIOS to boot from SCSI makes that SCSI drive the first drive in the boot list, and therefore hd0 in grub terminology.

As far as I can determine grub hdn is the nth drive in the BIOS boot list using zero origin indexing.

If the installer DID install an MBR on a drive which wasn't the target of the install, I think that it would be a serious error.

raboof (arnouten) wrote :

I saw something similar when installing Ubuntu on an external USB disk (which by the way works great). I followed the instructions on, which also mentions the problem.

Regularly, after an upgrade, it'd jump back to the wrong settings. I hadn't changed it back yet since last time this happened (hitting 'e' in grub is convenient ;)), but today I found the GRUB record was changed and it now works fine again.

I guess something was changed in the GRUB update scritps. Perhaps this change also fixed this bug for you?

Paul Dufresne (paulduf) wrote :

I did not read carefully, but bug title is the sams as bug #8497.
I'll add a note there to let them check this.

Launchpad Janitor (janitor) wrote :

[Expired for grub (Ubuntu) because there has been no activity for 60 days.]

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers