I think syg00 had it correctly as a uefi problem. Stupid uefi.

I tried to find your definition of "doesn't work" in this thread, but if it's here, it escapes me. What exactly (in detail) are you doing that leads to your conclusion 'doesn't work'?

I suspect rknichols has defined the problem here. One cannot do a full disk clone and expect to boot anything until something's been done to eliminate the replicated UUIDs and volume labels. Neither bootloaders nor device drivers nor motherboard firmware can cope with such duplications as are created by true cloning. Once the clone's been made, dupes must either be removed before rebooting, or rebooting must be done with one or the other device removed at least until any given boot is complete, lest risk of or actual corruption occur, if any boot at all is even possible.

I've been multi-booting and cloning much too long to remember, if not since last century, at least nearly so. My average OS installation per machine is well in excess of 10. When boot fails here, it's because I forgot something, not a failure of my cloning program to do what it was designed to do.

This is obviously true. My understanding, at least, is that this would not likely be an issue since the OP wanted to simply have a "hot backup" of sorts on the cloned physical disk to replace the original one if required because of failure. Hence, at no time would the 2 disks be present in the same system, therefore no UUID conflict.

If my understanding is incorrect, please forgive me and clarify.

Cheers,

That was the intent, yes, but I see no mention of the internal drive being disconnected during the failed attempts to boot from that backup drive. Even without the duplicate IDs, it is uncertain whether a Windows installation copied from an internal drive would boot successfully from a drive on a USB connection. Linux should have no problem with that, but Windows ...???

Replacing the internal drive with the backup drive was on the "todo" list of things to try.

1 members found this post helpful.

"I tried booting from the Inatek case the backup drive is in" doesn't read as though only one disk was present in the system at boot time. It would be on a different bus than the internal disk is in, but with identical UUIDs and volume labels as the internal, unless he changed them before trying to boot it.

.. true enough. Missed that detail. Your previous post, as well as rknichols above comment, are spot on.

Cheers, folks :-)

If you didn't, boot from a live usb and run dd from there. I've cloned a number of w10/linux dual boot machines with dd without problems, but I always use the intermediate step of having dd create the clone as a file, then use dd to restore that image file to another disk. This has the advantage of creating a backup, and with a dd image you can mount partitions from the clone image without having to restore to a physical hard disk.

Also, I've always cloned MBR to MBR or UEFI to UEFI.

Update: The dd clone worked. The laptop just doesn't like to do the dual boot thing from an external drive connected via a USB port. Once I pulled the internal drive and replaced it with the on to which the internal one had been cloned, the used-to-be external worked. I haven't tried a Clonezilla clone yet, and it's sort of a pain to replace drives.

To know if that is a true statement you will need to try booting the external without any internal drive installed. The more certain explanation is as we've noted in previous messages, UUID and volume label duplication are outside of bootloader, driver, BIOS and kernel capability to cope with.

I'm not really into advanced masochism, if it clones to an external drive and it works, the only time I am going to swap drives is if the internal one fails. I also copy my Home director out to another HDD (WD Passport) and retain various versions of that on that drive.

easeus cloned the whole dual boot laptop internal drive to a USB connected drive of identical storage capacity, but failed when I tried to recover the cloned disk back to the laptop drive, complaining that the destination drive had to be of equal or a larger size?????

I will try the same using clonezilla live, should the need arise, hopefully it won't .......but I saw a reply form syg00 saying that some table information is copied into NVRAM, so am wondering if all of this is in vain anyway.

I know you can cone TO a larger drive, but you won't be able to clone it back to a smaller one. Been there, tried that. You can clone the drive to a file, and then clone it back to the same size or larger drive. What I have not tried is putting a partition on a larger drive and then cloning to that partition. Dunno if that works. Like I said earlier, my drives are SSDs and the same size so I can clone back and forth with no problem and have done so several times - usually when I f^&% up the drive in the laptop and need to fix it. I am not above the odd science experiment!

Something very strange is going on here. As I said Easeus allowed me(from a size point of view at least) to clone my WD 1TB drive to my USB external Seagate drive but refused to clone it back saying the WD drive was too small. Now Clonezilla is refusing to recover saying saying the opposite with respect to sizes. ?????

https://www.linuxquestions.org/quest...1&d=1584496061

According to Clonezilla it now seems that either Seagate is coming up short when on 1TB drives by 1 cylinder with respect to WD, or the other way around as Clonezilla and Easeus seem to differ on the culprit.

Now, about the duplicate UUIDs and volume labels mentioned my mrmazda, how would I manipulate those to get an error-free cloned solution?

I don't use Clonezilla, so don't know if it might be able to handle these. I use blkid, partprobe and tune2fs or e2label to manage UUIDs and LABELs on EXTx filesystems. It may be necessary to reboot after the cloning operation with only one drive connected in order to change these successfully, depending on the details of the particular cloning process(es) performed.