Hi,
Can anyone help me out? My first time with Rescuezilla and was able to get the clone started but it errored out quite quickly. My source is a multi partition drive that is 1TB and target is 6TB. Partitions got created but then it quit. I took a photo of the error screen since I couldn't find a place that it would save a screen shot.
There was another screen with some other progress details (not much) but I didn't capture it. I will try to run it again and capture it if it happens again.
cloning WD 1TB drive to 6TB Seagate drive
Does not mount the Seagate (I don't see it in File Explorer in windows)
disk is offline because it has a signature collision with another disk that is online
I did not touch the BIOS settings
Will add images of the disk management and other RescueZilla errors.
edit: Adding more images and description of error.
Error is kind of blurry in the image but the line with error says:
Error restoring partition /dev/sda2 to /dev/sdb2.
-I zoomed the image on my phone and reattached it as thumbnail_IMG_2201.png. I think it shows the error but not sure what to do about it.
Other stuff looks ok. I wonder if I could disconnect the old drive and see if the new one comes online to windows? Any suggestions and recommendations are very welcome. This is something I don't do very often.
Your clone failed since it says it was not able to clone the second partition /dev/sda2 -> /dev/sdb2
That partition is the key partition containing most of the data, so you'll want the clone to succeed there, for sure. That 900 gigabytes will definitely take longer than 2 minutes to successfully clone.
The error window that popped up can be scrolled down to see the exact error.
It could be that your source disk was in hibernated state and you'd need to restart into Rescuezilla with the 'Restart' option from Windows.
I would repeat the entire clone, though technically the /dev/sda2 partition is all that's required.
When you do this, you should once again be extra careful you get the source and destination correct, because when two disks are almost the same it can be confusing. Fortunately your destination disk is much large than the source so this should be easy.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Is there anything I need to do to get the source disk to be not hibernating or just do the restart from Windows? I might try this tomorrow as it is very late. I have been messing around with Disk Management but I get stuck manually copying some old files, possibly corrupted programs.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
But it's not immediately clear that the hibernated disk is the root cause. What's interesting in the truncated screenshot is it cloned 1% of the drive with 2 minutes elapsed. Usually when the partition is hibernated it would fail a bit faster than that.
Ideally if that error occurs again you can scroll down further to see the exact issue. It's possible that this partition eg, needs a file system check before partclone will want to clone it.
It's worth trying a clean clone without any changes though. Particularly since it failed in a minute or two so is not a big time burden to try.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Not getting much joy here ... I ran a chkdisk and also DISM and SFC scan before once again trying to clone with RescueZilla. Same failure on sda2 -> sdb2. I captured a shot of the error, indicating a warning ; The disk has bad sectors. This is even after doing the chkdsk showed no errors. Am I scuppered and need to do a clean reinstall? Note, my system is on a SSD, the sda2 is a storage HDD that is being replaced by a much larger one, so the sda2 HDD will be decommissioned when all is said and done.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Definitely no need to do a clean reinstall on your destination disk at this stage, your clone should work.
I recommend trying to tick 'Rescue' mode checkbox? I forgot to mention that earlier. That will do basic skipping over any bad sectors and will most likely solve your issue.
If that fails (I don't think it will), you could also use the ddrescue application from a terminal to make the clone and it will intelligently skip over and retry bad blocks in a way that's much more robust than partclone is now. Eg, open a terminal and run ddrescue /dev/sda /dev/sdb (you'll need to add a force option or it will block you from making the clone from sda to sdb).
It doesn't make a difference for SSD and HDD everything is handled identically. The only requirement is the destination is larger than the source (which is is in your case).
Once your clone is finished, sanity check by rebooting into the destination disk (I generally recommend disconnecting the source disk when trying this). If it works, you'll need to reboot into eg, Rescuezilla and use the GParted Partition Editor to ensure all the disk space on your destination disk is utilized.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That 'rescue' mode did help quite a bit and it looks like it copied all the partitions. Thanks for that tip! Here's the summary notes when it finished:
Failed to run command: ntfsfix --clear-dirty /dev/sdb2
Mounting volume... FAILED
Attempting to correct errors...
Processing $MFT and $MFTMirr..!
Reading $MFT... OK
Reading $MFTMim... OK
Comparing $MFTMir to $MFT... OK
Processing of $MFT and $MFTMir completed successfully
Setting required flags on partition.... oK
Going to empty the journal ($LogFile)... OK
Windows is hibemated, refused to mount.
Windows is hibernated, refused to mount.
Remount failed: Operation not permitted
No changes needed for NTFS filesystem geometry of /dev/sdb2
Successfully restored image partition /dev/sda3 to /dev/sdb3
No changes needed for NTFS filesystem geometry of /dev/sdb3
Did not update GRUB bootloader (if any)
Are there any concerns from those failed mounts? After I rebooted, still with both disk installed, I looks OK in Disk Management in Windows, only still need to make some changes to the partitions to get access to the full drive. Any tips for that? I will attach an image of the layout, showing both disks.
The failure of running ntfsfix --clear-dirty /dev/sdb2 was caused by the cloned disk being in hibernated state ("Windows is hibernated, refused to mount"), which itself was caused by the source disk being in hiberated state (which is not ideal for the clone). This is command does an NTFS filesystem consistency fix to request it undergo a filesystem check on next boot.
I recommend disconnecting your source disk, and booting the destination disk and confirming Windows boots correctly. It may do a filesytem check on first boot. Since this was a suboptimal clone of a hibernated disk with known-errors, I would out of conservatism, actually do a second restart into your destination disk and confirm everything is 100% healthy without any Windows filesystem check the second time around.
After this, (as mentioned in a previous message) boot back into Rescuezilla and use GParted Partition Editor to move the final recovery partition to the end of the disk and grow the middle NTFS partition to utilize all the disk space. Then click 'Apply' and like 20 minutes later it should be all successful.
Then boot back into the destination disk and everything should be ready for you.
(A future version of Rescuezilla will do this manual GParted step for you, but right now it's a manual step)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
By the way, once your clone is successful and you've confirmed you can boot into the destination, you will need to reboot into Rescuezilla and open GParted Partition Editor to shift the final partition to the end and expand the main partition. (you can do this from Windows Disk Manager too, from your original disk).
Rescuezilla won't be able to automatically resize this particular disk's partitioning because the main partition isn't the final partition.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I booted successfully with my source drive removed. Note I have Windows on my SDD, not the HDD that has been removed after it was cloned. I could not move the recovery partition with Gparted. I tried to drag it with the tool but got an error saying it could not move it beyond the end of the device (or something to that effect). I tried also to move it just shy of the end and it seemed to be working but then aborted as it could not roll back. Sorry not sure about the exact message - I tried to save it to the desktop but I don't see it when I boot to windows. Where would I see the message? Would I need to launch firefox on the Rescuzilla to save it somewhere else? Anyway, I did boot successfully after removing the old HDD - just need to fix the partition to use the entire disk. I think there is a way to do it within Windows but if you know what my issue is from my description or how to fix the GParted error, I can try whichever is easier. Again, thanks for all your help.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
On looking more closely at your earlier screenshot, I think I know what's happening:
I think your source disk does NOT use modern GPT partitioning but rather uses legacy MBR partitioning. Because MBR has a maximum disk size support of 2TB, and I can see the "extended partition" envelope has expanded to this point on that screenshot, and this aligns with the 'end of device' error you suggest.
This would suggest you additionally need to use the official Windows tool MBR2GPT (https://learn.microsoft.com/en-us/windows/deployment/mbr-to-gpt) to convert the MBR partitioning to GPT, and Microsoft recommends doing this from a Windows environment.
For you this may mean booting into the source disk. I assume the tool won't get confused with the clone disk and will correctly process things. But I've never used Microsoft's MBR2GPT.
Sorry for the user-experience oversight here. This is a great case for restore and cloning that the current version of Rescuezilla v2.6.1 does not warn about (there is no reason it shouldn't), and doesn't automatically handle as the default behavior (since it theoretically could I think it should).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
Can anyone help me out? My first time with Rescuezilla and was able to get the clone started but it errored out quite quickly. My source is a multi partition drive that is 1TB and target is 6TB. Partitions got created but then it quit. I took a photo of the error screen since I couldn't find a place that it would save a screen shot.
There was another screen with some other progress details (not much) but I didn't capture it. I will try to run it again and capture it if it happens again.
edit: Adding more images and description of error.
Thanks.
Last edit: Larry Wright 2025-08-08
Error is kind of blurry in the image but the line with error says:
Error restoring partition /dev/sda2 to /dev/sdb2.
-I zoomed the image on my phone and reattached it as thumbnail_IMG_2201.png. I think it shows the error but not sure what to do about it.
Other stuff looks ok. I wonder if I could disconnect the old drive and see if the new one comes online to windows? Any suggestions and recommendations are very welcome. This is something I don't do very often.
Thanks.
In case this helps, here's a screenshot of the Disk Manager from Windows, attached.
Your clone failed since it says it was not able to clone the second partition /dev/sda2 -> /dev/sdb2
That partition is the key partition containing most of the data, so you'll want the clone to succeed there, for sure. That 900 gigabytes will definitely take longer than 2 minutes to successfully clone.
The error window that popped up can be scrolled down to see the exact error.
It could be that your source disk was in hibernated state and you'd need to restart into Rescuezilla with the 'Restart' option from Windows.
I would repeat the entire clone, though technically the /dev/sda2 partition is all that's required.
When you do this, you should once again be extra careful you get the source and destination correct, because when two disks are almost the same it can be confusing. Fortunately your destination disk is much large than the source so this should be easy.
Is there anything I need to do to get the source disk to be not hibernating or just do the restart from Windows? I might try this tomorrow as it is very late. I have been messing around with Disk Management but I get stuck manually copying some old files, possibly corrupted programs.
From Windows you can use
powercfg.exe /hibernate off
from an Admin command prompt (from https://learn.microsoft.com/en-us/troubleshoot/windows-client/setup-upgrade-and-drivers/disable-and-re-enable-hibernation)But it's not immediately clear that the hibernated disk is the root cause. What's interesting in the truncated screenshot is it cloned 1% of the drive with 2 minutes elapsed. Usually when the partition is hibernated it would fail a bit faster than that.
Ideally if that error occurs again you can scroll down further to see the exact issue. It's possible that this partition eg, needs a file system check before
partclone
will want to clone it.It's worth trying a clean clone without any changes though. Particularly since it failed in a minute or two so is not a big time burden to try.
Not getting much joy here ... I ran a chkdisk and also DISM and SFC scan before once again trying to clone with RescueZilla. Same failure on sda2 -> sdb2. I captured a shot of the error, indicating a warning ; The disk has bad sectors. This is even after doing the chkdsk showed no errors. Am I scuppered and need to do a clean reinstall? Note, my system is on a SSD, the sda2 is a storage HDD that is being replaced by a much larger one, so the sda2 HDD will be decommissioned when all is said and done.
Definitely no need to do a clean reinstall on your destination disk at this stage, your clone should work.
I recommend trying to tick 'Rescue' mode checkbox? I forgot to mention that earlier. That will do basic skipping over any bad sectors and will most likely solve your issue.
If that fails (I don't think it will), you could also use the
ddrescue
application from a terminal to make the clone and it will intelligently skip over and retry bad blocks in a way that's much more robust thanpartclone
is now. Eg, open a terminal and runddrescue /dev/sda /dev/sdb
(you'll need to add a force option or it will block you from making the clone from sda to sdb).It doesn't make a difference for SSD and HDD everything is handled identically. The only requirement is the destination is larger than the source (which is is in your case).
Once your clone is finished, sanity check by rebooting into the destination disk (I generally recommend disconnecting the source disk when trying this). If it works, you'll need to reboot into eg, Rescuezilla and use the GParted Partition Editor to ensure all the disk space on your destination disk is utilized.
That 'rescue' mode did help quite a bit and it looks like it copied all the partitions. Thanks for that tip! Here's the summary notes when it finished:
Failed to run command: ntfsfix --clear-dirty /dev/sdb2
Mounting volume... FAILED
Attempting to correct errors...
Processing $MFT and $MFTMirr..!
Reading $MFT... OK
Reading $MFTMim... OK
Comparing $MFTMir to $MFT... OK
Processing of $MFT and $MFTMir completed successfully
Setting required flags on partition.... oK
Going to empty the journal ($LogFile)... OK
Windows is hibemated, refused to mount.
Windows is hibernated, refused to mount.
Remount failed: Operation not permitted
No changes needed for NTFS filesystem geometry of /dev/sdb2
Successfully restored image partition /dev/sda3 to /dev/sdb3
No changes needed for NTFS filesystem geometry of /dev/sdb3
Did not update GRUB bootloader (if any)
Are there any concerns from those failed mounts? After I rebooted, still with both disk installed, I looks OK in Disk Management in Windows, only still need to make some changes to the partitions to get access to the full drive. Any tips for that? I will attach an image of the layout, showing both disks.
Thanks so much for your help so far!
The failure of running
ntfsfix --clear-dirty /dev/sdb2
was caused by the cloned disk being in hibernated state ("Windows is hibernated, refused to mount"), which itself was caused by the source disk being in hiberated state (which is not ideal for the clone). This is command does an NTFS filesystem consistency fix to request it undergo a filesystem check on next boot.I recommend disconnecting your source disk, and booting the destination disk and confirming Windows boots correctly. It may do a filesytem check on first boot. Since this was a suboptimal clone of a hibernated disk with known-errors, I would out of conservatism, actually do a second restart into your destination disk and confirm everything is 100% healthy without any Windows filesystem check the second time around.
After this, (as mentioned in a previous message) boot back into Rescuezilla and use GParted Partition Editor to move the final recovery partition to the end of the disk and grow the middle NTFS partition to utilize all the disk space. Then click 'Apply' and like 20 minutes later it should be all successful.
Then boot back into the destination disk and everything should be ready for you.
(A future version of Rescuezilla will do this manual GParted step for you, but right now it's a manual step)
By the way, once your clone is successful and you've confirmed you can boot into the destination, you will need to reboot into Rescuezilla and open GParted Partition Editor to shift the final partition to the end and expand the main partition. (you can do this from Windows Disk Manager too, from your original disk).
Rescuezilla won't be able to automatically resize this particular disk's partitioning because the main partition isn't the final partition.
Thanks for the replies. Hopefully I can get a clean clone tomorrow.
I booted successfully with my source drive removed. Note I have Windows on my SDD, not the HDD that has been removed after it was cloned. I could not move the recovery partition with Gparted. I tried to drag it with the tool but got an error saying it could not move it beyond the end of the device (or something to that effect). I tried also to move it just shy of the end and it seemed to be working but then aborted as it could not roll back. Sorry not sure about the exact message - I tried to save it to the desktop but I don't see it when I boot to windows. Where would I see the message? Would I need to launch firefox on the Rescuzilla to save it somewhere else? Anyway, I did boot successfully after removing the old HDD - just need to fix the partition to use the entire disk. I think there is a way to do it within Windows but if you know what my issue is from my description or how to fix the GParted error, I can try whichever is easier. Again, thanks for all your help.
On looking more closely at your earlier screenshot, I think I know what's happening:
I think your source disk does NOT use modern GPT partitioning but rather uses legacy MBR partitioning. Because MBR has a maximum disk size support of 2TB, and I can see the "extended partition" envelope has expanded to this point on that screenshot, and this aligns with the 'end of device' error you suggest.
This would suggest you additionally need to use the official Windows tool MBR2GPT (https://learn.microsoft.com/en-us/windows/deployment/mbr-to-gpt) to convert the MBR partitioning to GPT, and Microsoft recommends doing this from a Windows environment.
For you this may mean booting into the source disk. I assume the tool won't get confused with the clone disk and will correctly process things. But I've never used Microsoft's MBR2GPT.
Sorry for the user-experience oversight here. This is a great case for restore and cloning that the current version of Rescuezilla v2.6.1 does not warn about (there is no reason it shouldn't), and doesn't automatically handle as the default behavior (since it theoretically could I think it should).