Installer doesn't recognise SATA disks as primary.

Bug #32357 reported by IbeeX on 2006-02-21
This bug affects 2 people
Affects Status Importance Assigned to Milestone
grub-installer (Debian)
Fix Released
grub-installer (Ubuntu)
Nominated for Hardy by Herbert Thielen

Bug Description

The user has an nForce4 motherboard with both SATA and PATA drives attached. He set the SATA drive to be the first boot disk in the BIOS, but the installer installed GRUB to MBR on to the PATA drive instead.

Linux recognizes the PATA as /dev/sda and the SATA as /dev/sdb.

To work around the problem, he has set the first boot disk to the PATA drive.

Added by Duncan-Lithgow so it can be edited:
These bugs all have probelms installing GRUB on a SATA disc. Some with PATA present, some without. I do not have enough technical understanding to find exact duplicates.
Bug #8497 bug #75676 bug #32357 bug #110292

On Saturday 27 November 2004 20:26, Greg Orlowski wrote:

> It was late at night, and I was tired and bleary eyed, but when it
> asked "Install Grub to MBR" I said yes. Unfortunately, while I
> partitioned only the sata drive and installed the base system to only
> that drive, it automatically did a grub-install (hd0) on the ide
> drive. It would be cool if, when installing on a multiple-hard-drive
> system, you could ask the user WHICH hard drive's MBR to use for a
> grub install.

This would be useful when installing on a system with software raid, I usually
like to install grub to the MBR of both disks a raid1 set.

Fraser Campbell <email address hidden>
Georgetown, Ontario, Canada Debian GNU/Linux

This is quite annoying if you have hda1 to boot before hda0 in the bios.

We installed sarge on 15 computers, on removable hd. On 3 of them grub was
installed on the internal disk and this keep the system from booting.

Boot order:

- cd-rom
- hda1 (removable)
- hda0 (internal)

When the removable hd is connected, the computer hangs because it tries to
read the removable hd MBR.

When the removable hd is not connected, the computer hangs because GRUB can't
access menu.lst, which is in hda1.

The installer should ask in which MBR is GRUB to be installed, or at least it
should install it on the same disk than Debian, or on the hd which boots

Otherwise, I agree with Greg: thank you for such a good job with the

reassign 283312 grub-installer
severity 283312 wishlist

On Wednesday 08 December 2004 01:06, Joan Queralt wrote:
> This is quite annoying if you have hda1 to boot before hda0 in the
> bios.
> We installed sarge on 15 computers, on removable hd. On 3 of them grub
> was installed on the internal disk and this keep the system from
> booting.
> Boot order:
> - cd-rom
> - hda1 (removable)
> - hda0 (internal)
> When the removable hd is connected, the computer hangs because it tries
> to read the removable hd MBR.

Well, I disagree with you here. The installer _does ask_ you if you want
to install grub in the MBR; that it will be the MBR of hda0 is implicit.

If you have a special configuration like you list here, you are supposed
to know about it and you are supposed to be smart enough to answer 'no'
to that question and enter (hd1,0) in the next screen where you can
manually enter the partition where grub is to be installed.

AFAIK it is very hard, if not impossible, to ask the BIOS what the
bootorder is set to, so we can not automate selection in cases like this.

So, the only improvement I can think of is that we could make explicit
that we mean the MBR of hda0, or list the name of the device that was
For entering alternative partitions, I think there are already other bug
reports asking to show a list of possible partitions instead of having to
enter the grub code manually. (Which I would like to see as well.


Frans Pop wrote:
> Well, I disagree with you here. The installer _does ask_ you if you want
> to install grub in the MBR; that it will be the MBR of hda0 is implicit.

It's even explcit: "master boot record of your first hard drive"

see shy jo

A Dimecres 08 Desembre 2004 14:59, Frans Pop va escriure:

> Well, I disagree with you here. The installer _does ask_ you if you want
> to install grub in the MBR; that it will be the MBR of hda0 is implicit.
Sorry, because I wrote hda0 and hda1 where I wanted to write hda (or IDE0) and
hdb (or IDE1).

> If you have a special configuration like you list here, you are supposed
> to know about it and you are supposed to be smart enough to answer 'no'
> to that question and enter (hd1,0) in the next screen where you can
> manually enter the partition where grub is to be installed.
Yes, you are right here. It was a bit confusing to have 3 of 15 computers with
different hd configuration... I didn't know about it until they failed to
boot. In fact, I haven't realized that I should had answered 'no' to this
question until I've read your explanation (and these wasn't my first Debian
installations :( ).

I don't know if it can help, or if the result may be uncomfortable for some
users, but a possibility is:

Install the GRUB boot loader to the master boot record? (Yes/No) Yes
You have many hd. Which MBR do you want GRUB to be installed? (hda/hdb) hdb

Thank you for your attention,


I saw a similar problem. I had vmware configured with one scsi drive, one
ide cdrom (hda) and one ide disk (hdb). Vmware seemed to default to
booting from the scsi drive of the two disks (can't see a way to change
it in the bios actually), and I made that my root filesystem and took
the default at grub-installer, and it didn't boot since it turns out to
have installed grub to the ide drive.

To deal with this we could check to see if the system has two or more
drives with different interfaces and if so skip the thing about
installing to the mbr of the "first" drive, since it's not clear which
the "first" one is. Listing the name of the device is also a good idea,
it should be there in

Another possibility might be to check to see if the system seems to have
more than 1 hard drive of any sort; if so don't display the default
question, assume the user knows what they're doing and explicitly prompt
for which drive to use.

see shy jo

I have nforce4 motherboard, sata and pata HD primary HD is sata and it is configured via bios as boot disk, but installer writed GRUB to MBR off PATA disk so I needed to change in bios primary disk in order to boot ubuntu.

IbeeX (ibrkanac) wrote :

Installer wasfor ubuntu 64 latest flight 4

Simon Law (sfllaw) wrote :
description: updated
Simon Law (sfllaw) wrote :

I don't think this is a bug, but rather a consequence of hardware detection
order in Linux.

description: updated
Changed in grub-installer:
status: Unconfirmed → Confirmed
IbeeX (ibrkanac) wrote :

I am not shure what you think installer should finish installation and then you should be ablee to boot your machine, and if this is not case I guess that it is a bug.

sECuRE (michael-stapelberg) wrote :

This *definitely* is a bug and a quite serious! I had attached a PATA-drive encrypted with TrueCrypt which stores its required information to mount the drive in the first 512 bytes. You can already guess what happened? GRUB was written there and all my data are gone!

dexus (udo-schmiedeskamp) wrote :

I think it is not special to nforce4.
I had the same bug on an Intel P4 board.
For me the bug should be promoted to SEVERE because
additional SATA drives are getting more common.

Using the SATA drive for linux and leaving windows alone on the PATA drive has alot of charme for "non-experts"
If anything happens with my linux i change the bios boot order and boot windows again,
sounds too me as a good strategy for beginners.

They will be delighted having a non boot situation on the sata drive and a sort of messed up windows pata-drive.


the reported problem can leave your system in an unbootable state or even lead to dataloss. I think, correcting this bug is of high importance.

Thus please promote the bug's importance.

Marking this bug only as a "wish" is an act of negligence.

description: updated
Matthew East (mdke) wrote :

You are correct that bugs involving dataloss should be of high importance. I'm adjusting the importance accordingly.

Changed in grub-installer:
importance: Wishlist → High
Paolo Benvenuto (donpaolo) wrote :

I have a SATA disk and a ATA one.

I installed dapper to the SATA disk, but grub-install set linux to boot from the ATA disk.

I noted also that every time a grub security upgrade is performed in edgy, update-grub again invert the disks.

I'm gonna bump this bug with pretty much the same problem.

I have a SATA and IDE drive. And although the SATA is defined as hd0 grub keeps reverting it back to hd1... I installed to hd0 though so it should have recognized that.

I have a feeling this issue has to deal with converting the hda -> hd0 in the installer, rather than recognizing what the BIOS has labeled each drive.

Jojo (kuzniarpawel) wrote :

I've just been hit by the same bug. In my desktop comuter with nForce2 I've got two drives. One SATA and one PATA. During Ubuntu install (Edgy) I choose to install system and all stuff on sda and use hda only as media storage (music, movies, etc.). Yesterday to my PATA drive failed and to my astonishment I now cannot boot because there is no grub on SATA. My system is now 704 distr upgraded from 610.

severity 283312 normal
severity 317606 normal
merge 283312 226758 418535 306977 275262 249049 317606

I have just merged 7 bugs (#283312 #226758 #418535 #306977 #275262 #249049
#317606) that all have to do with grub-installer installing to the disk it
determines is (hd0) even though that might not be the disk the user
installed Debian on, or they wanted to install it to some other location.

Of these bugs #283312 appears to have to most useful info, that's probably
the best place to send future info.

There was one bug that was related, but different enough that I decided not
to merge it. Anyone looking at implementing a fix for this bug should also
check out,

#292513 - install to multiple disks in raid installs

maybe that could be fixed at the same time.

Matt Taggart
<email address hidden>

Similar to this bug and the 6 others merged with it, I also have a
situation where grub-installer picking (hd0) is not what I want. Here are
some details:

I am using d-i preseeding on a system that has both a cciss raid controller
and a fiber channel controller (appears as scsi). I specify which disk I
want to be partitioned/installed using something like:

d-i partman-auto/disk string /dev/cciss/c0d0

But when grub enumerate the disks (hd0) ends up being one of the scsi disks
and grub tries to install there (and fails in my case since the disk isn't
setup). I would like a way to tell grub "please install to the same disk as
was partitioned and used for the install". Now of course you might be
partitioning and installing to multiple disks, so I guess maybe you want to
be able to say "install on whatever disk /boot is on" or something like

For now the work around for this problem (at least using preseeding) is to
hardcode the device grub installs to with something like:

d-i grub-installer/bootdev string (hd4)
d-i grub-installer/bootdev string /dev/cciss/c0d0

but that is problematic since if you are trying to use the same preseed on
machines of differing hardware, differing amounts of controllers/disks will
cause those names to change. Better for d-i to record what did it used and
then use that.

I don't know what the patch to do this would look like but I expect that
the interface to use it would look something like:

d-i grub-installer/bootdev string bootdisk
d-i grub-installer/bootdev string rootdisk

or if you didn't want to overload that existing variable, invent a new one.


Matt Taggart
<email address hidden>

description: updated
description: updated
Michel DENIS (michel-denis) wrote :

Reporting same bug:
No problem to install kubuntu 7.04 on ATAPI disk
but got an error at grub installation on SATA2 disk on the same PC.
I tried to change BIOS settings on SATA2 from IDE to AHCI => same result.
Now i 'm trying to install grub on SATA2 disk at console command from Live CD...

Will Daniels (wdaniels) wrote :

I just encountered this same bug (I think) installing the Gutsy Beta. I have a SATA drive which I use for my main linux system and an old PATA drive for backups. My motherboard is an MSI K9N (nForce 570) which by default orders the PATA drive first, but I change the order in the BIOS to boot from the SATA disk. However, installing grub wrongly determined the drive number to be HD1 which resulted in grub "Error 15" on boot. I'm not sure whether grub was erroneously written to the MBR on the PATA drive since it was already installed on there anyway, but certainly it was necessary to edit the menu.lst file manually from the live CD in order to change HD1 to HD0, at which point everything worked fine.

Ivan Savcic (isavcic) wrote :

I have a mixed SATA / ATA system and same thing happens.

During the installation, it seems that the ATA drive was detected as hd0 and grub installed itself there. SATA were hd1, hd2.

During the boot, grub detects SATA discs as hd0 and hd1, while ATA is hd2.

I fixed it by re-doing the grub-install from the rescue console and editing /boot/grub/menu.lst to change every occurence of hd1 with hd0.

Happened to me before, on Ubuntu 7.04. I'm really amazed it didn't get acknowledged/fixed so far.

@ Simon Law:
The problem is different detection of drives during the installation and after, ie. during the boot of the installed system. It has nothing to do with the hardware itself, rather than with (wild guessing) different kernel, different module loading/order and such from the installation disc compared to installed system.

Mark (mmccaghrey) wrote :

I have had the same problem trying to install Ubuntu Fiesty Fawn onto a mixed SATA/IDE system. The SATA is my new drive - the IDE is my old XP one, which I am keeping just in case I need any of the old data on it.

I am very dissapointed that Ubuntu is not able to do what it says - which is perform a clean install onto a quite simple system to allow dual boot. I am someone who is quite computer literate and wishing to move away from XP, but has neither the time nor the inclination to go faffing around with manual editing of Linux configuration files.

It is this kind of problem which keeps people away from Linux.

As dexus wrote, SATA drives are now more common (I would say they are now the norm) and there are many users who will have mixed systems.

Somone, somewhere needs to sort this out so that on installation a non-literate person gets what they want - Ubuntu installed on the right drive - without any editing of configuration files or the MBR being written to the wrong drive (as in my case). I don't care why it is happening. It just needs to be sorted.

James Coleman (jamesc-dspsrv) wrote :

Same problem for me feisty 7.04. Two SATA drives sda and sdb. Dell optiplex desktop.
There seem to be a few problems for users coming up related to grub + sata difficulties
and the issue seems to be ongoing so I'll just add my piece.

bios before was booting from hd0 (suse + grub)
kubuntu new installed on sdb, wrote grub mbr to hd0, sdb was unformatted before install
After kubuntu install sdb bios was looking for hd1 mbr only? Boot hung.

After woe and wailing and gnashing of teeth wrote kubuntu sdb grub mbr to hd1
(in grub root(hd1,1) setup(hd1)) and got a grub menu YAY. But nothing worked.
Weirdly could see sdb was now hd0 and sda was hd1.
So if boot kubuntu live cd grub hd0 = sda, hd1 = sdb.
But in grub from bios boot hd0 = sdb (disk booting from) and hd1 = sda.
Swap hd0<->hd1 in menu.lst

Also the os scan could see suse and windows on sda but entry for suse was not added in kubuntu's menu.lst.

So ... hurmmm. What should the grub install do?
The grub setup(hd0) write by kubuntu gui install flashed up very fast and I didn't see it.
Write to hd0 or hd1 ? If I think you can't trust bios
I think it could have some helpful things added:
 1. make a backup of any mbr it is writing over, put it in /boot/grub/backup_mbr_xxxx (and rotate)
     (consider also backup of all partition mbr areas - user would appreciate that if they have to start
      running grub install themselves)
 2. if kubuntu successfully boots from install mark grub as having a successful boot
 3. If user has come back in on live CD and there is an mbr backup then options to
     restore these would be nice (display options if advanced user OR if user has come back and
     a successful boot has not happened).
 4. If user has come back in on live CD and there is no grub successful boot mark then ... ... ?
     offer option to audit hardware/software and send report somethere?
 5. If there is another grub ... play nice, warn user. Can't cover all options but it would be nice.

bloat bloat bloat :) but in the name of user-friendliness and that's what the grub install intends?

I think the bios behaviour is odd.

To handle bios weirdness I'd guess after any partition editing a reboot would have to be done (YEUCH!) and then the assigned handles would probably be correct so that grub install could run and be reasonably sure the handles have not changed.

Otherwise write grub mbr to all disks seen? Especially if have just formatted a disk ...
In my case the sdb mbr was left uninitialised so when it was attempted to boot from by bios it hung.
If a grub mbr was sneakily written to new disks it could save hassle for a few people.

But grub is clever and ?should?/could be made to be a bit more flexible?
i.e. if (hd0,x)/boot/grub/menu.lst not found then look for it on (hd1.x) (hd2.x) ... ?
Maybe that is hard to do.


I've seen a similar problem as reported earlier. My system has 4 IDE PATA ports:
- two internal PATA ports on an nVidia nForce2, used by a hard disk (hda) and a DVD drive
- two PATA ports on a Promise Technology PCI card, used by two additionla hard disks (sda, sdb)

During installation with Hardy Alpha 3 Kubuntu Alternate, the disks were named:
- sda, sdb for the two disks connected to the PCI card
- sdc for the disk connected to the chipset IDE port

Grub installed the boot record to sda, but the BIOS chose to start the (old) boot loader from hda (chipset PATA port, was called 'sdc' during installation).

I had to manually install Grub on the right disk again to be able to boot Hardy.

Additional informations can be provided on request.

Best regards,

James Coleman (jamesc-dspsrv) wrote :

After kernel upgrade grub again rewrote grub menus with hd0 and hd1 wrong way round.
Thanks be to goodness :) it left a /boot/grub/menu.lst~ (backup of old menu.lst) so quick edit to
that and everything is happy again.

Herbert Thielen (thielen) wrote :

Maybe your /boot/grub/ is wrong? Perhaps try --recheck option of grub-install?

larr2205 (larr2205) wrote :

Yesterday I tried to install KUBUNTU 7.10 RC to an Intel 945G series M/B with a SATA Seagate HDD (80 GB).
   The installation crashed every time at the 15% "Detecting file systems....." and after that I found it had write 530 MB to the root partition ( 3 partitions, Windows, Linux Swap and root for Linux).
   I think it is a problem with the SATA HDD because I used the same Install CD in a PC with PATA HDD and it installed all rigth.

   SATA is not new in the market, why does Ubuntu fail installing to it?

I actually do find this as a bug.
I have a 20G ATA drive in my system for backup purposes (I haven't spent the money, and don't really find it necessary to, on an external backup drive)... My primary drive is an 80G SATA.
Anyhow, when installing the system the installer finds the 80G as the primary drive and does assume the operating system to go on this drive; however, when GRUB is installed it installs to the ATA drive... then when I reboot the system for first boot to Kubuntu it gave me "Error Loading Operating System" so I was like "oh hell..."

However, I found that switching my drives in BIOS so the ATA drive was primary gave me access to GRUB... why wasn't GRUB installed onto my SATA drive? I don't think it's an error in the detection of the drives, because the SATA drive was listed as the first drive within the installer, but rather within the routine which installs GRUB on the system.

sorry, installation was on a P4, intel D865PERL motherboard, 32 bit processor, i686 install, Kubuntu 7.10...
I think this is a serious bug within the install routine for the GRUB bootloader and should be taken QUITE SERIOUS... if I had an operating system that required certain boot routines set up on my PATA Master Boot Record, that information would have been lost and that would have been a big downer.

I'm not sure is just for primary SATA since my SATA drive is the secondary, the PATA drive is my primary. In fact I couldn't boot Hardy AMD64 live CD 'till I used as boot option "all_generic_ide". I've got the same problem with Gutsy AMD64. Installers for 32 bit versions have no problems with my drives setup.

My system is:
Micro -> AMD BE-2300
Placa -> ASUS M2N-E SLI
HD1 -> IDE PATA Samsung 200 GB
HD2 -> IDE SATA Western Digital 250 GB

iain (igladwin) wrote :

I have the same problem on AMD64 box with a single IDE drive where the installation completes and then won't boot, hanging at "waiting for root fllesystem".
The installer sees my IDE drive as a SCSI but i suspect the boot process fails to see a non existant SCSI drive and then hangs.
If I add a SATA drive and install there it will boot OK but will not report the presence of the IDE drive.

Will Nowak (compbrain) wrote :

Added a link to the Debian bug report #283312. It and it's relatives have been open for ~4 years now.

Changed in grub-installer:
status: Unknown → Incomplete
X3 (x3lectric) wrote :

Right after I downloaded and started installing the Ubuntu 8.04.1 LTS on a mixed sata/ide drive environment I experienced similar issues when placing the MBR onto the IDE drive that I had partinoned and hadson partition 1 XP Pro and on Partions 2 Ubuntu and on partition 3 linux swap.... the other sata drives just contain data and I thought not much of this untiol I repeatedly experienced error 21 no matter where I placed the ubuntu mbr...

Work around is to unplug the sata drives do the install and then when all is fine plug them back up and all is well....

Solution? well just do what I said...

Dimitrios Symeonidis (azimout) wrote :

yes, the problem seems to come from the order of the hard disks, something that is decided by the bios.
unplugging disks, like X3 suggested, is a workaround, but it obviously cannot be the solution. we need to find a better way to do this...

Dimitrios Symeonidis (azimout) wrote :

this bug will soon celebrate it's 3rd birthday. it's marked as confirmed, high importance, and reported upstream (debian). are we going to do something about it, or are we just waiting for debian to resolve this?

kbunty (kbunty) wrote :

much of this silliness could probably be avoided by not pretending IDE drives are SCSI drives.

This mess seems to affect most distros now.

The kernel PATA driver still exists and is maintained. The kernel team's stated policy is that it will remain in existence and be fully supported. It is not "deprecated".

What could be simpler than treating an IDE drive as an ide drive?

As for the "data loss" claim in #5 , if you are going to plug in specially formatted encrypted disks and start installing OSes , you had better look where you are stuffing the boot loader.

Anyone using that sort of device is not a novice and should at least look what they are doing.

That would seem to be the only data loss scenario. However the mess that results during updates is unforgivable. If no solution has been found is 4 yrs, I strongly suggest using ide driver forth width.

That driver will probably be around as long as there are ide drives.

Please use it.

Phillip Susi (psusi) wrote :

I'm going to go ahead and close this old bug out. The reason it is now 4 years old and has not been fixed is because this report does not adequately describe an actual bug. There is simply no way for the system to know which drive your bios is configured to boot from, so it is up to you to install grub to the correct disk. The Ubiquity installer on the live desktop install cd prompts you to choose the disk. The grub-installer package this bug is filed against is only used by the alternate/server installer, and should have a similar means to select the device. If it does not, then please adjust the subject and description of this bug to indicate that before reopening.

Changed in grub-installer (Ubuntu):
status: Confirmed → Invalid
dexus (udo-schmiedeskamp) wrote :

@Phillip Susi

I just swallow what i wanted to write and just quote you:

"I'd like to continue working to improve Ubuntu, so it can be the best OS it can be, and encourage people to use it. "

X3 (x3lectric) wrote :

@ Dexus


Changed in grub-installer (Debian):
status: Incomplete → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.