grub-installer defaults to (hd0) which is the installation medium in the case of USB installs

Note that this must be somewhat duplicated in ubiquity from grub-installer as we need to know what boot device we're going to default to (to show in the advanced window) before grub-installer is run.

Notes from IRC:

< cjwatson> evand: I think your general approach in bug 282037 is fine, although I'm not absolutely sure about the grub-installer patch there. Is it possible that it should look more like the bootremovable stuff in the state=1 branch?
< cjwatson> evand: and how does said bootremovable stuff interact with ubiquity's boot device display? Maybe we ought to rip that out and do the whole thing differently, but we'd still have to make sure to cover both state=1 (only) and state=2 branches ...
< evand> cjwatson: Do you mean by default installing grub to the disk you're installing Ubuntu to, or only doing so when we know hd0 isn't correct, when it would be installing to the installation medium MBR?
< evand> state=1?
< cjwatson> well, I meant that it seems that in state=2 you want the default to be "install to MBR"
< cjwatson> which is the same as what you want if you answer true to the question in state=1
< cjwatson> I mean the 'if [ "$state" = 1 ]' conditional that starts at line 592
< cjwatson> so it seems that both of those cases ought to be handled the same way
< cjwatson> I suspect the reason we didn't notice what was wrong for years was that we thought we'd handled it with that $bootremovable business, but actually that only applies if state=1 is taken
< cjwatson> while it might actually be bypassed
< evand> ah
< cjwatson> like I say I think your basic idea is right though
< evand> can you clarify which one though? I proposed two options, one to always go with the device Ubuntu is being installed to, and the other to go with the device Ubuntu is being installed to if hd0 is the installation medium.
< evand> I suspect the latter, but I want to be sure.
< cjwatson> oh, right, um.
< cjwatson> given the difficulty of detecting what hd0 is it's really hard to say.
< cjwatson> for the time being, I think it may make some sense to special-case installs from USB disks, since then we know that the installation medium is about to be removed and putting the boot loader there will be bad
< cjwatson> i.e. I think your second option is probably better
< cjwatson> an example where the first option would fall down would be if you're installing to a second hard disk, where I think the sensible default is to put the boot loader where the BIOS is actually going to boot from, i.e. the first hard disk
< cjwatson> of course this won't please everyone and some people will call me names for saying the above is the sensible default, but that's why we make it selectable :)
< evand> indeed, that's the exact example I was thinking of. Ok, noted. I'll rework the patch to accomodate this and take another look at handling all states in grub-installer.

This bug was fixed in the package ubiquity - 1.10.5

---------------
ubiquity (1.10.5) intrepid; urgency=low

  [ Evan Dandrea ]
  * Filter out the net subsystem when calling update-dev to prevent the
    network connection from resetting (LP: #276383).
  * If ubiquity is installing from a disk, such as a USB drive, then default
    to writing grub to the disk that /boot or / is to be written to, as (hd0)
    will most likely be the installation medium (LP: #282037).
  * Automatic update of included source packages: apt-setup
    1:0.37ubuntu5, partman-auto 78ubuntu3, partman-base 121ubuntu7,
    partman-target 55ubuntu4, user-setup 1.20ubuntu9.

  [ Colin Watson ]
  * Fix typo in architecture detection for ntfsprogs dependency.
  * Work around lpia having DEB_HOST_ARCH_CPU=i686 (!).
  * Disable window minimise buttons if the installer is running in
    standalone mode (LP: #249045).
  * Update imported translations from gtk+2.0 2.14.3-0ubuntu3.
  * Update translations from Launchpad (LP: #144741, #218636, #277451).

  [ Emmet Hikory ]
  * Honor preseeded passwd/allow-password-empty (LP: #280014)

 -- Evan Dandrea <email address hidden> Mon, 13 Oct 2008 01:34:45 -0400

I used a daily net install last night (10/15/08) to install kubuntu from a USB and I ran into the same problem. I noticed it and fixed it before I committed, however after the reboot I ran into more funnyness. Grub had installed to the correct disk but menu.lst had the wrong UUID values. I think that I saved my original menu.lst. If you guys want I will see if I can get that and my UUID values to you. On a side note, I booted my disks out of normal order so I could install from the USB, but as I understand it the installer should still be able to find the correct UUID values and that should allow the disk to boot fine.

Perhaps I should mention that I was installing 8.10. I am guessing these are related but if needed I can start a new bug.

I don't believe that this has been fixed for net installs yet - that's part of the task on this bug that's still open.

I just wanted to make sure that you guys knew about the menu.lst
problem and at the same time give you all the details I could. I
wasn't even sure that the two problems were related. Thanks for
getting back to me.

-Evan

On Fri, Oct 17, 2008 at 10:24 AM, Colin Watson <email address hidden> wrote:
> I don't believe that this has been fixed for net installs yet - that's
> part of the task on this bug that's still open.
>
> --
> grub-installer defaults to (hd0) which is the installation medium in the case of USB installs
> https://bugs.launchpad.net/bugs/282037
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in "grub-installer" source package in Ubuntu: Confirmed
> Status in "ubiquity" source package in Ubuntu: Fix Released
> Status in grub-installer in Ubuntu Intrepid: Confirmed
> Status in ubiquity in Ubuntu Intrepid: Fix Released
>
> Bug description:
> Binary package hint: ubiquity
>
> The bootloader is by default installed to the first disk, which often makes sense as even if you have two drives, there is usually a bootloader on the first. However, this approach fails when the installation medium resides on the first disk, such as installs from USB disks.
>
> I propose we either use an approach such as the one in the two patches I've attached by default or only when we know hd0 is not correct, such as when we're installing from hd0.
>
> Colin, what are your thoughts?
>

Not quite sure I know how I should be testing this, but here is what I did:

Installed ubuntu 64-bit on a system with two internal drives, a 128GB SSD and a 500GB drive, both SATA. The system has no internal CD-ROM ATM, so I used a USB CD drive.

I used a desktop CD and chose to wipe the first disk (entire disk install). On the last screen of the installer I checked the Advanced button where I saw that the installer planned to put grub on hd0.

But after doing the actual install the system booted grub from sda (the SSD). It showed an entry for the 2.6.27-7 kernel on that drive and the correct 2.6.24 entries from the older system on sdb.

Grub was already installed on sda from the previous install there, but it was clearly updated on the new install.

Attaching syslog which claims grub was installed on hd0, but then went on do configure on sda (I'll leave detailed analysis to those who actually know how to read the logs ;) )

This bug was fixed in the package grub-installer - 1.32ubuntu10

---------------
grub-installer (1.32ubuntu10) intrepid; urgency=low

  [ Evan Dandrea ]
  * Set a sensible default boot device when /cdrom is not iso9660, as this
    is probably a USB install and (hd0) does not make sense when installing
    from a removable disk (LP: #282037).

 -- Colin Watson <email address hidden> Mon, 20 Oct 2008 23:08:21 +0100