#363 Last partition takes trailing free space on cloning to larger drive

[Andris Pavenis]

Cloned SSD to larder SSD with extending partitions: GPT, Windows 10 Pro + some other partitions (EFI boot, Linux /boot and some other Linux non root partitions). Boot partition was the last one. There was unpartioned space at end of source drive.

Result: last partition (ext4) was expanded after cloning to all available space up to very end which resulted of boot partition of size of many GB.

The problem is however not-critical as it can be easily and quickly fixed with gparted after unmounting it.

System information:
- Arch Linux, clonezilla 3.35.2-3 (https://archlinux.org/packages/community/any/clonezilla/)
- it was possible to unmount used partions on source drive and run clonezilla without need to reboot from USB (or some other media)

[Steven Shiau]

You can enter expert mode, then check "-k1" option:
https://clonezilla.org/clonezilla-live/doc/02_Restore_disk_image/advanced/09-advanced-param.php

Steven

[Andris Pavenis]

I used expert mode and option -k1 to use proportional partition table expansion as was cloning to larger drive (960GB Kingston SSD -> 2000GB Samsung SSD).

It worked as expected (partitions expanded proprtionally according to drive size increase) to all partitions except the last partition which took trailing unoccupied space (also expanded proportionally). That is why I reported this.

Fetched and attached additionally clonezilla.log from /var/log.

[Steven Shiau]

Which version of Clonezilla live did you use?

Steven

[Andris Pavenis]

Did not record output of df after cloning and booting with target disk as /dev/sda but could extract information from system journal

[root@ap ~]# for n in $(seq -4 -1); do journalctl -b $n -g sda9 | grep fsck; done
touko 04 17:56:33 ap systemd-fsck[757]: /dev/sda9: clean, 382/48000 files, 34478/192000 blocks
touko 04 18:53:05 ap systemd-fsck[695]: /dev/sda9: clean, 382/41088000 files, 2610410/168290337 blocks
touko 04 19:29:12 ap systemd-fsck[689]: /dev/sda9: clean, 382/41088000 files, 2610410/168290337 blocks
touko 04 20:22:09 ap systemd-fsck[692]: /dev/sda9: clean, 382/96000 files, 37586/393216 blocks

• first line is from old drive before cloning
• second and thirdh are from new drive with incorrect size (consumed space up to end of drive)
• last one is after I noticed problem and fixed it with gparted and rebooted

[Andris Pavenis]

I did not use Clonezilla live but installed on Arch Linux as it was possible to run it from normal Linux installation

Installed clonezilla version: 3.35.2
PKGBUILD file: https://github.com/archlinux/svntogit-community/blob/30487ee759f62a763ef5071ce39ab60c62f9ba01/trunk/PKGBUILD
Applied patch for ArchLinux build (I installed binary):
https://github.com/archlinux/svntogit-community/blob/30487ee759f62a763ef5071ce39ab60c62f9ba01/trunk/usrbin.patch

As result for functionality it is original 3.35.2 as only installation place is edited

[Steven Shiau]

Arch is not supported as the underlying GNU/Linux operating system by Clonezilla project.
Anyway, if you want to try, please use the unstable DRBL to test it, or please give testing Clonezilla live, e.g., >=2.7.25 a try.

Steven

[Andris Pavenis]

I have already done what I wanted to achieve (SSD content is cloned to larger one and all is working without problems) and do not plan to do additional testing in near future. So I did what I can to document the problem.

Collected installed versions of packages mentioned in PKGBUILD as dependencies fir reference:

[andris@ap ~]$ pacman -Q 'drbl' 'partclone' 'ntfs-3g' 'partimage' 'pigz' 'sshfs' 'parted' 'gptfdisk' 'dosfstools' 'gzip' 'bzip2' 'pbzip2' 'lbzip2' 'lrzip' 'xz' 'pixz' 'lzop' 'ecryptfs-utils' 'screen' 'perl' 'cifs-utils'drbl 2.30.5-1
partclone 0.3.17-1
ntfs-3g 2017.3.23-5
partimage 0.6.9-13
pigz 2.6-1
sshfs 3.7.1-1
parted 3.4-2
gptfdisk 1.0.7-1
dosfstools 4.2-1
gzip 1.10-3
bzip2 1.0.8-4
pbzip2 1.1.13-3
lbzip2 2.5-5
lrzip 0.641-1
xz 5.2.5-1
pixz 1.0.7-2
lzop 1.04-3
ecryptfs-utils 111-4
screen 4.8.0-3
perl 5.32.1-1
cifs-utils 6.13-2

[Andris Pavenis]

ArchLinux bug https://bugs.archlinux.org/task/70712 now links to this one.