d-i does not provide a way to select which drive to install grub to

I wonder if this is a duplicate of bug 45989?

It's possible, but I'd rather they remained separate until they're both understood.

Have added a comment to bug 45989 to clarify. I think this bug is part of that one (independent of SATA). It looks like the installer chooses the first BIOS disc regardless of what kind of installation is being done.

I have had this same issue and it is discussed as a problem for many in the forum page: http://ubuntuforums.org/showthread.php?p=1096588 This problem still exists in the recent Dapper Drake release.
RedBoot

As per https://bugs.launchpad.net/distros/ubuntu/+source/grub-installer/+bug/45989/comments/3 bugs which result in an unbootable system should be of high importance. Adjusting accordingly.

Makes total sense. Thanks.
Scott

On 1/2/07, Matthew East <email address hidden> wrote:
>
> As per https://bugs.launchpad.net/distros/ubuntu/+source/grub-
> installer/+bug/45989/comments/3 bugs which result in an unbootable
> system should be of high importance. Adjusting accordingly.
>
> ** Changed in: grub-installer (Ubuntu)
> Importance: Medium => High
>
> --
> Grub installs to wrong drive's MBR in default install. No way to change in
> standard installer.
> https://launchpad.net/bugs/46520
>

I just had this happen with 7.04 alternate. One EIDE, one SATA drive, boot order is configurable in BIOS menu. Now both HDs have a grub :)
https://bugs.launchpad.net/ubuntu/+bug/112239 is at least related.

I don't often whine about bug status and progress, but I have to say that I find it unbelievable that this is still marked unconfirmed (albeit High) and does not seem to ever see any progress. I made a similar comment on bug 45989 several months ago, and it is still marked unconfirmed and lacking in developer communication. I currently have an unbootable Windows partition on one of my discs having once again confirmed this on a different machine.

Can confirm this (or something very similar) with a couple of other recent Debian distributions as well as Ubuntu 7.04 (64studio, musix).

In my case I have hda, hdb and sda. The bios is configured to boot from sda. Grub installs correctly, except that for some reason groot is set to (hd2,0) in menu.lst (and all images are pointed accordingly to (hd2)). The correct settings should be (hd0,0) since the SATA device is configured first in the bios. This leads to a "File not found - Error 15" when trying to boot, which can be resolved by editing the menu.lst entries.

Sam, "confirmed" is used to mean that all the necessary info is there, not just "someone else has it too."

Anyway, Feisty's installer lets you choose at the last page (the confirmation page) where GRUB should be installed (I think it's an "advanced" button).

Yes it's a 'geek button' - beginners (first time linux users) will choose default option 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 anyhow ...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, explain about all possible situations ).

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

That sounds JUST like my problem.

Started in Feisty, GRUB would want to install on the wrong drive, and when I tried to set it to the drive that was was the start drive in the GRUB Drive Map, I'd get an endless Looping of the word "GRUB" all over my screen when I boot up. Here's how GRUB maps my drive since Feisty.

hd0: hdg
hd1: sda
hd2: sdb

In other distros, and Edgy downward, it read like this:

hd0: hda
hd1: hdb
hd2: hdg

Whereas "hda" translates to "sda", "hdb" translates to "sdb" and "hdg" translates to "hdg". The drive I boot up with in Windows, and I had to use Grub4DOS to boot up Feisty, sda. The device that GRUB wanted to install in a Fresh Feisty+ install is, hdg.

I had this same problem on 7.10. AND I tried the advanced button... that didn't work either. I have a ASUS motherboard, a SATA, and an IDE.

I have had this problem since 6.06 my first install.

The only "solution" I have found is to unplug my IDE harddrive, do the install, then plug in my IDE and add it manually to the /etc/fstab.

I'd rather not be the one to test this to get you info since obviously fresh installs take up a lot of time and also take a while to recover from, but if that's the only way to get this issue resolved then let me know. (email me <email address hidden> because I don't check these posts very often)

I had the same problem with the Gutsy install and it caught me again on the Hardy install. I marked it as a buG previously. Honestly... this is enough to make me quit using ubuntu.
 I installed ubuntu to an external USB drive but grub was also installed into the master boot record of an encrypted internal drive. Why would this be set as the default?. Why wouldn't grub only be installed on the targeted install drive? From what I understand the only way to remove grub from the mbr is to reformat the mbr. In this case my internal HDD with windows 2000 is now rendered useless as the encryption software resided in the mbr.

THIS IS A MAJOR FLAW THAT SHOULD HAVE ALREADY BEEN FIXED!!!!

marked as new, assigned to nobody. same old story. i hate writing on bugs just to complain but this is scandalous and i hope comments will at least make someone listen/ask for more information. i am yet to experience the joy of this bug on hardy, as i tried to use the upgrader. my machine is now unbootable.

maybe it's not even worth trying the install from scratch if this problem still exists. :((((((((((((((((((((

Yep - too few developers for millions of users ...I hope I'll enjoy
soon the "helpers" brigade. I can't see a better situation nearby...

2008/5/2 Sam Brightman <email address hidden>:
> marked as new, assigned to nobody. same old story. i hate writing on
> bugs just to complain but this is scandalous and i hope comments will at
> least make someone listen/ask for more information. i am yet to
> experience the joy of this bug on hardy, as i tried to use the upgrader.
> my machine is now unbootable.
>
> maybe it's not even worth trying the install from scratch if this
> problem still exists. :((((((((((((((((((((
>
>
>
> --
> Grub installs to wrong drive's MBR in default install. No way to change in standard installer.
> https://bugs.launchpad.net/bugs/46520
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Nemes Ioan Sorin

Are you still experiencing this with Hardy? I had it on Dapper and Edgy, but not anymore.

nope
HARDY is OK - For me - but this is not a general rule - I'm not the
comparison element, so the this bug should be investigated because seem to
be critical

Morgan - the point is that an kernel upgrade ( so an Ubuntu upgrade ) will
rewrite your boot menu, even is customized - your problem can be from
menu.lst too ( but sure ..can be from the wrong MBR location as you suggest
here )

My menu.lst was customized but an recent upgrade rewrite my menu.lst so for
next boot I can't see my XP installation on grub list so I need to repair my
menu.lst by hand. This is a potential bug too - because on the upgrade
proces not tell me in clear terms about "what" configuration will change ( I
was asked to choose between the producer config file or to keep actual file
[but no reference about what file] )

2008/9/13 Mackenzie Morgan <email address hidden>

> Are you still experiencing this with Hardy? I had it on Dapper and
> Edgy, but not anymore.
>
> ** Changed in: grub-installer (Ubuntu)
> Status: New => Incomplete
>
> --
> Grub installs to wrong drive's MBR in default install. No way to change in
> standard installer.
> https://bugs.launchpad.net/bugs/46520
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Nemes Ioan Sorin

> the point is that an kernel upgrade ( so an Ubuntu upgrade ) will
> rewrite your boot menu, even is customized - your problem can be from
> menu.lst too ( but sure ..can be from the wrong MBR location as you suggest
> here )

It rewrites *only* the Debian Automatic Kernel section, based on
whatever rules you specify above. Make your changes only in the one
location up top where the settings go.

> My menu.lst was customized but an recent upgrade rewrite my menu.lst so for
> next boot I can't see my XP installation on grub list so I need to repair my
> menu.lst by hand. This is a potential bug too

No it's not. It explicitly says not to edit between the Debian
Automagic Kernel lines. The Windows info should be outside of that
area--either before it begins or after it ends. Only that area is
rewritten.

OK - tanks - than take it as a proposal -> Why - Ubuntu must adapt dinamic
to changes - then - a lot of let say advanced Linux users on other areas -
wil to the same mistake like me - writing menu.lst by hand ..so the proposal
is for a script -> to check other valid lines that are not generated by
Debian Automatic Kernel script -> then move to outside with the mension "
Those valid ( valuable lines ) were moved outside of automatic generated
zone - to prezerve your customisation against future kernel upgrades. Your
customisation was not afected."

This way a potential enemy can be killed from start - even a people like me
wrote lines on the "hot" area. Mo more complaints for "nothing", low trafic
on mailing lists ;) ...etc - so please consider my proposal.

Anyway please read again the first message from this list - I dont know why
but I feel it is unsolved by now...

2008/9/13 Mackenzie Morgan <email address hidden>

> > the point is that an kernel upgrade ( so an Ubuntu upgrade ) will
> > rewrite your boot menu, even is customized - your problem can be from
> > menu.lst too ( but sure ..can be from the wrong MBR location as you
> suggest
> > here )
>
> It rewrites *only* the Debian Automatic Kernel section, based on
> whatever rules you specify above. Make your changes only in the one
> location up top where the settings go.
>
> > My menu.lst was customized but an recent upgrade rewrite my menu.lst so
> for
> > next boot I can't see my XP installation on grub list so I need to repair
> my
> > menu.lst by hand. This is a potential bug too
>
> No it's not. It explicitly says not to edit between the Debian
> Automagic Kernel lines. The Windows info should be outside of that
> area--either before it begins or after it ends. Only that area is
> rewritten.
>
> --
> Grub installs to wrong drive's MBR in default install. No way to change in
> standard installer.
> https://bugs.launchpad.net/bugs/46520
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Nemes Ioan Sorin

As I said above, upgrading from Gutsy to Hardy left me with a machine that would not boot.

Sam - to ensure - I will never get into this situation ( yep I was in your
situation too - my Ubuntu install wrote on MBR over XP loader - so I can't
boot any OS ).

If you have XP - U can recover XP boot with a bootable win98 floppy with :
fixmbr command afer the floppy boot is complete OR from your Windows CD (
details here :
http://amazingrando.wordpress.com/2007/04/05/fixmbr-is-your-friend/ )

........................................

on the linux side :
I'm afraid you have to reinstall Ubuntu from an Ubuntu Hardy CD

if you want to protect your data on linux partitions for further troubles -
do partitions as I do - a boot partition ( first ), a swap partition (
second ), a root partition ( third ), and finally a home partition.

so you need to mark them at the manual partitioning phase, like that:
    1 = /boot
    2 = /swap
    3 = /root
    4 = /home

my /boot has 500mb
my /swap has 2000mb
my /root has 65% from rest of space
my /home has 35% from rest of space

if you have doal boot - U have to put Grub over XP loader where XP is
installed ( on the partition where XP is located ). Grub will recognize XP
loader and will offer you as a boot option.

Also if you have a /home partition your data is safe ...even if your linux
is gone - you can install other linux and after boot your data will be there
...

2008/9/14 Sam Brightman <email address hidden>

> As I said above, upgrading from Gutsy to Hardy left me with a machine
> that would not boot.
>
> --
> Grub installs to wrong drive's MBR in default install. No way to change in
> standard installer.
> https://bugs.launchpad.net/bugs/46520
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Nemes Ioan Sorin

On Sun, 2008-09-14 at 12:09 +0000, Nemes Ioan Sorin wrote:
> on the linux side :
> I'm afraid you have to reinstall Ubuntu from an Ubuntu Hardy CD

You should be able to just reinstall GRUB from the live cd.

Thanks for the tips, but my computer is currently booting both Ubuntu and Windows successfully. My point was simply that this is still a critical problem in Hardy. We shouldn't have to waste our time fixing this, and new users shouldn't be put off or worse by this.

Failure to edit menu.lst correctly with your custom kernels is irrelevant here.

"
Failure to edit menu.lst correctly with your custom kernels is
irrelevant here.
"
thanks for the tip *

2008/9/15 Sam Brightman <email address hidden>

> Thanks for the tips, but my computer is currently booting both Ubuntu
> and Windows successfully. My point was simply that this is still a
> critical problem in Hardy. We shouldn't have to waste our time fixing
> this, and new users shouldn't be put off or worse by this.
>
> Failure to edit menu.lst correctly with your custom kernels is
> irrelevant here.
>
> --
> Grub installs to wrong drive's MBR in default install. No way to change in
> standard installer.
> https://bugs.launchpad.net/bugs/46520
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Nemes Ioan Sorin

OK, well I don't have anything other than laptops at my current place, so I can't test it on Intrepid. Besides the part where on my mom's computer the bug's gone.

Can someone test it on Intrepid?

right now I can't my testing machine is down, in pieces ..next week maybe -
my main machine is for my daily production ( Hardy ) and I can't afford any
risk.

2008/9/15 Mackenzie Morgan <email address hidden>

> OK, well I don't have anything other than laptops at my current place,
> so I can't test it on Intrepid. Besides the part where on my mom's
> computer the bug's gone.
>
> Can someone test it on Intrepid?
>
> --
> Grub installs to wrong drive's MBR in default install. No way to change in
> standard installer.
> https://bugs.launchpad.net/bugs/46520
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Nemes Ioan Sorin

I have confirmed that the same behaviour is seen in Intrepid (20081009 / AMD64 Server). My workstation has the following hardware -- which differs in chipset than the original with the disks listed in physical order:

MB: Abit KV8Pro

PATA1: 1x 80GB and 1x 120GB disks
PATA2: 1x DVD drive
SATA: 2x 120GB disks

I have attached the output of some commands (uname, lspci, dmesg, fdisk) from Intrepid, as well as from Gentoo and GParted Live for comparison. It seems that in Ubuntu, Grub is seeing the correct order for the disks, but the order the the kernel provides to it during the install is incorrect. This probably only affects systems that have integrated PATA and SATA controllers provided by a single chip with both types being used.

My guess is that Ubuntu is the only one (of theses three atleast) that is solely relying on the new 'libata' module. The others still have /proc/ide populated.

Let me know if there is any thing else I can provide for you.

well seems to be chronic ...

2008/10/9 Doug Wright <email address hidden>

> I have confirmed that the same behaviour is seen in Intrepid (20081009 /
> AMD64 Server). My workstation has the following hardware -- which
> differs in chipset than the original with the disks listed in physical
> order:
>
> MB: Abit KV8Pro
>
> PATA1: 1x 80GB and 1x 120GB disks
> PATA2: 1x DVD drive
> SATA: 2x 120GB disks
>
> I have attached the output of some commands (uname, lspci, dmesg, fdisk)
> from Intrepid, as well as from Gentoo and GParted Live for comparison.
> It seems that in Ubuntu, Grub is seeing the correct order for the disks,
> but the order the the kernel provides to it during the install is
> incorrect. This probably only affects systems that have integrated PATA
> and SATA controllers provided by a single chip with both types being
> used.
>
> My guess is that Ubuntu is the only one (of theses three atleast) that
> is solely relying on the new 'libata' module. The others still have
> /proc/ide populated.
>
> Let me know if there is any thing else I can provide for you.
>
> ** Attachment added: "Not fixed in Intrepid (20081009)"
> http://launchpadlibrarian.net/18376640/output.zip
>
> --
> Grub installs to wrong drive's MBR in default install. No way to change in
> standard installer.
> https://bugs.launchpad.net/bugs/46520
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Nemes Ioan Sorin

I woul like to be more precise. In fact the problem is that the standard install does not ask where to install the Grub and goes directly to the first hard disk. It is sort of downgrading from 8.04.1 which installs on a secondary disk properly. I installed the 8.04.1 on USB disk, was prompted during the installation to decide where to put the grub, and was able to boot from both the internal drive and USB. The 8.10 installer went through the installation without prompting and left me with shaky boot (I need the USB disk plugged to boot from the internal disk). I do not see any technical problem for 8.10 guys. Could take the relevant part from 8.04.1 install, it's merely the question of decision.

I'm pretty sure my system has PATA and SATA controllers integrated on same chip but I don't use the SATA at all and still get this problem.

it's merely a problem regarding -> next upgrade always do some regressions
where is supposed to be plain ground and clean states - I mean is so hard to
quantify every good step forward ( then the next step to be a real progress
) - instead of reinventing the wheel each time ? following development of
Ubuntu for few years I have the bad impression that every step is reinvented
( ? MS money here ?? ).

So we have now better kernels ( better drivers ), tabs on Nautilus but I
can't set my video card to put 75 / 85 Mhz on my screen not 60Mhz - amximum
for now ( I can do that in 7.10 ), and STILL I can't clearly know where the
Grub will stay.

Also we see no measure is taken agains Grub default instalation AND Grub
User Experience ( is so hard to detect hard drives and to make a noob
friendly - step by step ( explanations... ) guide ???? ), no problem I'll
do a Blueprint for that. I'll make this problem public on forums and blogs.
Maybe someone will see that and help us to help Ubuntu to become human
friendly.

Sorry devs.( if some dev. read this ) but as a friend of Ubuntu I think that
something serious is to be done - to broke a glass on this case. Like your
dutty - but not for money, I work for Ubuntu too. I install desktops for my
friends and their friends all for free ( ...time here ), I recomend - and
install servers sometime ( as in the city-hall of Nasaud - Romania ), and In
general I do my own war with local zealots from PC shops, magazines.

2008/10/10 Sam Brightman <email address hidden>

> I'm pretty sure my system has PATA and SATA controllers integrated on
> same chip but I don't use the SATA at all and still get this problem.
>
> --
> Grub installs to wrong drive's MBR in default install. No way to change in
> standard installer.
> https://bugs.launchpad.net/bugs/46520
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Nemes Ioan Sorin

I can confirm that this bug still exists in Intrepid. I just did an install of Intrepid on a spare partition, and had the same thing happen, EXCEPT that the Intrepid entries were immune from a casual user's standpoint, as the UUID even for specifying root seems to have taken care of the issue. I found this out by taking a look at my Intrepid menu.lst, where the other operating system entries still have the same issue I have seen since (I think) Edgy, the first version I tried.

I have one SATA drive and two IDE drives. In BIOS/grub the SATA drive comes first with the IDE disks following. In the OS and installer, the IDE drives are sda and sdb, with the SATA drive sdc. Because of this, the installer sets all my boot entries to hd2, instead of hd0 where they belong.

I was thinking that the entries were simply reversed, but now I am no longer sure. If it would be helpful, I will take a look at boot grub and OS and check the order of the IDE disks.

Tor

I encountered the same problem (grub error 2) after installing, and this cost me many hours. I considered recommending Ubuntu for some non-technical friends, but it seems that this still won't be an option.

Anyway, here is a complete summary:

- I have an internal NVIDIA mirror RAID with Windows on it. Touching that RAID or writing anything on it was not an option
- Decided to install Ubuntu to external USB disk
- Installed Ubuntu 8.10 using the alternate installer
- Created 100mb boot partition (sdc1), 100 gig root (sdc5) and 5 gig swap (sdc6)
- Selected "do not install GRUB to default location" and forced install to /dev/sdc (the MBR of the external drive)

Then rebooted, and put the external drive before the internal in the boot order.

Good news: without the external drive, Windows boots, the RAID is completely unaffected
Bad news: with the external drive, Grub crashes out with "Error 2"

I have not been able to solve the problem directly in Ubuntu. The UUID setup GRUB uses now doesn't seem to work properly. The only way I can boot into my Ubuntu at /dev/sdc at the moment is as follows:

- Boot from supergrubdisk CDROM (ISO image from super grub disk site)
- Fall back to the GRUB command line
- Enter the setup parameters manually:

root (hd2,0)
kernel /vmlinuz-... root=/dev/sdc5 ro quiet
initrd /initrd-...
boot

This gets me into Ubuntu. I have tried putting these commands verbatim into the GRUB menu file. It doesn't work, I still get the error.

Good luck!

Christian

p.s. I have seen some posts around the Internet from people saying this bug goes away "if you disable your internal disks" or "if you disable the RAID array". These are not options, I have important data in my Windows installlation.

On Fri, Dec 19, 2008 at 5:21 AM, xcut <email address hidden> wrote:

> I encountered the same problem (grub error 2) after installing, and this
> cost me many hours. I considered recommending Ubuntu for some non-
> technical friends, but it seems that this still won't be an option.
>
> Anyway, here is a complete summary:
>
> - I have an internal NVIDIA mirror RAID with Windows on it. Touching that
> RAID or writing anything on it was not an option
> - Decided to install Ubuntu to external USB disk
> - Installed Ubuntu 8.10 using the alternate installer
> - Created 100mb boot partition (sdc1), 100 gig root (sdc5) and 5 gig swap
> (sdc6)
> - Selected "do not install GRUB to default location" and forced install to
> /dev/sdc (the MBR of the external drive)
>
> Then rebooted, and put the external drive before the internal in the
> boot order.
>

By changing the drive order you made the drive stop being /dev/sdc (hd2,0)
and it became /dev/sda (hd0,0)

What you want to do is specify the boot drive usually with a F12 menu in the
bios. Not change drive order which is what causes grub to fail.

I probably phrased what I said badly: I meant I changed the boot order of the disks. I did not reorder the disks.

Note that in the snippet I put in manually above, I type in root (hd2, 0) into super grub disk, i.e. the disk is still sdc. I have no idea why this gets me in through the boot CD, but not when it tries to read the same grub instructions from the MBR.

This bug still exists and was reproduced by my attempt to install Ibex on my multiple hard drive system.

I have 6 IDE drives, and one IDE CDROM drive. They are configured: /dev/sda, b, c, and d are hooked to a Promise PCI IDE card, master/slave channel 0, master/slave channel 1 respectively. These are LVM drives, and NOT boot drives. The motherboard's BIOS doesn't see these drives, as they are handled by the Promise IDE's onboard BIOS.

The other two drives are /dev/sde and f. These are both masters on channel 0/1 of the motherboard. The CDROM drive is also attached as a slave of channel 0. The motherboard BIOS sees these drives, and the boot order can be chosen to boot 1st from the CD, then from drive 0 (/dev/sde presumably).

I think I have old GRUB(s) hanging around on one or more of the MBRs from Gutsy Gibbon, etc. The Ibex installer put GRUB on the wrong drive. Going to a GRUB terminal and typing:

root (hd0,0)
find /boot/grub/stage1 (This line gives a file not found error)
find /grub/stage1 (This line works)
setup (hd0)
reboot

Allows me to get past the GRUB Error 2 problem, but then the boot fails as fsck can't access the /dev/sde1 partition... presumably because it thinks it is either busy or already mounted. Looking at it when it drops me into a rescue mode shows it is not mounted, but that the /dev/mapper/pdj.... is associated with that partition. Allowing it to finish booting by (crtl-D escaping from the rescue shell) correcly mounts the /boot partition, but I still can't fsck /dev/sde1.

This problem is present in Intrepid and easy to duplicate with a laptop and a USB disk.
Installating Ubuntu to a USB disk is likely to be a common scenario.

Set the laptop boot order to be: USB/CDROM/harddisk. Boot the standared live Ubuntu CD-ROM, plug
in the USB disk, and install to the first USB partition. Select the default (not advanced)
option and the result of the "successful" install will boot neither Linux nor Windows, with
or without the USB disk attached.

The Cause:
The Grub files are put on the USB /boot/grub, but the Grub bootloader is put
on the laptop harddisk master boot block. The menu.lst disk identifications are the USB UUID for
the Linux roots and (hd0... for Windows! Without the USB drive attached, the Grub bootloader
cannot find its files, so it fails. With the USB drive attached, the windows disk is wrong in
the menu.lst (It is not hd0, as menu.lst identifies it). Not sure why the Ubuntu boots fail,
unless since there is no bootloader on the USB disk, the disk is not even seen, and the UUID
is not found.

Workarounds:
  1) Windows boot works (only with USB attached) when you change the boot order to hard-disk first, then
the Grub "hd0" is accurate for the Windows sections. I thought I tried editing menu.lst, changing the hd0 to hd1
for the windows sections, and even trying to map (hd0) (hd1) ... all failed (before fixing the USB boot, then just
changing the hd0 to hd1 worked).
  2) Linux boot may be fixed by booting the CD-ROM, and doing the Grub install again to the
USB disk (needed the --recheck and the explicit root-directory flag to get beyond the "disk not
 supported by bios complaint"). Then replace the menu.lst file, which disappeared! (I had a backup called menu.lst~).
  3) To use the laptop without the USB disk, either:
    a) Restore the MBR with the Windows Recovery Console's FIXMBR (good luck, finding the Recovery Console is the hard part!).
    b) Find a (Windows) fdisk on a bootable media, and fdisk /mbr
    c) Do a complete Grub install to a FAT partition (like the recovery partition found on many laptops these days). I
       finally did this, since I have messed up a system before looking for the Recovery Console on the
       vendor supplied recovery disks.

Other (hopefully) irrelevant details:
 * AMD cpu laptop, NTFS primary partition, FAT recovery partition
 * MAXTOR 200G USB disk, 9 partitions, first partition 50G for the Ubuntu install, preformatted ext2. No swap. No boot.
 * Before repair, Grub console found the /ntldr on (hd1,1), but nothing was found on hd0 (?).
 * Visible devices were fd1-fd7, hd0 and hd1. I thought the 7 floppy disks were probably the misidentified usb disk partitions.
 * kernel is whatever the 8.10 live cd installs

Ubfan wrote:
> This problem is present in Intrepid and easy to duplicate with a laptop and a USB disk.
> Installating Ubuntu to a USB disk is likely to be a common scenario.
>
Probably true.
> Set the laptop boot order to be: USB/CDROM/harddisk. Boot the standared live Ubuntu CD-ROM, plug
> in the USB disk, and install to the first USB partition. Select the default (not advanced)
> option and the result of the "successful" install will boot neither Linux nor Windows, with
> or without the USB disk attached.
>
Sounds like a special case of the original bug. Possibly worth a new
bug, as the original bug was (I thought) fixed (at least for all
internal drives) by complete use of UUIDs in GRUB.
> The Cause:
> The Grub files are put on the USB /boot/grub, but the Grub bootloader is put
> on the laptop harddisk master boot block. The menu.lst disk identifications are the USB UUID for
> the Linux roots and (hd0... for Windows! Without the USB drive attached, the Grub bootloader
> cannot find its files, so it fails. With the USB drive attached, the windows disk is wrong in
> the menu.lst (It is not hd0, as menu.lst identifies it). Not sure why the Ubuntu boots fail,
> unless since there is no bootloader on the USB disk, the disk is not even seen, and the UUID
> is not found.
>
Sounds rather like the original bug here. You may have already changed
this by changing boot order, but I suspect that if you go to the grub
command prompt and look at the disk config, it will match the boot
order, probably with your USB disk first. From within Ubuntu you will
find that the USB disk comes second ("sudo fdisk -l" will get you that
information).
> Workarounds:
> 1) Windows boot works (only with USB attached) when you change the boot order to hard-disk first, then
> the Grub "hd0" is accurate for the Windows sections. I thought I tried editing menu.lst, changing the hd0 to hd1
> for the windows sections, and even trying to map (hd0) (hd1) ... all failed (before fixing the USB boot, then just
> changing the hd0 to hd1 worked).
>
No good idea about this. To my knowledge the only truly reliable
information on which number it should be is from the /boot/ grub's
command prompt. Use "geometry (hdX)", replacing "X" with a drive number
to figure out which disk gets which number, and compare with what you
get from either "sudo fdisk -l" or by using the grub prompt through
terminal by "sudo grub". I can tell you from my own experience that the
two different grub prompts can give different results.
> 2) Linux boot may be fixed by booting the CD-ROM, and doing the Grub install again to the
> USB disk (needed the --recheck and the explicit root-directory flag to get beyond the "disk not
> supported by bios complaint"). Then replace the menu.lst file, which disappeared! (I had a backup called menu.lst~).
> 3) To use the laptop without the USB disk, either:
> a) Restore the MBR with the Windows Recovery Console's FIXMBR (good luck, finding the Recovery Console is the hard part!).
> b) Find a (Windows) fdisk on a bootable media, and fdisk /mbr
> c) Do a complete Grub install to a FAT partition (like the recovery partit...

The laptop is an HP Presario v3100 with an 80G Seagate ST98823as drive. Always thought it was IDE. From the interrupts, it looks like the harddisk is on the secondary slot, with the dvd/cdrom on the primary (or nothing since the number of primary interrupts is 0). No tools to actually open things and look, sorry. I'm all set up and running the way I wanted, now, thanks.

I recently had this on a fresh install of 8.10...

I grub defaulted to hda install. It apprarently failed the first time as hda did not exist. second time i told it to manually install to "sda" and then it worked.

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/45989
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/414996

I believe this issue has been fixed... I have been installing Natty32/64 and Oneiric32/62 onto USB-Sticks from my notebooks without having my main MBR being overwritten.

Experienced this issue running the server installation for 10.04 LTS from a USB stick to a RAID - Ubuntu was installed to the RAID but grub was installed to the USB stick.