I’m attempting to clone my current 500gb disk to a 2TB disk. The disk has a dual boot windows/fedora 34 setup. The new 2TB disk is connected via a USB caddy. Both disk are SSD M.2. NVMe.
On my first attempt, I used clonezilla to clone the disk. This worked to some extent… the grub menu loads, I can select Windows or Fedora… Windows boots fine… Fedora gets to the loading graphic and then hangs, terminal shows it hangs on “basic system”. After doing some research I can see the locations (/dev/mapper/fedora-root, etc) do not exist on the cloned disk. I read I can update the /etc/fstab to the correct UUID, but there is no /etc/fstab on the new system. Also read I can run dracut -f but rebuild but I’d need a new live disk for that, the shell I’m in says command not found.
So with the above in mind, I’ve decided to try to clone the disk again but this time use DD. In the tutorial here it says I need to use lsblk to get the disk name (/dev/sdb or whatever) for the dd command… but the lsblk command doesn’t show me the disks, it shows me the nvme volumes, and I’m not sure how to proceed.
#lsblk: (on my old disk, booted into fedora normally)
nvme0n1 259:0 0 476.9G 0 disk
├─nvme0n1p1 259:1 0 500M 0 part /boot/efi
├─nvme0n1p2 259:2 0 128M 0 part
├─nvme0n1p3 259:3 0 317.9G 0 part
├─nvme0n1p4 259:4 0 609M 0 part
├─nvme0n1p5 259:5 0 1G 0 part /boot
├─nvme0n1p6 259:6 0 145.5G 0 part
│ ├─fedora-root 253:0 0 55G 0 lvm /
│ ├─fedora-swap 253:1 0 7.8G 0 lvm [SWAP]
│ └─fedora-home 253:2 0 82.6G 0 lvm /home
├─nvme0n1p7 259:7 0 9.8G 0 part
└─nvme0n1p8 259:8 0 1.1G 0 part
Any advice on either using dd, or any other method, is greatly appreciated.
The tutorial didn’t mention that you should specify a block size in the “dd” command, so use
dd bs=40960 ...
The default block size was fine in 1980’s where the disk block size were usually 512 bytes.
Also bear in mind that the uuid will also be cloned, so when both disks are attached to the system, the system will get really confused and does not know which disk is which.
I always use gparted for cloning partitions and resizing them and changing UUIDs, etc.
But I don’t think using clonezilla is likely to be the source of your problem. Maybe you did something else that you didn’t mention, such as change the UUIDs of the destination. Or maybe there was something very strange in your original etc/fstab or your grub.cfg.
I assume you mean when you reach the terminal in the incorrectly booted system, you don’t have the root partition mounted, so you don’t have access to /etc/fstab
Working from the old system, I assume you can examine/fix the copy. You can use gparted (or other tools if you choose) to change the UUIDs (if you hadn’t already). Once those are changed, you can mount the new partitions while booted in the old. Then you can examine the files that need UUIDs fixed: EFI/fedora/grub.cfg , grub2/grub.cfg and etc/fstab. Those will be in three different partitions on the new drive (the third in the / subpartition of the lvm)
@john2fx, I’ve not ran the dd command yet, so if I can rescue the clone I have then perfect, especially seeing as you are suggesting dd may give me the same issue I have had with clonezilla. I really didn’t do anything other than clone disk to disk in clonezilla… the target being the ssd in a usb caddy. And yes I still have the source up and running.
You, and several other posts I’ve read, mention updating the UUID, but I can’t find a guide on doing that.
Regarding my fstab missing… yes I’m referring to the target disk… when I put the disk in my machine and boot to it I get to a sh shell that lets me see /etc/ … I have other files such as /etc/fstab.empty (which is empty) and /etc/mtab … just no fstab…
This is the contents of my fstab on the working source machine:
#
# /etc/fstab
# Created by anaconda on Wed Jun 21 18:02:51 2017
#
# Accessible filesystems, by reference, are maintained under ‘/dev/disk’
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
/dev/mapper/fedora-root / ext4 defaults 1 1
UUID=828862a9-3cb8-4c04-beac-42f98e99e6a7 /boot ext4 defaults
1 2
UUID=9A2D-13D2 /boot/efi vfat umask=0077,shortname=winnt 0 2
/dev/mapper/fedora-home /home ext4 defaults 1 2
/dev/mapper/fedora-swap swap swap defaults 0 0
How complex is updating my uuids? Do you know of any easy to follow guides?
It is a simple right-click option for any unmounted partition in gparted. There are lots of other ways, but that is the one I know.
First, am I correct in understanding that while booted in the old system, you can connect the new drive by USB? It is important that all mounting of partitions on the old drive have happened before you connect the new drive.
BTW, that suddenly gives me a good theory of your basic problem: The old drive was still connected when you tried to boot the new one? That can’t work unless/until the UUIDs are fixed. But you should have been able to disconnect the old drive and use the new one without changed UUIDs, if you wanted to.
Anyway, never mount a partition (or have boot auto mount it) when another partition with a cloned UUID is physically connected. But you can boot and/or mount one without the other connected and then connect (via USB or other hot connection method).
Once hot connected with UUIDs you expect to conflict, first verify everything is as expected. I like the command: lsblk -o NAME,FSTYPE,SIZE,LABEL,FSSIZE,FSUSE%,MOUNTPOINTS,UUID
to get a clear picture of what is where.
Then use gparted to fix UUIDs, if needed. Then use the above command again to see the new UUIDs. Then mount the partitions containing the three files I mentioned earlier and fix the UUIds in those three files. Then it should be possible to boot the new system even while the old drive is physically connected.
No the old drive wasn’t still connected when I tried to boot the new one. After cloning, I took the new drive out the usb caddy and then put it into the slot in the machine, of which there is only one.
First, am I correct in understanding that while booted in the old system, you can connect the new drive by USB?
Correct. Because after the new disk failed to boot properly, I took it back out my machine and moved it back to the usb caddy and reinstalled the old disk into the machine.
I will create a live usb of gparted tomorrow and try to update the UUIDs and I’ll use your command there to get a full picture, thank you.
The live usb of gparted would only be needed if you didn’t have the USB connection for the new drive (if you needed to connect before booting).
gparted is an ordinary program that can be run in your old system and can modify any unmounted but physically connected partitions. If it isn’t installed (such as if you are using the kde spin of Fedora) then you can use sudo dnf install gparted. It is a nice utility to have. (In the old days of tiny hard drives and/or tiny ram, using the gnome version of utilities in kde wasted space. But it works perfectly and the space it wastes is trivial now.)
But since you had disconnected the old drive, I’m back to no good theory of what went wrong. If you never wanted to use both drives in the same machine after cloning, then fixing UUIDs should not be necessary.
But lacking a good theory of what went wrong, you want to take a good look at what you have. That is best done while booted in your old system, and involves changing those UUIDs and mounting the new partitions to examine from the old system. Simply changing the UUIDs (and making the corresponding fix in those three files) can’t fix the problem if the problem was NOT the presence of the old drive. But it is still a step toward understanding.
Below shows gparted running on my old disk… first I do a View Information on the fedora partition, then I flip to the new disk (currently plugged into usb) and you can see an error on the same fedora partition on the new disk, it doesn’t seem to know the file system type.
Furthermore, the “new uuid” option is disabled across the board, I assume that is the right click option you mentioned.
If it is somehow too messed up to fix, I think dd is a worse way of retrying.
In that case, I think you do want gparted in some live form. I’ve never tried the live usb of gparted. I had and was used to using the live kde spin of fedora. You can install programs while that is running. They go away on reboot, of course. But for one time use, I found installing gparted while booted in live fedora gave be an environment I was more used to.
I used the copy/paste of partitions choice in gparted to copy my partitions one at a time to my new drive, then changed their UUIDs and edited those files.
Did you run clonezilla with the source drive running or was the system off and the only thing running the clonezilla.
You should never try to clone a device that is in use since it will be in constant flux as the system is running. What is recommended when cloning from drive to drive is to boot to a bootable live clonezilla usb and use that to copy one device to the other. Neither device should be mounted or in use in any way.
It sounds as if something may have interfered with a proper completion of the clone. My suggestion would be to repeat the process from a bootable clonezilla usb and ensure the process has 100% completed before doing anything else.
Once that is done then the suggestions about the UUID are 100% mandatory if both devices are intended to be in the same machine. If not then the new device probably would have no issues if it were the only drive.
You can use almost any live media usb to boot and change the UUIDs in the files mentioned, and use gparted to change the UUID on the device from that same live media.
You can, as already noted, use gparted to copy (clone) one partition at a time from one device and paste it into another device (similar to the way you can copy and paste files). Gparted is also available as a bootable image, or you can boot live fedora media, install gparted, then work on 2 different drives while in the live environment with the source and destination devices unmounted.
As far as the UUIDs are concerned. the entries in /boot/grub2/grub.cfg, /boot/efi/EFI/fedora/grub.cfg can easily be fixed in a chroot environment while booted to live media, and the /etc/fstab entries that use UUID can be repaired the same way.
Once the drive has been cloned and you are ready to do the UUID updates to avoid the conflicts I can assist with those steps.
I guess I was wrong about gparted on your old system being usable for that.
You have demonstrated that you need gparted on something booted separately (live usb version of gparted or using it on live fedora). Sorry I misled you.
Jeff, no, the disk wasn’t “live” when I used clonezilla, I was booted from a clonezilla live usb.
The new disk is intended to fully replace the old disk, so it sounds like I can avoid the UUID issue altogether.
I’ll try another clone of the image using clonezilla to test the theory that the clone didn’t fail… If they fails again, I’ll get gparted live and copy each partition manually.
I didn’t attempt another clonezilla clone, I went straight to using dd via the Fedora 37 live USB. It worked first time, both linux and fedora partitions boot normally with no problem.
Again back on the fedora 37 live USB, I’m now trying to extend the new allocated space (1.35tTiB) to the /dev/nvme0n1p3 partition, however I can’t because there are several partitions between the unallocated space and the n1p3 partition I need to extend. Is there a way I can give n1p3 more space from unallocated without deleting all the partitions in-between? All partitions except n1p8 have the resize/move option disabled because there is no space.
Use GParted to move them to the right (end of disk) starting from the last one (now only it has sufficient unallocated space to be extended or moved). Use windows disk manager to extend n1p3 after you’ve made enough unallocated space after it.
PS ddrescue works like dd, but additionally has detailed statistics (progress, speed, ETA, etc.), can resume/retry copying and deal with errors.
That demonstrates another reason I wouldn’t clone an entire drive, but would instead clone partitions one at a time to a new drive and resize them as I go. I’m glad dd worked for you. But I still wouldn’t recommend others moving to a new larger drive do the same.
Now, you could move/resize partitions one at a time to the end of the free space that follows them (starting with n1p8 and working backward).
Or you could copy n1p3 entirely to the 1.35TiB free space and delete the original, so it no longer uses its current 317Gib. There might be bitlocker issues in that which I’m not aware of.
If I cant move the n1p3 partition (gparted wont let me) but I can copy it to the unallocated space… The screenshot below shows me copying it (I haven’t applied the change yet)… once I do, I’ll be able to extend the partition into the unallocated space. My question is, if I apply the copy in the screenshot and then delete the original n1p3 partition, I assume I need to update something else that tells my system where the partition has moved to?
I’d rather move the other partitions and the extend n1p3 from within windows - less copying, no need to deal with very probable windows booting issues, no odd free space after removing original partition.
You can only move or extend partition that has enough unallocated space right next to it, so you have to boot Fedora from live-usb (to be able to move p5 and p6), move p8, then p7, p6, p5, p4, apply changes in GParted and then boot widows to extend p3.
I’m booted onto a live usb in that screenshot above. When you say “move partition 5 and 6 and then…etc” … to move the partition, you are essentially shrinking all the unused space from each partition? Or something else? Because I don’t really see a way to move… click move/resize just gives me the partition size slider.
Something else. You are really moving them. You need to start with n1p8 (the one with lots of unallocated space directly after it).
Right click and select Resize/Move then slide it to its new position or change the numbers. If you also want a new size you can do that at the same time.
Then click the Resize/Move button to queue the operation up.
You might need to apply that operation (have it actually occur) before moving on the physically previous partition.
You are moving each into (or all the way across) the unallocated space to the right of it. So each must be done before the one to its left.
No, moving all those other partitions is more copying. But I don’t think that should be a decision factor.
Maybe there is something I’m misunderstanding about bitlocker specifically. But I think having GPT partitioning (rather than old style MBR) eliminates most concerns from having Linux move/resize Windows partitions.
That is a valid goal and reason to move n1p8 then 7 then 6 …
I’m not entirely sure. I don’t know whether that copy got the original UUID (the copy/paste I’ve done with gparted works that way). The normal way of identifying partitions in Linux is by UUID, so the fact that it is in a different place on the hard drive doesn’t matter and the fact that it is pointed to by a different entry in the GPT probably doesn’t matter to linux.
Windows more likely knows about it by which entry in the GPT points to it. Copying it such that it has the same GPT entry is different (the easiest way would be to delete it first then copy it again from the original partition on the old drive). I’m 90% sure that would reuse the gpt entry from the deleted partition.
If it does change gpt entry position, I’m not sure whether that affects Windows nor what to fix if it does.
Moving everything from n1p8 down avoids that whole issue.
