Clonezilla fails to clone a hard disk to a smaller hard disk with parameter...
A partition and disk imaging/cloning program
Brought to you by:
steven_shiau
Menu
▾
▴
#342 Clonezilla fails to clone a hard disk to a smaller hard disk with parameter -ICDS because sfdisk's last_lba
I am using Clonezilla to clone big HDDs into smaller SSDs in laptops as most users don't use most of the space of their 1TB HDDs and can be cloned easily into SSDs with just one change in Clonezilla.
Let's imagine this scenario:
· Origin: 1 TB HDD with just a 900GB NTFS partition using only 100GB.
· Target: 256 GB SSD, empty
This is the process I would follow:
· Clear all caches and temporary data.
· Shrink the partition to something that will fit before the target disk's last sector (like 150GB), taking in account any offset since the disk's beginning.
· Run Clonezilla Live: disk to disk, expert, origin disk, target disk, parameter ICDS (to ignore if the target disk is smaller than the origin disk), copy the partition table from the origin disk to the target disk, run.
After a few seconds, it fails saying that gfdisk can't apply the dumped partition table because "LastLBA" of the original disk is in a sector after the end of the target disk.
My solution:
· I create an empty partition table in the target disk
· I dump the target disk's partition table with gfdisk and I write down its LastLBA parameter
· Then I dump the origin disk's partition table with gfdisk and change its LastLBA parameter to match the one in the origin disk
· I apply that fixed dump partition table to the target disk
· Then I run Clonezilla and repeat every step, except for the partition table management, which I configure to "Do not create a partition table"
I have applied this solution a lot of times already and it works flawlessly.
It would be amazing if it was actually done by Clonezilla itself: just changing the LastLBA parameter to the partition table dump does the trick! :)
Thank you for your attention, and please excuse my probably bad grammar 😅
Some more info:
· This problem only occurs when cloning a GPT disk
Even more! A simple grep will solve it as sfdisk actually detects last-lba automatically :D
Just change this line:
ocs-onthefly:1208: [ -f "$src_pt_tmp" ] && cp -f $src_pt_tmp $tgt_pt_tmp
To this:
ocs-onthefly:1208: [ -f "$src_pt_tmp" ] && grep -v last-lba $src_pt_tmp > $tgt_pt_tmp
It works in my test machine, but I don't know if it actually breaks something.
I will be testing it in the next few days :)
Thank you for sharing this. Please keep us posted, and we will also test it. If it works well, we will use that in the future release.
Steven
It seems I can not make it work. If I apply your patch, then clone a 64 GB to 21 GB disk, using ocs-onthelfy like this:
/usr/sbin/ocs-onthefly -icds -g auto -e1 auto -e2 -j2 -r -nogui -sfsck -icds -pa choose -f sda -t sdb
Then it failed:
Error: /dev/sdb: unrecognised disk label
Running sfdisk --force /dev/sdb < /tmp/ocs_onthefly_local.3ZfrX1/tgt-pt.sf
Partition #1 contains a vfat signature.Checking that no-one is using this disk right now ... OK
Disk /dev/sdb: 20 GiB, 21474836480 bytes, 41943040 sectors
Disk model: VMware Virtual S
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
The last usable GPT sector is 41943006, but 125829086 is requested./dev/sdb2: Created a new partition 2 of type 'Linux filesys
tem' and of size 10.3 GiB.
/dev/sdb3: Created a new partition 3 of type 'Linux filesystem' and of size 7.2 GiB.
/dev/sdb4:
Failed to add #4 partition: Invalid argument
Leaving.
What are your source and destination disk sizes?
Thanks.
Steven
Hi Steven!
Thank you for your testing it. Could you send a sfdisk dump?
I think your 4th partition has its last sector after the 20GB in the original disk.
My solution does not solve the partition positions. If a partition has its last sector after the end of the target disk, it won't work, but it will help if your original partitions don't go past the target's disk last sector.
Thanks again!
Regards,
Pablo
Yes, definitely. Hence that's why I was asking what were the sizes for source and destination disks you have tried there.
Steven
Well, the last time I did it, it was a 1TB HDD to a 240GB SSD.
It had a NTFS partition with just 80GB used, so I shrinked the partition and then used this method.
I just tried again with the latest testing build and applying my little patch, and it worked for me perfectly. I used 2 disks: one of 64GB and one of 20GB.
I created a 18GB NTFS partition in the 64GB disk and then I cloned it to the 20GB disk with -icds and just copying the partition table (MBR). It worked as expected.
Then I repeated the operation but with GPT and it also went well.
It just needs to have the origin disk last partition's last sector a little before the end of the target disk :) Without my patch, sfdisk would stop me from doing it.
Thanks. I did another test, the source disk was 64 GB with 4 partitions, while the destination disk was 54 GB:
root@debian:~# parted -s /dev/sdb print
Model: VMware, VMware Virtual S (scsi)
Disk /dev/sdb: 64.4GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
1 1049kB 524MB 523MB ntfs Basic data partition hidden, diag
2 524MB 628MB 104MB fat32 EFI system partition boot, esp
3 628MB 645MB 16.8MB Microsoft reserved partition msftres
4 645MB 64.4GB 63.8GB ntfs Basic data partition msftdata
root@debian:~# parted -s /dev/sdd print
Model: VMware, VMware Virtual S (scsi)
Disk /dev/sdd: 53.7GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
1 1049kB 524MB 523MB ntfs Basic data partition diag
2 524MB 628MB 104MB fat32 EFI system partition boot, esp
3 628MB 645MB 16.8MB Microsoft reserved partition msftres
4 645MB 53.7GB 53.0GB ntfs Basic data partition msftdata
Without the -k1 option, as -icds was enabled, even the patch was applied, it failed:
The last usable GPT sector is 104857566, but 125827071 is requested.
Failed to add #4 partition: Invalid argument
Checking that no-one is using this disk right now ... OK
Disk /dev/sdd: 50 GiB, 53687091200 bytes, 104857600 sectors
Disk model: VMware Virtual S
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Since this patch only works for larger disk to smaller one, while the option -k1 works for larger to smaller one, or smaller one to larger one, and from my test, it failed in the source disk has more than one partition. Hence we won't apply it in the future release. The option "-k1" should cover the case you have provided.
Still thank you very much for sharing this, appreciate.
Steven
Hi again Steven.
I just tried the -k1 option, but it doesn't solve this case, at least when cloning NTFS partitions.
I have a 64GB disk with a 20GB NTFS partition.
If I try to clone it to a 21GB disk with -k1, Clonezilla creates a 6GB partition in the partition table, instead of 21GB, and outputs this message while cloning the partition:
"target seek ERROR:Invalid argument"
If my suggestion doesn't make any harm to other cases, it could be useful in cases like this one.
We just used it again today :)
Thank you in advance for considering.
Pablo
Your case is not to have a proportional partiton size on the destination. I believe it only works for 1 partition and its partition size is within the destination disk size. In that case, if we want, maybe we could have an option like -k3 for this purpose. However, actually you can do that by choosing the option -k2, then enter command line to use fdisk to create a partition then continue to clone that for the moment. I will think about if we really want to have an option -k3...
Thanks.
Steven
I think it may just fit in the -icds option, as it just removes the size of the origin disk in the partition table dump so it can be applied in a smaller target disk :)
Got it. If there is no side effect, of couse we can just use taht in -icds. More tests maybe be required. Have you tried that in most of the scenarios?
Thanks.
Steven
No, I have only tried to clone a disk bigger than the target disk.
Please tell me any other cases you may think of, so I will be able to test them.
Still, afaik, that line just removes a second hard disk size comparison check that sfdisk realizes when importing a dump from another disk (the first check is the one that currently -icds skips), so in theory it should be safe :)
OK, I think we can give it a try. Will try to implement that in the future release.
Thank you very much.
Steven
Your patch has been applied.
Please give Clonezilla live >= 2.6.6-15 or 20200428-* a try:
https://clonezilla.org/downloads.php
It should work for disk cloning and image restoring.
Please let us know the results. Thanks.
Steven
Same error here!
None of versions Clonezilla live >= 2.6.6-15 or 20200428-* work
@panreyes can you give me the instructions in command line for the steps you use to copy the partition tables and more, I'm noobie into that, Thanks in advance!
OK I got it.
I'm writting it down for anybody in need:
· Create an empty partition table in the target disk
-> I just created an empty partition within the OS. In my case Windows 10, just using the Disk Management. After this I reboot the PC booting with Clonezilla and getting in command line.
· Dump the target disk's partition table with gfdisk and I write down its LastLBA parameter
-> sfdisk -d /dev/sdb
· Dump the origin disk's partition table with gfdisk and change its LastLBA parameter to match the one in the origin disk
-> sfdisk -d /dev/sda > tempTable
-> nano tempTable
· Apply that fixed dump partition table to the target disk
-> skdisk /dev/sdb < tempTable
· Then run Clonezilla and repeat every step, except for the partition table management, configuring to "Do not create a partition table"
Hi Nicolas!
Did you try to do that in expert mode with the -ICDS parameter?
It should solve that for you :)
Hi. Of course I tried -ICDS parameter, it is supposed to include the real lastLBA for the destination disk. I tried it with - k1 option in partitioning dimensions.
My origin disk was the OS disk with 4 partitions, I was upgrading my laptop from the 1TB HDD to a 500GB SSD M.2 PCIe.
I shruk the origin disk main partition in order to make the whole 4 partitions Lower than 500GB together. After many tries I just followed the instructions to force the partition table with LastLBA and that did the trick.
I don't have right now a set of disk to make further test, sorry.
However, thanks To the Clonezilla team because this is an Open Source Tool worth the time to use and learn
Well then, I don't know why did you need to do that, as the -ICDS parameter removes the optional LastLBA parameter, which actually was used by sfdisk to confirm that the target disk is as long as the disk.
Hi, can you please fix-automate this feature please as I lost a day and clonezilla -ICDS k1 or k does not work AT ALL? Should I open a feature request to add this CRITICAL functionality of cloning large (hdd) to small (ssd)?
The solution (using gparted live disk) is to shrink the source (sda) disk partitions to the size of the target (sdb) disk with gparted (manually) so at the end of the source disk we have only free space and run
dd if=/dev/sda of=/dev/sdb bs=1M status=progress. When dd finishes one gets an error, that is fine. Next rungdisk /dev/sdbto fix the target partitions GPT table with commandsvandpand save results withw. Partition your target disk or/and reboot - everything works! https://www.tigraine.at/2014/01/04/how-to-upgrade-to-an-ssd-with-minimal-effortSure.
You can also refer to this:
https://drbl.org/faq/fine-print.php?path=./2_System/119_larger_to_smaller_disk_restore_clone.faq#119_larger_to_smaller_disk_restore_clone.faq
Method 2 is recommended.
Steven
As I understand both methods are the same but method 2 uses no parameters as method 1 uses k1 after the source disks data is shrinked to fit destination disk. Next time I'll try method 2 - unfortunately could not find it before.