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 😅
Similar problem here, still in 2022 on "CloneZilla stable - 2.8.1-12". Situation:
sda: Inside laptop: 2.5 inch Samsung SSD 256 GB with 2x ext4 primary partition.
sdd: Attached to usb: 2.5 inch Crucial SSD 240 GB cleanly wiped without partitions.
Goal: clone sda to sdd. Pretty simple right?
No. Even in expert modus, with or without -r -k -icds -k1 -k2,... manually creating partitions during clone. Everything always crashes with a "target seek error" at 90+% during clone of the second partition. The 2-step approach: disk-to-image then later image-to-disk fails similarly. I eventually fixed it with a manual
rsync -ah samsung-part2/ crucial-part2/And manually setting the blkid with tune2fs. CloneZilla's
ocs-install-grub "sdd1 sdd2" autowas useful.Last edit: Matt Eljay 2022-01-21
OK, great. Thanks for sharing this.
BTW, did you try the method 2, as mentioned here?
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
Steven
Hello,
I really could use help with this - the -icds -k1 option worked when my image was MBR (Legacy) but now that its GPT (UEFI) it fails restoring image to 64GB SSD and image was cloned from 128 GB SSD.
It fails like your logs showed-- shows creating the last partition @steven_shiau ---
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.
I dont know how to use gparted - would I have to make a new image or can I modify the captured image I have on a stick with it?
Can anyone make a real guide for a plebian to follow to do this?
You link to the clonezilla help page but this part doesn't make sense to me.
First use GParted live to resize and move the partitions in the source disk, and make all partitions to be equal to or smaller than the size of that in the destination disk. You have to make sure the boundary of last partition in the source disk is within the limit of destination disk.
How do I use gparted to resize like what exactly are the steps?
Do I have to do this on my live computer then once complete recapture the image from scratch?
There's very little in information for someone that isn't familiar with linux / gparted to complete this setup...
Please help,
I suggest you find someone who is familiar with GNU/Linux to help you.
Actually there are some docs on https://gparted.org which you can read. Just backup important data before you use GParted and Clonezilla.
Steven
Has this issue with creating an image from a larger source HDD which contains data that would easily fit on a smaller HDD been resolved?
(This has been a long-running issue many wished a solution for.)
Is this method restricted to creating an image of a partition on a larger source HDD which partition is smaller than the target HDD?
(Guess it makes a difference how I ask the question.)
I assume in creating the image, that Clonezilla can't tell what's data and what's empty space and just goes after partitions or whole disks only and doesn't involve itself with data?
In that case shrinking the partition containing data on the source drive (so the source partition size is smaller than target drive's size) is a necessary first step before creating the image.
That's easily done with partition tools, just not sure if Clonezilla has that ability built into it.
Thanks!
Well, that's the limitation for Clonezilla, due to the mechanism of file system imaging. It is not "file" based, as described in the FAQ:
https://drbl.org/fine-print.php?path=./faq/2_System/25_restore_larger_disk_to_smaller_one.faq#25_restore_larger_disk_to_smaller_one.faq
https://drbl.org/fine-print.php?path=./faq/2_System/119_larger_to_smaller_disk_restore_clone.faq#119_larger_to_smaller_disk_restore_clone.faq
Steven
Hello Steve,
It appeared the issue was fixed so that the solution panreyes found is
easier to implement?
It almost sounded like you made a change to the code almost 3 years ago
near the end of April, see below.
If that piece is noted in the app and guides you through the process
that would be very welcome.
I assume the prerequisite is shrinking the source partition to be below
the size of the target drive before taking the image. Then when
restoring to use -icds only and -k1 is not needed.
Steve Sybesma
====================
Clonezilla live 20200428-focal
is based on the Ubuntu Focal repository (as of 2020/Apr/28).
* Neglect the line "last-lba:..." for the GPT partition table. This
allows something like: 64 GB disk with a 20 GB NTFS partition, disk
clone to >= 20 GB disk. This is harmless when same sizes of disk cloning
or smaller to larger case. The option -icds is required when larger disk
is cloned/restored to smaller one, no need to use -k1 in this case.
Thanks to panreyes for this idea. Ref:
https://sourceforge.net/p/clonezilla/bugs/342/
-- Steven Shiau <steven at="" stevenshiau="" org=""> Wed, 29 Apr 2020 13:36:00
+0800</steven>
====================
On 2023-03-08 05:29, Steven Shiau wrote:
Links:
[1] https://sourceforge.net/p/clonezilla/bugs/342/
Related
Bugs: #342
"I assume the prerequisite is shrinking the source partition to be below
the size of the target drive before taking the image. Then when
restoring to use -icds only and -k1 is not needed." -> Yes, basically it is. However, this is not an ideal solution, I can say it's just a workaround.
Steven
Work around is good.
To implement that in Clonezilla with all the extra steps is probably
beyond the purpose of the program.
Just knowing it can be done is a big deal.
I think some clear instructions should be included, though.
Steve
Last edit: Steven Shiau 2023-03-12