This is not a question how to basically solve this (it is already solved). I just want to better understanding.

I already found a good and logic answer here: the cloned partitions are not in exactly the same position

But I still have some problems understanding the whole process. Or better - how to avoid the troubles I had.

The scenario is (not) classic:

  • Clone SATA HDD to USB SSD (in my case AOMEI backupper standard)

  • Put SSD inside the laptop (yes I removed the HDD first ;)

  • Power on - Sorry - no bonus - no boot - no repair (because of the shifted sectors -> repair)

So now I had the (sick?) idea to use the original HDD per USB to boot.

  • Power on - Sorry - no bonus - no boot BUT repair (And this is the first question, because this sectors where not moved)

  • With repair I went directly to command line - diskpart and co

  • Then I came to bootrec /rebuildbcd I got both windows systems offered for repair - ok - but then the Error: '.... failed ... indistinguishable systems' (or alike)

Well ok, that's a clone ... (2nd Question: same disk signature? If yes how to change?)

I solved this with a sick idea:

I started bootrec /rebuildbcd again but after scan and before selecting Windows on C: (SSD) I unplugged(!) the USB HDD - and - voila: it completed successfully. And I booted from SSD.

Summary of Question(s):

  • Why did (or does) the original HDD not boot from USB? Is it because of same Disk ids? If yes how to avoid? (and run into windows activation probs?)

  • What are the 'things' that lead to "indistinguishable systems error"

  • Had it been possible to repair the EFI system on the SSD while on USB (before swap)?

1 Answer 1


There are two different answers to your question depending on how the computer booted originally. In fact, the explanation you cite for the problem's cause (changed partition location) applies to just the first scenario, AFAIK (with the caveat that I know less about Windows booting than about Linux, so I may be misunderstanding this detail of Windows EFI-mode booting). The two boot modes -- and scenarios -- are BIOS-mode and EFI-mode. There are also some common factors that might be at play.


Most computers sold prior to late 2011 used Basic Input/Output System (BIOS) firmware. BIOS-based computers boot via a boot loader that's stored in the Master Boot Record (MBR), which is the first sector on the disk. I won't go into all the gory details, but most BIOS-mode boot loaders are highly dependent on the starting sector numbers of the partitions on the disk. This is because the MBR is too small to hold a full boot loader, so the MBR code loads more boot code from a partition's Partition Boot Record (PBR; the first sector of a partition), which in turn loads additional code (also often referred to by sector numbers). The exact details vary with the OS and boot loader, but the key point is that sector numbers are critical in most cases. Thus, if your disk-cloning operation altered the start sector of a boot partition without adjusting the boot loader code or configuration that relies on it, the boot process will fail.

There are other partition details that can affect things, such as the presence (or absence) of a "boot flag" (aka an "active flag") on the bootable partition. Because boot code resides in the MBR and PBR, a disk cloning operation would have to copy this boot loader code, too. There's no guarantee that some random disk cloning program would copy these things. (I can't speak to AOMEI, which you say you used, specifically.)

Note that most (but not all) computers that shipped with Windows 7 used BIOSes, as did all Windows Vista and earlier computers (except for those that used Itanium or other exotic CPUs). Starting late in 2011, manufacturers shifted rapidly from BIOS to the newer EFI/UEFI (described next), but most EFIs include a feature called the Compatibility Support Module (CSM), which enables these computers to boot in the BIOS way (aka "legacy mode"). Thus, it's possible to install Windows (even Windows 8.x and 10) in BIOS/CSM/legacy mode on newer EFI-based computers. When so configured, the computer works like a BIOS-based computer.


The Extensible Firmware Interface (EFI) or its 2.x variant, Unified EFI (UEFI) is a replacement for BIOS, which became the dominant firmware on new computers starting in late 2011. Confusingly, though, many manufacturers use the term "BIOS" in reference to their EFIs. IMHO, this is a bad practice, since it leads people to think that EFIs are just minor updates to BIOSes, but they're really radically different in the way they boot.

The EFI way of booting involves files; the MBR and PBR play no special role and do not hold boot code. The computer knows which boot loader file to launch because that information is stored in NVRAM by the OS installer. (A special fallback filename, EFI/BOOT/bootx64.efi, is used by bootable external media like USB flash drives.) EFIs, unlike BIOSes, understand partitions, and so EFI boot loaders do not normally refer to partitions' start sectors. Thus, the start sectors of partitions are much less important in EFI-mode booting.

Instead, EFI-mode booting relies on some way to identify the partitions themselves. This is normally done by globally unique identifier (GUID; aka UUID) values associated with both disks and partitions. Thus, if a disk-cloning operation preserved the disk and partition GUID values, the cloned disk should remain bootable. If not, the boot process might fail at one step or another. I have no idea whether AOMEI would preserve GUID values by default. Note that replicating a GUID would normally be discouraged, since these are supposed to be unique values; but in the case of a disk being cloned so that you can replace the old hardware, replicating the GUID values on the new disk is desirable so as to make the new disk bootable without changing the NVRAM entries.

One more complication is that many EFIs will actively purge invalid boot entries from their NVRAM. Thus, if you were to clone a boot disk to another in a way that does not preserve GUID values, and if you then remove the original disk, a computer might "forget" that the first disk was bootable. Thus, it might not boot when you plug the original disk back in.

Common factors

In principle, boot loaders and OS configurations might rely on filesystem serial numbers, UUIDs, or names in their configurations. These values are similar to the partition GUIDs, but they're stored in the filesystem data structures, rather than in the partition table. I don't know offhand if Windows does this, but most Linux distributions do.

If you run into boot problems, you must use OS-centric boot loader repair or re-installation procedures to fix things. The details can vary depending on the boot method. For instance, you would not use a tool that restores the MBR on an EFI-mode boot. A lot of older instructions tend to assume BIOS-mode booting, and so do not work with newer EFI-mode installations.

  • OK, after reading twice, and checking GUIDs of disk: AOMEI does change the GUID even with clone. So no chance for boot (GUID and sector shift) I understand. Since EFI wanted to boot old HDD, what did not work, it removed the entry from NvRam, and the next attempt to boot HDD via USB failed, and fallback too, because this disk was not ment to be a USB ever. So repairing the SSD in advance while USB should or could work. Only the "indistinguishable" is now a problem for me.
    – halfbit
    Jun 25, 2017 at 14:39

You must log in to answer this question.

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