Compression comversion tool doesn't work for images created with dd
A partition and disk imaging/cloning program
Brought to you by:
steven_shiau
Issue discovered in clonezilla-live-20180812-bionic:
The ocs-cvtimg-comp tool doesn't convert the compression used on images of unrecognised filesystem types, such as the Microsoft reserved partition on Windows 10 installations.
A look at the code reveals that this is because it just copies any images whose filename is of the form "$img_file.dd-img" or "$img_file.dd-img.aa*".
Also, the compression type is not saved as part of the image filename (like it is for recognised filesystem types) when creating dd images. It really ought to be, because the fallback option of using the "file" tool doesn't recognise all of the possible types of compression that Clonezilla can use.
A minor correction to the last paragraph:
The "file" tool does actually recognize all of the types of compression Clonezilla uses, but the function get_image_cat_zip_cmd() in /usr/share/drbl/sbin/ocs-functions is missing a case to check for LZMA compression in file's output.
Also, get_image_cat_zip_cmd() only uses the filename to identify the compression method for files of that contain "ptcl-img", so even if the compression type were to be added to the filename of dd images, the decompression routines wouldn't use it.
The above means that dd images which are compressed using LZMA compression during backup will not be decompressed when restored. The compressed image will instead be written directly to the partition!
I also note that in the function save_part_by_dd(), there is a comment that claims that the compression method is forced to "gzip" for dd images, but this doesn't appear to be correct: I made a backup of my Windows machine using bzip2 compression, and have verified that the Microsoft reserved partition dd image is a bzip2 file.
Yet more information:
I've spent some more time looking through the code, and it seems the intention is that dd images should only be compressed with gzip, and I think that's the case when the "dd" method is chosen. But when partclone.dd is used, that limitation is not imposed.
The image of the Microsoft reserved partition I mentioned in my previous post was made as part of a multiple partition backup, and "partclone.dd" was used on that partition, not "dd". Thus, the compression method was not forced to "gzip" in the function check_ocs_input_params().
Yes, that's the limitation. So if you save the image by default, it should work. There is no any checksum we can check for dd while there is CRC checksums in Partclone.
Steven