2

I have a Windows 10 PC but I'm trying to teach my kids C programming and was trying to install linux to a removable USB drive.

PC setup: I have an i3 with an gigabyte z97x gaming 3 motherboard. I have windows 10 on the SSD and I have it set to boot UEFI only in BIOS (secure boot is off).

I booted the installer USB perfectly fine in UEFI mode by selecting it from the bios (clearly said UEFI) and was created using dd on an ubuntu distro on my linux laptop with the ubuntu install iso , in UEFI mode (F12 boot menu). That booted okay. To install it on the other USB, I ran the install ubuntu menu function on the installer drive. Then setup my own partitions on the Installee USB. I made a 512mb efi partition (primary), a 27gb ext4 part (primary), and a 4gb swap part (also primary).

i selected to install the bootloader to /dev/sdc. It installs great and reboots.

Okay...so now things get a little odd. And I can't figure out what I'm doing wrong here.

When I look at my boot options at the F12 bootselector there are 4 options listed. Windows boot manager, ubuntu, ubuntu, (yes 2 of them) and Samsung 32gb UEFI boot (the usb drive is a samsung). If I select Windows it boots to windows. If I select Samsung 32GB UEFI it still boots to windows?! But if i select ubuntu...it boots to ubuntu on the 32GB USB drive.

More frustratingly, if I pull the USB drive out, the samsung UEFI boot option disappears but the ubuntu options remain. When you click on them without the USB drive in, it goes to a grub menu and won't boot. In bios those two ubuntu options are listed under the SSD drive meaning even though i specifically told it not to install there, it still installed grub on it?

Windows fortunately will still boot if the windows boot manager is selected but this is very frustrating. Why did it mess with it? I went to windows repair and used bootrec and did both /FixMbr and /FixBoot but the ubuntu options remains. Grub seems to have stuffed itself somewhere but I don't know where! The USB drive will not boot on my laptop either (though the installer will boot in UEFI mode just fine).

I'm not sure what I did wrong. I made sure I was in UEFI mode not BIOS mode when installing and I never selected anything that would touch /dev/sda in the booter to have it mess with my HD.

Fedora 23 will install just fine and boot in UEFI mode when installed to a USB drive.

Would really appreciate some help! Thanks!

Improve this question

2 Answers 2

Reset to default
2

When installing under EFI, the "device for boot loader installation" option (or whatever it's called; I haven't checked that detail) is ignored. I haven't verified that it actually works, but there is another way to specify where the boot loader goes: It's what partition is marked as an "EFI boot partition" or "EFI System Partition" (the term varies with the Ubuntu version) in the "Something Else" partition list. In theory, if you mark the ESP on the USB drive, and unmark the ESP on the hard disk, the installer should put GRUB 2 on the USB drive. I haven't tested that this actually works, but it should work.

That said, you're running into another problem, too: The EFI boot manager entry that you describe, for booting from a USB drive, does not launch the EFI/ubuntu/shimx64.efi file, which is where Ubuntu stores its first boot loader. Rather, that option launches the "fallback" EFI boot loader file, EFI/BOOT/bootx64.efi. This filename is used as a "generic" boot loader filename for removable media. The idea is that an OS installer or other external medium isn't likely to have a working NVRAM entry, so a standardized boot loader location is needed to boot OS installers, emergency disks, etc. Thus, if you want to make a USB drive that can be booted on any x86-64 EFI-based computer, you must copy EFI/ubuntu to EFI/BOOT and rename EFI/BOOT/shimx64.efi to EFI/BOOT/bootx64.efi. IIRC, you'll have to leave EFI/ubuntu in place, too, since there are hard-coded paths in one or more binaries, so both directories are needed.

Another point: If you intend to use the USB drive on just one computer, you may be able to get away with not copying GRUB to EFI/BOOT; however, some EFIs clean up their NVRAM entries if they boot and notice that an entry is inaccessible. Thus, if you remove the USB drive and boot without it inserted, you may lose the ubuntu entry. For this reason alone, copying GRUB to the backup filename is desirable.

The reason you're seeing a grub> prompt when you try to launch the ubuntu option with the USB drive unplugged is because Ubuntu's GRUB configuration relies on a GRUB binary on the ESP (on your internal disk) and configuration files in the Ubuntu /boot partition (on the USB drive). Thus, when the USB drive is unplugged, GRUB launches, but can't read its configuration file, so it fails miserably.

Improve this answer
2
  • Thank you very much for your detailed reply. I think I understand. I'll try this, this weekend and see if I can get ubuntu booting on this (and maybe even remove it from my HDD). I do have a question, when Ubuntu goes through a software update and installs a new kernel let's say, will I have to repeat this process each and every time to get the USB drive into a bootable state? Will it again write the UEFI to the main HDD and I'll have to move it? I'm finding Fedora seems is doing this well on the USB without having to move everything around even after an update...(I just can't stand Gnome 3)
    – FrostedCookies
    Mar 18, 2016 at 17:45
  • 1
    No, kernel updates involve updating the GRUB configuration file in /boot/grub, but they do not require re-installing GRUB. That said, there are occasional GRUB updates, but they're pretty rare; and if you neglect to copy the GRUB files after such an update, chances are everything will keep working -- you'll just be using an older version of GRUB, which is probably fine.
    – Rod Smith
    Mar 18, 2016 at 21:37
2

You bumped into a known bug 1173457 in grub of always installing to the primary EFI instead of where you indicate. However, you are also confused by the new UEFI boot mechanism -- The Ubuntu bootloaders (shim, grub) get put into the EFI filesystem in their own directory, /EFI/ubuntu, not overwriting anything Windows. The simple solution is just to copy the primary disk's EFI filesystem over to the USB, and select it for the first boot device. The other gotcha is that Ubuntu's grub is still unable to boot Windows with secure boot enabled, you will need to use the EFI boot menu (some function key at power-up to select device/oses), or disable secure boot.

Do add yourself to the bug "list" on 1173457 (the "does this bug affect me question). Since a second person has never added themselves, this bug, filed in 2013, has never even gotten to "confirmed", so maybe that's why it was never fixed.

Good question about the updates, but even if they go to the wrong ESP, the old versions keep working, so you might never know.

Improve this answer
2
  • Thank you very much for your reply. It's helpful to know I wasn't doing something obviously wrong. I'm wondering, Fedora uses grub2 as well, why didn't it have this problem? Did they patch the bug and use that version? And quick follow up question to that, if I do get Ubuntu working (I prefer it's UI) when grub is updated or a new kernel is installed, will that run update grub and reinstall it to the primary HDD yet again?
    – FrostedCookies
    Mar 18, 2016 at 17:36
  • I found this: bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1173457 and added myself as a second afftected user (really the 3rd because ubfan1 is the 2nd) but I noticed that if you use the "also affects project" link, the confirm page says "ubiquity doesn't use Launchpad to track its bugs. If you know this bug has been reported in another bug tracker, you can link to it; Launchpad will keep track of its status for you.". Where is their bug tracker and is this indeed a "ubiquity" bug or some sub-project involved specifically with the EFI/GRUB stage of the installation?
    – Robert Munafo
    Aug 13, 2016 at 1:28

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .