I have a image which was taken with Clonezilla as SAVEDISK on a 160GB harddrive.
Now a newer version of the PC released with a 120GB harddrive, the space in use is just 20GB

Is there a way I can force Clonezilla (or any other program) to manipulate the images 'original size' to 120GB or lower, so Clonezilla can write it to the new PC?

  • I don't know how clonezilla works, but if there are only 20GB of data, what is the exact problem you encounter?
    – Michael K
    Sep 7, 2011 at 10:42
  • 1
    Since the image was taken of a 160GB disk, it includes a 160GB partition table, which won't allow me to override it.
    – Sander
    Sep 8, 2011 at 5:56
  • Is there no way to 'open' the image and copy the data away?
    – Michael K
    Sep 8, 2011 at 6:43
  • I have various .aa .ab .ac files (sda1.ntfs-ptcl-img.gz.aa till sda1.ntfs-ptcl-img.gz.ae) seeming this is the image of the harddisk, I think I can un-aa it into one .img.gz file, but then I need a way to write it back.
    – Sander
    Sep 8, 2011 at 6:58

7 Answers 7


Clonezilla relies on Partclone to save and restore filesystems. Although it's useful, even if you use the -icds option, that alone isn't enough. When restoring the original filesystem on the smaller disk, Partclone will encounter a seek error trying to write beyond the disk boundary. So this is a limitation of not only Clonezilla, but the underlying tools it uses.

What you can do however, is to restore the image temporarily on a 160GB disk, use a filesystem resize tool such as ntfsresize (for NTFS) or resize2fs (for ext3/4) to shrink the filesystem, say to 25GB. Resizing the partition table, which GParted does, isn't necessary. Use Clonezilla again to create a new image using the "savedisk" option.

When restoring the image on the smaller disk, use the -icds option to skip Clonezilla checking if the disk is the same or larger than the original disk. Since you shrunk the filesystem, Partclone won't encounter a seek error and your data will be restored on your smaller disk.

If you used the option to restore the partition table proportionally (-k1), Clonezilla will create a proper partition table and resize (expand) the original filesystem so that all the free space on the new disk becomes available.

EDIT: The -icds option isn't passed to ocs-expand-mbr-pt, so this step currently fails. A bug report has been filed about this with the project. The bug has been fixed.

  • 2
    I've a question about the bug mentioned in the EDIT paragrah: Which versions of clonezilla and partclone were effected by this bug?
    – pefu
    Dec 10, 2015 at 8:26
  • To add the -icds flag to a recovery zip file created with the "recovery-iso-zip" option (clonezilla.org/clonezilla-live/doc/…), open up /boot/grub/grub.cf in the zip file and add it to ocs_live_extra_param="" for each boot option. (I inserted it between -scr and -p.)
    – EchoLynx
    May 24, 2022 at 16:27

Restore the image to a 160GB or larger harddrive ... could be virtual.
Boot that machine with PartedMagic Live CD.
Resize down the partition with parted.

Put drive in as a secondary drive in windows or Linux,
and resize using parted, gparted, or windows disk manager.

  • I think that this is the easiest way to do it.
    – Sekhemty
    May 8, 2013 at 20:43
  • 1
    Moreover, a virtual drive can be put on compressed underlying storage so you don't actually need a 160GB or larger drive, only enough to hold the compressed data (~20GB or so?)
    – qasdfdsaq
    Jul 6, 2015 at 13:31

I solved it with a Windows 10 image as follows

  1. Temporarly move some files if your source drive is nearly full.
  2. A drefragmented drive leaves more space for shrinking, so defrag c:\ through right clicking on the drive -> tools
  3. shrink c:\ through windows disk management as small as possible
  4. start Clonezilla, expert, device-device, local, select -icds and finally the -k1 option
  5. switch off and disconnect old drive
  6. restart with the new drive and hold shift on windows login, select restart -> troubleshooting -> startup repair

In the past the 4th step failed, but since 2015 clonezilla supports GPT with the -k1 option so I think this is the reason why this works, now:

Clonezilla live 2.4.2-38 ... Proportition GPT partition layout could be created by the option -k1.

The 6th step is needed because Windows does not recognize the boot drive in the optimization tool (SSD trim) and will try to repair the drive randomly so something seems to be wrong in the boot sector/partition table but startup repair will fix it.

EDIT: I uploaded a video of the the complete process (German):


If the space is not in use, go into expert mode and enable -icds then restore the image. It will skip the partition size check and will succesfully restore it (only if < 120 GB is in use).


My situation:

  • Clonezilla image (of Windows 7) based on 128GB drive (100MB system partition + 117GB "C"),
  • new 120GB drive.

Following suggestions (like https://superuser.com/a/592283/229908) did not solve the problem for me.

What worked for me was:

  1. restore the image to another (larger) drive,
  2. defragment that drive (because it seems Clonezilla restores the data as was structured on the original drive, so possibly there won't be enough free space to shrink the partition to target size),
  3. shrink the partition (in my case, the 117GB "C") to the size of the target drive/partition (in my case 111GB) or, more safely, to a smaller size,
  4. install Windows 7 on the target drive (and have it create its system partition by using advanced options),
  5. use Clonezilla to restore each partition (with restorepart command) from the resized drive to the corresponding partition on the target drive.

The main trick why this worked was creating partition table (in my case done automatically by installing the Windows) that corresponds to the target drive, then just copying contents (via restorepart) which wouldn't touch the partitions configuration. So, even if the source partition that is being restored was smaller than the target, as partition table is not touched by restorepart, there is no need to "extend" the target partition after the operation.


In my case -icds alone has not solved the problem. I don't know if the problem is exactly the same as mine. But I left here my cent.

I have tried a disc to disc clone from a 930GiB HDD (source drive) with a GPT partition table to 890GiB SSD (destination). Please note I am a Linux user and I have a dual boot with windows 10. I have tried to left unchanged all the partitions and to reduce slightly the size of my data partition only.

  1. With gparted, I resized the bigger data partition in order to have an overall size that fits the destination SSD, and moved all free space at the end
  2. I used clonezilla-Live from USB pen, with advanced mode and -icds enabled.

It failed. It looks like Clonezilla fails, at start, to clone the partition table to the destination disk because it wrongly uses sfdisk utility that is for older partition types instead of sgdisk utils. My solution:

  1. The same as previous (overall size must fit)
  2. I manually copied the partition from one drive to another, using Clonezilla shell with this command (only for GPT partitions!):

    sgdisk /dev/sdSourceDeviceName -R /dev/sdDestinationDeviceName

  3. Performed Clonezilla disc-to-disc clone, selecting the option -icds and the option to NOT CREATE a partition table on destination disk, option -k. (In this case Clonezilla uses the destination partitions as they are, and resizes partitions when sizes are smaller, in order to fit, it perform a good "best effort").

It worked. I obtained all the partitions the same size as source (Yes I only reduced the bigger partition a bit). Dual boot with windows keeps working well. Regards


this one helped me:

expert mode => disc to disc => etc. => enable -iscd => then: use the partition table from the source disk

create the partition table proportinally (-k1) worked for me on three UEFI GPT computer 1 tb hdd's to ssd's clones. i think clonezilla ignored -k1 there.

on one very old computer with MBR, 512 gb hdd, max 4 gb ram, 64-bit but more junk than useable pc newest windows 10 (20H1) i had to choose -k and not -k1 although i shrunked the hdd partitions to hell and -k1 never worked.

the ssd's had 120 gb.

i think it's the same for uefi gpt that i could use -k there too instead of -k1

i use gpt everywhere i can even for drives lower than 2 tb. gpt is future.

clonezilla told me something with calcuated size of is < 0 ! and the ratio target size to original disk size.

never forget: a shrunken device shrunked with gparted has to get force fsck'd or chkdsk'd by windows 10

enter image description here


click on scan and repair drive (must be FORCED) and then something like restart now. wait until chkdsk became 100 % needs 2 restarts then until windows 10 is usable again, go back to clonezilla.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .