My current SSD drive appears to be failing, but I need the installation for current work, so I don't want to just immediately replace it.

My intended plan is the following:

  1. Connect a new SSD via USB (using a device like this https://www.amazon.com/gp/product/B00MVRS38G/ref=oh_aui_detailpage_o02_s00?ie=UTF8&psc=1) and create a new installation on that drive. (It will be some variety of Ubuntu probably.)

  2. Boot from that USB connection to set up my new installation. However when I need to go back to my old installation, the old drive will still be connected so I should be able to just boot from that.

  3. When I have the new installation the way I want it, take out the old SSD from the internal SATA connection, and replace it with my new SSD.

From some Googling, it seems that both 1. and 2. are standard and shouldn't create any problems. (But please correct me if you forsee any.)

My question is primarily about 3. -- will this create any problems?


The installation is not the problem, it will be the bootloader(s) on a UEFI machine. A legacy machine should be no problem, grub will install to the external drive as requested, and the disk may be moved to the internal location.

There are several bugs on an install to an external disk which you should be aware of:
* 1173457 -- Ubuntu Installer uses wrong bootloader location for USB UEFI installs
* 1229488 -- EFI install to removable media not supported (unwanted nvram changes shimx64.efi to grubx64.efi, makeing a secure boot enabled machine unbootable.

Get ready for the UEFI install, and put an EFI partition on the external SSD. This external partition will be ignored, regardless of what you enter on the grub location during the install. Also in preparation, make a copy of the /EFI/ubuntu/grub.cfg file (like grub.cfg.orig). This file uses the UUID of the internal disk's root, and will be wrongly replaced with the external disk's root UUID. After the install to the external disk, you will have to manually copy the internal EFI files over to the empty external EFI (bug 1173457). These files are correct for the external device, but the host is left with a stub /EFI/ubuntu/grub.cfg which has the UUID of the external disk's root (for the maintained grub.cfg file). This boots as long as the external disk is present, but I'd suggest simply copying back the grub.cfg.orig file to grub.cfg (or just edit the UUID back to the original).

On the external disk's EFI, check that you have /EFI/ubuntu/grubx64.efi and /EFI/ubuntu/shimx64.efi (these will be the normal bootloaders when the disk is moved to the internal location). Also check that /EFI/Boot/bootx64.efi exists and is a copy of shimx64.efi. /EFI/Boot/grubx64.efi should also be present. You might get away with only grubx64.efi as the file bootx64.efi when secure boot is disabled, but using shimx64.efi as bootx64.efi should work in either case. The /EFI/Boot location bootloaders are used when the external disk is still a "removable" disk in the external case. The external disk should boot when it is selected as the boot device.

When the external disk is moved to the internal location, there might be a boot problem. The nvram probably has some of the old disk identification, so a new boot entry might be needed (efibootmgr may be used to create a new entry). Another possible error is for a shimx64.efi boot entry to be changed to grubx64.efi, which wont work with secure boot enabled. Maybe the boot will actually work via a fallback mechanism. When/if the old nvram entry fails, the /EFI/Boot entries may be tried. Even if this succeeds, I'd suggest you use efibootmgr to make the regular /EFI/ubuntu/shimx64.efi (or grubx64.efi). entry.

Invalid partition table may be something like using GPT on an old machine that does not boot with GPT, or installing to the device instead of a partition, making the location of the partition table really part of the filesystem. What partitioning did you use, and what does it look like (when in the external enclosure).

| improve this answer | |
  • I have my machine set up in Legacy boot mode, so from your answer it sounds like I don't have much to worry about. But very helpful info -- hopefully someone else finds it useful! – evencoil Jan 22 '18 at 16:23
  • I tried this today and I was not able to boot: "Invalid partition table!" Any ideas what went wrong and how to fix it? – evencoil Jan 24 '18 at 1:46
  • Found out what was happening. The boot order was still set to start with the old drive (now connected via USB), and trying to boot off of that drive led to the "Invalid partition table!" error. Based on your comments, this was not what I was expecting. However it was easy to fix by just changing the boot order to now start with the new (now directly connected) drive. – evencoil Jan 25 '18 at 15:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.