boot loader not installed to target disk

I can confirm this to be still present with 11.10 (didn't test it with 12.04 but will test with 12.10stable).
The bootloader of the primary disk is overwritten to start grub, which is installed on the linux-HDD. This results in problems when the linux-disk gets removed or formatted.

11.10 will not have a point release with cd-images. Please verify this bug with 12.10 daily and/or 12.04.1 images. There have been changes to boot loader target device selection in 12.10. Then set the bug back to confirmed if you can reproduce it there.

Okay, I'll do that, as soon as the 12.10 stable version is released.

Bug is still there in 12.04 LTS.

When doing an install from a USB stick, the installer defaults to putting the boot stuf on the USB stick instead of the harddrive I am installing the OS to.

(Status change on behalf of dmakfan - 12.04)

The attached patch fixes the issue, as it allows grub-installer to use the boot device passed to grub_default() when no GRUB installation device is explicitly set like in 'Erase disk and install'. As such, if the target is /dev/sdb, GRUB will no longer try to be installed to /dev/sda (assuming both are non-removable drives), and instead will just install to /dev/sdb.

The attachment "ubiquity-grub.patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

The problem is that the installer has no way of knowing that you intend to remove the other disk from the system and manually boot them separately. It assumes you just have two disks and want to be able to choose which OS to load at boot time. At best it would need some kind of prompt to ask which your intention is rather than just assuming it should install grub to the second disk.

The problem with the installer at the moment is that it blindly tries to install GRUB to the first disk in GRUB's device map, regardless of if it can or not (apart from the special removable device code). This causes problems when /dev/sda is a secondary disk that isn't configured at the time of installation, and so because it contains no MBR GRUB fails to install on it. I can see why installing to a drive that is different to the one /boot exists on is beneficial with multiple OSes, but to be honest when one selects 'erase disk and install Ubuntu' they likely do not have or care about any other operating systems on other drives.

Even if another operating system exists on another drive, with this patch GRUB will be installed to the 'secondary' drive, and so to start using it one must simply change the boot order in the BIOS/UEFI. In addition, perhaps the user does not want to overwrite the existing bootloader, say, if GRUB is being managed by a different distribution on the same system. But I just think that if one has another OS installed on a system, they'd probably use the manual partitioning selection which allows them to set the bootloader location manually, rather than the 'automate everything, erase disk and install' option.

You make a good point about the erase option, but we still want the side by side option to stick with sda because you don't want people have to figure out that they need to tell their bios to boot from the second drive. Then again, I don't think the side by side option even lets you pick the other disk anyhow so maybe it's a moot point.

Problem is still there in 16.04 LTS (pre-release).

In my case I have a laptop with one internal disk and I'm installing on an external USB-attached disk (/dev/sda and /dev/sdc respectively).

The result makes no sense to me. If I boot the laptop without the external disk, I end up at a Grub command prompt. I can't boot from the external disk because there's no boot loader on it. Surely I should be able to boot a system from one or the other disk alone.

The internal disk is mounted as /boot/efi, and has EFI/ubuntu/grub.cfg with the content:

search.fs_uuid xxxx root hd2,gpt2
set prefix=($root)'/boot/grub'
configfile $prefix/grub.cfg

where xxxx is the UUID of the root partition on the external disk. So it's quite deliberately requiring both disks to be present.

Let's at least have a warning message that the internal disk will be modified. There is no mention of /dev/sda in the installation, only a warning that /dev/sdc will be changed (see screenshots).

I think there are two different symptoms.
One is for legacy BIOS and the other is for UEFI BIOS.
Regarding UEFI BIOS, it may be caused by Bug #1512589.

I installed Xubuntu 16.04 from a DVD to a new SDD. I ended up with a system that had no bootloader. I have other disks with earlier Ubuntu releases and thought "Erase and use entire disk" was the safest. I had to re-install using manual partitioning.

The release version of xenial trashed the boot sector on the target disk. I've re-installed from the late April testing version.

It gets worse!!!! After trying all the suggested ways of restoring the boot sector and failing, I used the live cd to re-install xenial, with the other two internal drives I have, disconnected. Ubiquity on the lat April testing version) - showed grub being installed, and update-grub being run. BUT when re-booting, I got the grub error prompt. It seems the problem's been there for a while!

I'm using UEFI. I've found that Rod Smith (of rodsbooks.com fame) has written some typically detailed reports about this problem in bug #1571354 and bug #1567534.

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/704763

Two years later, still a problem in 18.04 installer. I was trying to install Ubuntu to a USB drive.

The graphical installer has a dropdown for "bootloader location", but it does not work and instead installs to /dev/sda1.

I ran into this problem under Ubuntu 20.04 Beta on my 2008 MacPro while attempting to have the boot loader installed on the same drive as the linux installation rather than the drive with my macOS installation. Using the Custom Partitioning option to install / on /dev/sde2 (ext4) and the device for the boot loader installation set to /dev/sde, the following glitch occurred. The boot loader was still erroneously installed on the EFI partition of the macOS drive (/dev/sda1) and worse the installer recreated the EFI partition on /dev/sde1 with the identical blkid name as that used by /dev/sda1. So it left my system with two physical drives having identical blkids for separate partitions.

Same problem, 20.04 on 2019 Mac Pro. And in this case, I *can't* install GRUB on the internal drive at all, because the built-in NVME disk is non-writable in Linux. So I had to go through a lengthy process of mounting things and running grub manually with about a hundred-character-long command.

Worse, every time I install any kind of update that upgrades the kernel, it looks like I have to repeat that whole lengthy process, or else the system won't be bootable.

How is something so critical still so badly broken after this many years? Installing the bootloader on the same disk as the OS should be the DEFAULT. Installing it on some random disk shouldn't even be POSSIBLE, much less the only supported behavior.

If the internal disk ever becomes writable in a future kernel update, this bug could be *seriously* bad.