Back when hard drives were made out of stone, we used a command to copy everything from one disk to another and it would be bootable from DoS to Win XP, I think. When they changed the file system from fat to ntfs it would no longer boot unless it was a copied drive for that particular computer. You could no longer use it to copy your drive to another drive then put into a new chassis.
That said, the string was like this…from run> xcopy c:\ d:\ /e/c/f/h/y
D and E being the drives in the example. Of course you could specify any drives. Or files for that matter.
Is there a string like this for Linux? Copy an entire drive and be bootable? Process?
I remember that app from the days of the Amiga!
In short, yes, there is such an option. It’s called cloning or ghosting. The pre-installed version in Linux is to simply convert your one drive into an image (IMG) via Gnome Disks and then restore it to another drive.
Alternatively, there are some tools below.
However, you’ll need to not be using the drive while cloning or imaging (devices need to be unmounted for it to work). Which means that it’s best when done via another installed distro or via Live USB.
Greetings @vasileios !
I used Mint/Cinnamon’s ‘Disks’ to clone one SSD (#1) onto another SSD (#2). The two laptops are of the same make/model/components.
The process appeared to be successful until I rebooted the #2 laptop.
Error messages referred to “Invalid partition table” and “No Boot Device Found.”
Here’s what I captured of the process:
Laptop SSD #1:
- .img file created ok, as saved to 1TB, external SSD:
Laptop SSD #2:
With a non-responsive laptop (#2), I manually powered it off, effectively crashing the system.
Before restart, I re-inserted the Mint/Cinnamon-enabled USB drive.
At restart, I was able to F2 into the Boot Sequence menu and return the USB to first position in the sequence to regain control.
When I reboot without the USB plugged in, the error message returns.
Here’s the laptop #2 SSD’s current status:
So, I can run the #2 (cloned) laptop only via USB. Without the USB, the same above-listed error messages appear.
What can I do to avoid re-installing the .img?
Many thanks for your guidance,
Thank you for all the info, @nwarren!
There are some cases which I encountered once, that all it needs is for Grub to be re-installed so that it passes the correct information. It happened to me when I cloned my Arch installation to a bigger drive.
Let’s give this one a shot.
As you start from the Live USB, install the Boot Repair application. You can either go to the Software Center or the terminal, by typing:
sudo apt update && sudo apt install boot-repair
The update is to prepare the databases and find the Boot-Repair (otherwise it won’t have anything to look for).
Once it installs, run it and select the recommended option. It will look at whatever is wrong with the drive and fix it or at least give you a good direction per to what may have gone wrong.
Please let me know how that goes so that we take it from there.
The “recommended repair” wants a system change that I didn’t make until you guide me further, @vasileios.
Process, all on laptop #2:
- Connected laptop #2 to internet (hardwired connection).
- Booted to live USB.
- Via Terminal, ran, as you recommended,
sudo apt update && sudo apt install boot-repair
A lot of packages were updated.
- Via Menu, found and ran Boot-Repair, choosing the “Recommended repair” option.
Is it ok to disable the Boot Option, “Legacy Option ROMs”? What are the repercussions of disabling it?
Boot-repair has a default, advanced option of secure boot = ON. I had understood that we need to turn that off. Will Boot-repair turn it back on?
What is my next step?
Thank you for the screenshots, @nwarren!
You’ve encountered one of the most common issues! Legacy vs UEFI. The short answer is yes, disable both Legacy and Secure Boot so that your booting parameters revert to the EFI filesystem approach.
The automatic version also detects if the BIOS has Secure Boot on or off, so you don’t need to go into the advanced settings. And you are correct, it’s always best to have SB off!
oh wow. it worked.
I’m using laptop #2 now. It’s stunningly disorienting to see a different laptop beside me, while I’m using my usual programs, etc. in the same configuration to which I’m accustomed.
So here’s what I learned:
Do the work while connected to the Internet.
Disabling “Legacy Boot” requires two steps…and in a specific sequence.
- When UEFI is enabled, all the former Boot Sequence options change. I needed to manually reposition USB as 1st to boot.
4. ONLY THEN was I able to disable Legacy Options ROMs.
When I attempted to disable Legacy Options ROMs first, I got this error:
I rebooted after using Boot-repair via Live USB, then installed BR again, this time on the SSD, using the Terminal command from @vasileios
sudo apt install boot-repair.
Then I ran Boot-repair from the menu.
Question 1, @vasileios
- What problems could be caused by a “Locked-NVram”? (whatever that is)
Boot-repair ended with this error message:
I powered off the laptop, then powered back on, sans USB. So far, it appears that everything is working ok.
- Is there any potential issue I might encounter while using the cloned drive?
- Can system backups (and data backups) on laptop #1, be restored onto laptop #2, effectively retaining their status as clones? (I have changed the background image in #2 in order to know which machine I’m working on. )
oh wow. it worked.
Thank you, @vasileios.
Congratulations on getting it done! As you experienced, most of the issues appear due to BIOS configuration differences. Many distributions will initiate a completely different boot-loader setup if you have a Legacy boot as opposed to a UEFI boot. And when you’re dual-booting and both are enabled (it’s possible in some devices), some distros will go UEFI and others will go Legacy. It happened to me in my desktop of 4 OSs.
To answer your questions:
You don’t need to worry about it - as it’s not something that can be solved via any software. If the laptop produces any kind of issue in the future, just reset its CMOS, which is basically the BIOS memory.
The answer here is simple: No. I did it to my Arch, which I cloned twice. One from a Virtual Machine conversion and one to get it to a bigger drive. No issues there, other than the usual bleeding edge bugs that get resolved.
Another simple answer: Yes. As long as they have identical apps installed. Keep in mind, the file system will become identical to the snapshot of the TimeShift. Which means that any extra files in the second system will be wiped.