zstd compression causes image check to fail on backups
A partition and disk imaging/cloning program
Brought to you by:
steven_shiau
Menu
▾
▴
i am booting clonezilla though netboot.xyz and trying to backup my arch linux install onto a usb drive. if i select the zstd compression for my image and select for the image to be checked after the backup the check will day that the image is broken. checking it manually through the menu has the same result. However if i try to restore said image and select check image before restore the check succeeds. if i use any other compression method I never get that error to begin with even when making a backup. i have tried all the stable and unstable versions
Last edit: Andres David Ortiz 2020-07-17
the system was glitching out on me and was duplicating what i was typing. sorry and i don't see a way to delete this comment
Last edit: Andres David Ortiz 2020-07-17
any one have any ideas?
It seems you are the only one reporting this issue. I use zstd to save images very often and it does not have this issue.
Hence It'd better to check your hardare, like do a memtest, or check the CPU fan...
Steven
the strange thing is if this was a hardware issue I would be seeing issues elsewher no? Its very starange for a hardware to only cause issue in a certain use case of software and it reporducible everytime. I been using the gzip compression without issues for the past week and otherwise temps and everything are normal. runing a memtest also shows no issues.
So this happens ONLY when I use the zstd compression and it will happen everytime I try. Which is really strange idk what could be causing zstd images to fail there check. Just to confirm are you able to create a zstd compressed backup and check it's integrity? maybe its a false positive? I can't think of anything else, everything else in clonezilla works perfectly. Maybe its some how an incompatbility with my system, Im just spiting ideas as I have no clue. these are my specs. This also includes my Arch instalation which is irelvent I guees as i booting the livecd.
https://linux-hardware.org/?probe=da5d5b6a33
the strange thing is if this was a hardware issue I would be seeing issues elsewher no? Its very starange for a hardware to only cause issue in a certain use case of software and it reporducible everytime. I been using the gzip compression without issues for the past week and otherwise temps and everything are normal. runing a memtest also shows no issues.
So this happens ONLY when I use the zstd compression and it will happen everytime I try. Which is really strange idk what could be causing zstd images to fail there check. Just to confirm are you able to create a zstd compressed backup and check it's integrity? maybe its a false positive? I can't think of anything else, everything else in clonezilla works perfectly. Maybe its some how an incompatbility with my system, Im just spiting ideas as I have no clue. these are my specs. This also includes my Arch instalation which is irelvent I guees as i booting the livecd.
https://linux-hardware.org/?probe=da5d5b6a33
In that case, if your image does not contain classified data, please share that so that I can test here.
If it does, then maybe you can try to install a GNU/Linux on a virtual machine, and save it by zstd. Try to see if this issue is reproducible. If so, share that image.
BTW, some hardware only shows the problem when it is run in high CPU loading, and zstd normally uses more CPU than the gzip. Especially when zstd runs parallelly.
Steven
i figured out the issue. For some reason clonezilla didn't like that i was storing the image on the root directory of my usb hdd it need to be under a folder after doing this no vertification issues
OK, got it. Thanks.
However, that's weird... I have no idea why it has such issue for only zstd, but not other compression...
Anyway, good to know this issue is resolved.
Steven
The issue came back ir seems to be an issue with extfs4 and using the ztsd option
Last edit: Andres David Ortiz 2020-09-27
No idea... It seems you are the only one mentioning this issue recently, and I can not reproduce this issue here. Hence it's very unlikely we can fix it.
Steven