Unrecognised filesystems backed up using LZMA compression not restored correctly
A partition and disk imaging/cloning program
Brought to you by:
steven_shiau
Menu
▾
▴
#307 Unrecognised filesystems backed up using LZMA compression not restored correctly
Issue discovered in clonezilla-live-20180812-bionic:
Unrecognised filesystem types backed up using LZMA compression are not decompressed when being restored - the compressed image is written directly to the partition instead.
Analysis of cause:
1. Recognised filesystems types backed up with partclone have the compression method saved as part of the filename (e.g. "sda1.ntfs-ptcl-img.bz2.aa")
2. Unrecognised filesystem types don't have the compression method stored in the filename - instead, they have filenames of the form "sdX.dd-img.aa".
3. When restoring a partition, the function get_image_cat_zip_cmd() in /usr/share/drbl/sbin/ocs-functions only extracts the compression type from filenames containing the string "ptcl-img". For other filenames, it uses the tool "file" to identify the compression type.
4. When using "file" to identify the compression type, the function get_image_cat_zip_cmd() tests for all compression types except LZMA. Thus, it assumes LZMA-compressed files are uncompressed raw data.
Oops. I've just realised that I didn't set the "milestone" of this ticket to "stable-clonezilla-live", and there doesn't seem to be a way to update it.
Could you please tell us the steps to save and restore in detail so that we can reproduce this issue here?
Please show that step by step. Thanks.
Steven
My PC has two hard drives (sda & sdb). sdb3 is a Microsoft Recerved Partition of size 16MB. I backed up the image of sdb3 to an unpartitioned USB stick (sdc) containing a VFAT file system.
The attached files sdb3-orig-file-output.txt and sdb-orig-dump.txt contain the output of "file -s /dev/sdb3" and a hexdump of the first kilobyte of the contents of sdb3 BEFORE the backup.
Backup steps:
1. Select "Start_Clonezilla"
2. Select "device-image"
3. Select "local_dev"
4. Select "sdc" as backup partition (/home/partimag)
5. Select "/" for backup destination
6. Select "expert" mode
7. Select "saveparts"
8. Enter backup name (I chose "sdb3-lzma-test")
9. Select "sdb3" only for backup
10. Select "-q1 Priority: Only dd" (NOTE: I have also tried the default option here. The result is the same.)
11. Use default extra parameters
12. Select "-z4 lzma_compression"
13. Enter maximum file size (I chose 1024MB)
14. Select "-sfsck Skip checking/repairing source file system"
15. Select "Yes, check the saved image"
16. Select "-senc not to encrypt the file system"
17. Select "-p choose"
18. After backup is finished, select "rerun2" to keep /home/partimag mounted.
The attached file clonezilla-img is the log taken from the backup directory. You can see on line 55 that the output of "partclone.dd" is piped into "lzma" to compress it.
The attached files sdb3.dd-img-file-output.txt and sdb3.dd-img-dump.txt contain the output of "file sdb3-lzma-test/sdb3.dd-img.aa" and a hexdump of the first kilobyte of sdb3-lzma-test/sdb3.dd-img.aa
Restoration steps:
1. Select "Start_Clonezilla"
2. Select "device-image"
3. Select "skip" to keep existing /home/partimag
4. Select "expert" mode
5. Select "restoreparts"
6. Select backup directory (in my case, "sdb3-lzma-test")
7. Select sdb3 image to be restored
8. Select sdb3 as target partition
9. Use default extra parameters
10. Select "-k Do NOT create partition table"
11. Select "Yes, check the image before restoring"
12. Select "-p choose"
The attached file clonezilla-restore.log is the log of the restoration taken from /var/log. You can see on lines 37 - 42 that the image is not decompressed before being written to the partition.
The files sdb3-restored-file-output.txt and and sdb-restored-dump.txt contain the output of "file -s /dev/sdb3" and a hexdump of the first kilobyte of the contents of sdb3 AFTER the restoration. They clearly show that the compressed image has been written directly to the partition without being decompressed.
Thanks for the bug report. We have fixed this issue. Could you please give testing Clonezilla live 20181024-* or 2.6.0-16 a try?
https://clonezilla.org/downloads.php
Please let us know the results. Thanks.
Steven