Installation to second disk confuses drive numbering

[Sam Brightman]

Performing a Dapper Flight 7 install to a secondary hard disc seems to confuse the installer. I already had a Dapper install on my computer's original 6.4GB hard disc (primary master). Bought a new 160GB hard disc, secondary master. BIOS detects this disc in the right place (note: has trouble with drive parameters - could be relevant?).

Running the Flight 7 install CD on this disc seems to work (partitioned into ReiserFS
and swap) until grub-install - it detects my install on the first disc and talks about installing to the first disc's MBR. This could be right still, provided the entry is added correctly to boot to the second disk without altering options for the first. However, on reboot grub stage 1.5 gets an error code 17 and halts.

I ran the CD in rescue mode, which seems to get the drives the wrong way round (new, big, secondary master as 0; old, small primary master as 1). Re-installing to MBR of old disc allows booting of old dapper install, so something clearly was mucked up when doing this. But cannot boot to second disk as far as I can tell. Removing drives and making just the new disk the primary master doesn't work. Attempting to re-write the MBR under this configuration leads to an error code 20 from the grub-install part of the rescue section of the CD.

Re-installing to a second disk seems like a reasonable upgrade path either OS-wise or hardware-wise (like me). And at the moment this causes the machine to be unbootable.

[Sam Brightman (sambrightman)]

I should clarify that I think there are three bugs here:

1) Installation to a second hard disk shouldn't default to installing grub to the first without any alternatives.

2) If anything is written to the first hard disc's MBR (e.g. updating MBR to say boot from second disc so BIOS boot order doesn't need to be changed by user?), it shouldn't make it non-bootable.

3) Writing to a second hard disc's MBR should work if chosen/in rescue mode. Even playing with grub-installer manually I can't make the second disk boot.

Using --recheck lists the drives in the right order.

[Sam Brightman (sambrightman)]

I will soon have the opportunity to confirm this bug using 6.10 on a different machine.

If it is still an issue, I find it incredulous that such bugs are still being marked as only medium severity. This bugs leaves an unbootable machine - not just the new install but whatever was on the other disk as well. It may also, as described in bug 32357 (which even more bizarrely is marked as wishlist), cause dataloss. What is the rational for downplaying the severity here and in others such as bug 32357 and bug 46520?

[Matthew East (mdke)]

Hi Sam,

According to https://wiki.ubuntu.com/Bugs/Importance bugs which have a severe impact on a small proportion of users should be marked "High". I'm therefore doing so with this bug.

Where this hasn't been implemented, it's likely a result of an error in the bug triaging process.

[LoSko (lorenzo-marcon)]

I can confirm this bug on Kubuntu 6.10 Edgy Eft.
Before installing mine configuration was this:

hda: primary device. Windows is installed here, with Windows bootloader in the MBR
hdb: secondary device. Empty.

I wanted to install Kubuntu on hdb and grub in the MBR of hdb, maintaining Windows bootloader untouched in hda MBR. My choice will be to select hdb as first booting device in the bios settings.

So, I proceeded and installed Kubuntu on hdb. When I was asked about where installing grub I choose MBR of hd1 (the preselected choice was MBR of hd0). Installation was successful and done exactly as I asked, but after rebooting I had to change all the occurrences of hd0 to hd1 (and hd1 to hd0) in menu.lst

[Sam Brightman (sambrightman)]

Have since confirmed this bug on another machine. Unfortunately I am unable to remember the details and exact configuration but the installer required manual intervention to get grub installed properly, and then boot configuration editing to boot successfully. Windows partition doesn't boot at all. I guess this is minutely better than before (not having a choice), but not happy about lack of activity here as stated in bug 46520 (I know more info would help, but when there is so little response, what's the point?)

[tonyko (antoniorusu)]

I also encountered this bug, so maybe I can help. I was actually using Linux Mint 3.0, but since it's based on Ubuntu 7.04, I believe it's a Ubuntu bug.

Ok, here it is:
I have 2 IDE harddisks, a primary master (hda) with Windows XP and a primary slave (hdb) with PCLinuxOS 2007. On hda's MBR I had the XP boot loader, while on hdb's MBR I had PCLOS's grub.
Also, I had changed my BIOS to boot from hdb, so I would get the grub menu.

When I installed Mint, the boot configuration was messed up - the new grub from Mint wouldn't boot anything. When trying to boot, I got the following grub errors (I believe the grub stage is 1.5):
 * for Mint - grub error 17: Cannot mount selected partition
 * for WinXP - grub error 13: Invalid or unsupported executable format
 * for PCLOS - grub error 22: No such partition

 After some fiddling with grub, I decided to use PCLOS's grub => I simply copied the entries from Linux Mint's menu.lst to PCLOS's menu.lst and restored grub from PCLOS. Now PCLOS and WinXP worked, but Mint still gave error 17.
So I looked in the menu.lst and devices.map => I discovered something:
hd0 and hd1 wre swapped. In other words, hd0 was referruing to hdb, and hd1 to hda.
But the Mint entries were using hd1 => they were looking on the wrong disk.

I'm not sure, but I think that when my BIOS boots from hdb, it automatically swaps hda and hdb => hdb will be the first disk (hd0) and hda will be the second disk (hd1).
Apparently, the PCLOS installer correctly detected this and wrote the menu.lst accordingly.

I'm not sure if this helps, but I sure hope it does (this is one nasty bug IMHO).
If you need more details, please contact me.

[Nemes Ioan Sorin (nemes-sorin)]

Copy from a previous message () :

"... beginners (first time linux users) will choose default option (fd0) in 98% of cases without any understanding about hd0 / hd1. Something really useful can look like -> Install to Windows boot partition (with explanation : this will let you to chose preferred OS from the Windows Boot Manager, at the windows boot) // Install to Linux boot partition (targeting on the Linux boot partition, with explanation : this option will let you to choose preferred OS at Linux boot from the Linux boot manager, but be careful - on this case you may need to choose your linux Hard-disc from Bios when U need to boot on Ubuntu ).
Some derived cases regarding 1: different partitions on the same Hdd; 2: different partitions on 2 (or more) hd's, should be covered too.

This kind of adviser will have GOLD value for new linux users and for mid linux users too.
This must be the way, without exceptions (for entire Ubuntu concept not only for Grub Installer ) if we want to grow a friendly, global community on a 'non geek' world.

Else ..no problem Ubuntu community will be large and growing anyway ...but we can be sure we will miss something - even 0.1%, even a single person.
For me it's ok as is now.

Eventually, GRUB INSTALLATION STEP can present at start 2 main modes :
-Advanced Grub Installer (with grub extra options - if we admit that geeks don't like to read again what they already know)
-Default Installation (Guided, very clean and clear regarding all possible Grub installation locations).

Drawbacks - NO ONE - This can be a Win - Win situation. And a good example of how we (Ubuntu community) understand the way that world should be."

[Aether (raymond-dick)]

I have a similar problem and I think it is to do with assumptions that grub makes.

I have an IDE hard disk which should be hd(1,0)
I have a SATA hard disk which should be hd(0,0)
as the SATA disk has the MBR on it and the BIOS looks at this disk for an MBR first.

Every time there is an upgrade to grub or the kernel they get changed around and I have to manually edit the boot loader at boot else it cannot find the hard disk drive. Minor inconvenience for me.

Interestingly the IDE hard disk used to come up as /dev/hda but now it comes up as /dev/sda (Ubuntu 6.10 and before), the SATA disk coming up as /dev/sdb.

I don't know why this happens but I guess it has something to do with the way the kernel identifies drives. So basically, I'm thinking grub makes the choices it does because of underlying works in the kernel.

What I do to boot:
  - Selecting the option you want to boot
  - hit e to edit
  - change the hd(1,0)<>hd(0,0), hit b to boot.
This should work if its doing the same thing that happens to me.

If you need any more info feel free to contact me.

[Ralph Corderoy (ralph-inputplus)]

The BIOS and the Linux kernel have a different ordering of the drives and Linux can't tell what drive the BIOS actually booted from. That is until EDD came along. Could this bug be connected to bug #8497.

[Moritz Baumann (mo42)]

Similar problem here.

I had Windows installed on my first HDD (Master) and installed GRUB in the MBR of the second HDD (Slave) so that it wouldn't overwrite the Windows boot loader. After changing the boot device priority in the BIOS, nothing booted and I had to edit the menu.lst manually. (I tried it again and again, every time I installed Ubuntu on a friend's computer, and it never worked.)

As far as I understand the problem (and I'm pretty sure I don't fully understand it, so it's just a guess), in my case the fact that GRUB is installed in the slave's MBR (which the installer knows!) is simply ignored, therefore the device numbers in the automatically generated menu.lst are wrong. If it's just that, it shouldn't be too hard to fix.

[Charlotte Meyer (lottemeyer)]

I have a similar problem

I have installed ubuntu 8.04 from the live cd and it worked nicely for about a week, but now I get error 17, randomly it seems, when i reboot. After a few tries I can usually boot from harddisc with the help of the boot menu in the live cd.

I do not have a windows installation, but I do have an extra harddisc which still contains the file system from my old windows installation.

I am quite new to linux and not yet completely familiar with all the technical stuff. So I have no suggestions for what is wrong or how to fix it. I just wanted to let you know that the bug also seems to exist on ubuntu 8.04.

[Dup (ddup1)]

Hi,

I have similar behaviour on an IBM Netfinity server. We have 2 harddisk link on an Adaptec 2940 SCSI adapter and 1 IDE drive.
We choose to install Ubuntu on the IDE drive and Ubuntu report hard disk schema as this :

SCSI1 : /dev/sda
SCSI2 : /dev/sdb
IDE1 : /dev/sdc

Install works fine when choosing to install grub, no error message is displaying but after reboot, grub failed to launch.
Cause is that grub use device.map to know where to install grub and device.map look like this :

(hd0) (/dev/sdc)
(hd1) (/dev/sda)
(hd2) (/dev/sdb)

So Ubuntu say to grub to install itself on hd2 disk (as ubuntu know ide drive is on third disk) and fails. After booting in rescue mode i resolve because i know how grub works.

[Cameron W (cwill747)]

I have the same problem as some people above.

I confirm this while installing ubuntu 8.10. I have to manually change my menu.lst every time it is updated so my grub will successfully find the disks.

If I do not update my menu.lst or use manual boot options, i get error 17. It also seems as if i have the error described in bug 8497 .

[Chris Hird (chrish-shield)]

I have a similar problem, I have 2 drives installed and configured for Raid. The 2 drives appear in the partitioner as separate drives, but surely they should appear as a single drive? I installed Ubuntu 9.04 using the normal install which reported no errors at all.

After I rebooted the GRUB 2 error appeared stating that the file is missing. After some investigation I found that the Grub installer had actually installed on the second drive /dev/sdb not on /dev/sda. I found this out by checking the /boot directory only to see that the grub directory was missing. I then mounted the /dev/sdb drive and I can now see the grub directory!

The device.map file shows
(fd0) /dev/fd0
(hd0) /dev/sda
(hd1) /dev/sdb

This is exactly as I would expect, but why did grub install on the wrong device mbr?

[David Ayers (ayers)]

I can confirm that installing from CD to an external USB drive/stick still overwrites the MBR of the internal drive on Lucid Beta2.

Possibly related reports:
https://bugs.launchpad.net/ubuntu/+source/grub-installer/+bug/46520
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/414996

[Larry Tate (cathect)]

This just happened to me in an upgrade from 9.10 to 10.04. The installer confuses my two hard drives, switching the labels from dev/sda to dev/sdb and vice-versa. It had also installed / (root folder) folder on my backup drive (where I keep backup of my /home partition). This ultimately led to a loss of important data because I had become confused about what had occurred. It also installed the MBR on the wrong drive (my backup drive) which caused me to have to repair the MBR.

This was REALLY frustrating.

[Phillip Susi (psusi)]

This does not appear to be a bug in grub-installer. The disks changing identifiers is not a bug and is the reason for the use of UUIDs instead of device names. If grub legacy did not correctly add entries to boot the system found on the other disk, that would be a bug there, but grub legacy is no longer being developed. Using grub2, which has been the default for new installs since Karmic, should handle this fine.

[Sam Brightman (sambrightman)]

This bug was still a problem long after UUIDs started being used (before Karmic). For a serious bug to exist for 4.5 years and then be marked invalid based on an assumption doesn't indicate a very good respect for the average user's ability to have a bootable system. You can see from the comment above that there are problems in the 2009/10 releases as well. Additionally, one of the parts of this bug is that the second disk is chosen, and the MBR is written on the first disk. Unless the disk ID changes during the installer's progress, this would not be solved by UUIDs.

[Phillip Susi (psusi)]

The nature of the bug is unclear form the original report. This is because it describes disks changing identifiers, which is perfectly normal and not a bug. If you still have issues with 10.04 or 10.10, please try describing them again so we can get the description updated. Specifically, what the exact grub-install command you run is, and what the results are. Attaching the output of this script would be helpful as well:

http://sourceforge.net/projects/bootinfoscript/

[Launchpad Janitor (janitor)]

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