0

I currently have a laptop w. a 2tb internal hard drive & Windows 10 installed on it. For coding reasons, I would like to run Ubuntu from a USB drive if I needed to but still retain my Windows hard disk and not modify it in any way. I already made a USB stick with an ISO Ubuntu 17.04 image, but anything I do on it is not retained once I shut down the PC; therefore, I suspect I need to fully install it to a storage device, but I don't want to run the risk of accidentally wiping my internal HDD... how would I go about doing this?

Any help is appreciated; thanks, in advance.

Caleb M
  • 11
  • @ubfan1's answer is a good and detailed description. A simple alternative, that might work for you is to unplug the internal drive and after that install Ubuntu from one USB drive (a live drive) to another USB drive, the target drive. This way the target drive will be treated like it were an internal drive. After the installation you can plug in the internal drive again. In many computers you can use a hotkey to get a temporary boot menu, where you can select which drive to boot from. You may need to turn off secure boot to allow booting from USB. – sudodus May 01 '17 at 05:12
  • Mkusb will make a Live Persistent install that will retain all of your changes without the need of doing a Full install, It will work on a 4GB USB drive, a Full install of Ubuntu requires an 8GB drive minimum. Mkusb will do either a MSDOS or GPT install. – C.S.Cameron May 02 '17 at 16:27
  • If your main reason to use another operating system you may be better off with a virtual machine than a dual-boot installation. – David Foerster May 12 '17 at 19:32

1 Answers1

1

UEFI full install to a USB using another USB install media.

Superfically the same as a legacy install with the addition of an EFI partition on the target USB, but there are problems which may leave you with an unbootable target and even host.

First decide if you want MSDOS or GPT partitioning on the target USB. You might want MSDOS partitioning if some (older) machine wont boot with a GPT USB stick. GPT probably is the default here. In either case, your first partition will be the 300M EFI partition. It will have a FAT32 filesystem and the boot flag.

Next decide if you want the target USB to boot with both UEFI and legacy MBR bootloaders. This depends upon how you want to use the USB. It's a little more work, but does improve portability. If you are using GPT partitioning, you will need to include a 1M partition without a filesystem, with the grub-bios flag. You can just add the 1M partition now and for a later project to add the legacy grub-pc bootloader to your UEFI stick.

Select in your UEFI settings (formerly known as the BIOS) the ones which allow your install USB to boot in UEFI mode. The install media can boot in both modes, so to create a UEFI target, it needs to boot in UEFI mode.

The rest of the USB target may be your root (/) filesystem. Don't bother with swap, it will be unbearably slow and if used, will cause more rapid wear on the stick. For the filesystem, avoid journaling, which may also cause undue wear -- ext2 or ext4 without journaling. You may need to set "ext4 without journaling" before running the installer, that may not be a choice.

Boot the install media, if you set up the partitions, select the "something else" choice, then identify the root (/) and EFI System Partition (ESP). The bootloader location you want to be the target USB, (example /dev/sdc), but whatever you enter, will be ignored. Run the install, and then start dealing with the problems.

Problems 1) The bootloader location you input for your target is ignored, and the bootloaders get copied to sda's ESP.
Bug 1173457
Fix: Copy everything in the sda EFI partition to the target's EFI partition. These are just files, copy them any way you like, keeping the directory structures.

2) One of the bootloader files improperly copied to sda, grub.cfg, references the target USB. This file overwrites the grub.cfg in the host's EFI partition, so the host will no longer boot without the target USB present.
Bug 113457
Fix: Before the install, backup your host's /boot/efi/EFI/ubuntu/grub.cfg to .../grub.cfg.good so you may easily restore it after it gets overwritten.

3) Assuming you copied all the files in the host's ESP to the target's, the bootloaders are still in the wrong location for removable media.
Bug 1173457
Fix: Removable media boots off /EFI/Boot/bootx64.efi, so copy grubx64.efi and if present, shimx64.efi, from /EFI/ubuntu to /EFI/Boot, then rename shimx64.efi if present to bootx64.efi. If shimx64.efi is not present, rename grubx64.efi to bootx64.efi.

4)If your host was running with secure boot enabled, your nvram boot entry was shimx64.efi. The install to USB may have changed that to grubx64.efi.
Bug 1229488
Fix: Restore the nvram entry with efibootmgr. In this case, (boot failure of the first boot entry), some machines may try a fallback to /EFI/Boot/bootx64.efi, the removable media bootloader, before they try the second item in the bootorder. For this reason, I recommend setting up the host's /EFI/Boot just like the USB target's, with a bootx64.efi which is a copy of shimx64.efi or grubx64.efi.

There's an easy alternative, install to the USB target in legacy mode and add the UEFI bootloaders later. Use MSDOS partitioning, have a 300M FAT32 EFI partition, and a root (/) partition. Select the UEFI settings to boot your install media in legacy mode. Select "something else" in the installer, and select your root on the target. This is a normal legacy install which causes no problems.

After the install, copy everything in the host's ESP to the target's ESP. This brings over the Windows bootloaders, and the /EFI/Boot directory.

Find the target USB's UUID with: 

sudo blkid

Make a directory on the EFI partition at /EFI/ubuntu

In the EFI/ubuntu directory, make a file named grub.cfg with the UUID and disk and partition for the root partition:

search.fs_uuid YourUUID root hd1,gpt2  
set prefix=($root)/boot/grub
configfile $prefix/grub.cfg

Put a copy of shimx64.efi and grubx64.efi into /EFI/Boot, and rename the shimx64.efi to bootx64.efi. These files may be found on the install media under /EFI/BOOT, with the reaname already done.

The target should now be able to boot in UEFI mode! Optionally, you can make the ESP mount point /boot/efi on the target, and add a line on the target's /etc/fstab to mount the EFI partition there. You might want to do this if you install the grub-efi package, which may occasionlly update the bootloaders, but if they work, the only reason for doing that is security updates.

There's really not much difference between a legacy and UEFI install, just the bootloaders really.

ubfan1
  • 17,838