2

I'm installing Ubuntu 16.04 onto an external HDD (sdb). My computer also has an internal Windows 10 HDD (sda).

When at the partitioning stage, I chose for the boot loader to be installed onto the external HDD (sdb).

When Uniquity is installing the system, it mounts Windows 10's ESP (sda2) and copies the Ubuntu/grub boot loaders over, when it should have mounted the ESP created on the external HDD (sdb1). /dev/sda2 is the Win10 ESP and it's mounted to /target/boot/efi. /dev/sdb1 is the correct ESP but is not touched.

Here's lsblk: lsblk

Because the boot information is not on the external HDD, the Windows 10 disk must be present to boot Ubuntu because the boot information pointing to Ubuntu is located on the Windows ESP - not exactly optimal.

The question is can I force Ubiquity to use sdb1 as the ESP. It makes sense to by default because it's where I chose to install grub but apparently not.

Ubiquity is version 2.21.63. I'm revisiting this issue because I need Ubuntu on this computer. I filed a bug report originally but it is still undecided/unassigned.

Brady Dean
  • 243
  • 1
    Grub has only installed to sda. I quickly learned to back up my main install's /EFI/ubuntu as new install overwrites it. With my flash drives, I have partitioned in advance, so external has ESP. Then copy /EFI/ubuntu to external & then copy again to /EFI/Boot and rename shimx64.efi to bootx64.efi. All external devices in UEFI boot only with bootx64.efi. http://ubuntuforums.org/showthread.php?t=2107873&page=4&p=12599515#post12599515 – oldfred Jul 13 '16 at 03:59
  • So you just copied all the ubuntu stuff from the original ESP to the new ESP? I tried the originally but couldn't get it to boot. I could have been doing it wrong though. – Brady Dean Jul 13 '16 at 04:05
  • You have to then boot external device, not an ubuntu entry. I added my 2 cents to bug. It may really be a grub bug a Ubiquity says installing to sdb, but it has always installed grub to ESP on sda. And with an external drive it has to know to create /EFI/Boot/bootx64.efi. If you copy files you have to also copy to /EFI/ubuntu as the shimx64.efi is hard coded to find other files like the grub.cfg which is a configfile only in /EFI/ubuntu. You can also manually install grub directly telling it that it is an external, but have to create your own grub.cfg to boot a full install. – oldfred Jul 13 '16 at 04:13
  • I might try selecting /dev/sdb1 as the grub install device instead of /dev/sdb. That might do something. I need to find the ubiquity docs to see if there's any options for specifying an esp.. – Brady Dean Jul 13 '16 at 04:19
  • Do not use sdb1, grub only installs to sda. Bit more info, I forgot the update to fstab to use new ESP. http://askubuntu.com/questions/720827/using-ubiquity-for-the-full-disk-encrypted-install-to-disk-on-dev-sdb-instead-o/722147#722147 – oldfred Jul 13 '16 at 04:28
  • If you want to directly create the bootx64.efi on external: http://askubuntu.com/questions/549647/uefi-machine-doesnt-boot-ubuntu-through-nvram-bootcatalog-how-to-fix But that requires your own grub.cfg and only installs the .mod addins you specify. – oldfred Jul 13 '16 at 04:32
  • I might do that. This is on a laptop and I cannot get to the hard drive. If I could, I'd temporarily detach it so Ubuntu would see the external hdd as sda, but the laptop is glued together. – Brady Dean Jul 13 '16 at 04:36
  • Let us continue this discussion in chat. – Brady Dean Jul 13 '16 at 04:48

2 Answers2

3

Two other workarounds occur to me, in addition to the one provided by Brady Dean:

Workaround 1

  1. Before running the installer, change the GPT type code of the EFI System Partition (ESP) you do not want to use to something other than the code for an ESP. Details of how to do this depend on the partitioning software you use:
    • In gdisk, sgdisk, or cgdisk, this would mean changing it from EF00 to just about anything else. (0700 will make it visible as a normal FAT partition to Windows.)
    • In GParted or parted, remove the "boot flag" from the ESP.
  2. Run the installation. With luck, it won't flake out and insist on finding an ESP on /dev/sda, but will instead notice the one on /dev/sdb and proceed normally.
  3. After installing Ubuntu, reverse step #1 -- restore the normal "ESP" type code to the ESP on /dev/sda. Forgetting this step may have few or no negative consequences, but depending on the type code you use, Windows may start showing it as a regular partition; and if you need to re-install Windows (or some other OS), it may be important that the type code be correct.

Note that I've never tried this approach, so I can't guarantee it will work. If it doesn't work, then that information should be added to the bug report referenced in the question.

Workaround 2

  1. Launch the Ubuntu installer in its "try before installing" mode.
  2. Open a Terminal window.
  3. Type ubiquity -b. The installer program should launch, but it will do so in a way that will cause GRUB to not be installed.
  4. Finish the installation normally.
  5. When you're done, Ubuntu will be installed, but won't be bootable. There are a number of ways to make it bootable. The two easiest are:
    • rEFInd -- This tool, which I maintain, is an alternative to GRUB. You can get a USB flash drive version from its downloads page and use that to boot Ubuntu the first time. You can then edit /etc/fstab to identify the ESP you want to use, mount it at /boot/efi, and install either rEFInd (via a Debian package or PPA) or the regular grub-efi package.
    • Boot Repair -- This popular tool, described in more detail here, can install GRUB. I'm not sure offhand, though, how to tell it to use an ESP on /dev/sdb rather than one on /dev/sda. You might need to use type code trickery, as in the preceding workaround; or perhaps just setting up /etc/fstab, as with rEFInd, would do the trick.

I frequently use the ubiquity -b method of installing on computers that multi-boot many distributions, since managing GRUB in such cases is a bit awkward at best and totally unworkable at worst; rEFInd does a much better job with such installations. Of course, this is a somewhat different problem than that of getting all your stuff installed on /dev/sdb rather than /dev/sda, but the same solution should work.

Rod Smith
  • 44,284
  • 7
  • 63
  • 105
0

Well I didn't find a solution, but I found a workaround.

  1. After booting the live cd, run dmesg | grep ata to find the id for the internal drive. In my case it was ata1.00
  2. Reboot the live cd but hit e to edit the grub configuration
  3. Add libata.force=1.00:disable to the end of linux. 1.00 comes from ata1.00
  4. Hit f10 and the machine should boot and Linux should not see the drive - check with lsblk
  5. Continue installation, Ubuntu sees the external as /dev/sda

I would also recommend adding this to the installed system's grub configuration so it doesn't even see the internal drive. Don't want anything happening to it.

Thanks to https://askubuntu.com/a/387261/440238 for the libata.force=1.00:disable part.

Community
  • 1
Brady Dean
  • 243