Posts made by Junkhacker

@george1421 is it possible that you tried to deploy a legacy image with partclone 0.3 and the --ignore_crc flag set, then captured it again, or something like that? or maybe captured without checksums with 0.3 and redeployed it with --ignore_crc? i know for certain that the second of those two will result in corrupt partition without reporting any problem. (it tries to skip the blocks in the image file where the checksum would be, but there it skips actual data because there’s no checksum)

@george1421 mine was a bios image deployed in legacy mode. the image was a Win 7 Ent zstd compressed resizable, compression 11.
i also tested a windows 10 image that was otherwise the same.

with uefi, the UUID information not applying error i got would be important. did yours throw a visible error? do your partitions have the data intact on them, or are they corrupt? (i had problems in testing with corrupted deployment when using the --ignore_crc flag is why i ask.)

if i use the init @Sebastian-Roth supplied here https://forums.fogproject.org/post/119056 and edit the funcs.sh to remove the --ignore_crc flags, i have no problems when deploying any images. just fyi

i tried the init you supplied, and i got a "failed to set disk guid (sgdisk -U) (restoreUUIDInformation)

though, it did boot fine

@george1421 line 2052 of funcs.sh needs the -aX0 flag set, but i don’t see anything else wrong yet. i’ll test it as soon as i can.

@george1421 pigz still outperforms gzip. gzip still doesn’t support multi-threading, and i don’t think they have any plans to implement it. also pigz uses a slightly different formula for it’s rsyncable implementation that i have tested to be slightly better at creating chunk data that dedups.

blame me for the 200MB split code. it was an experiment that got pushed into the mainline code, but the idea was to make it easier for people running FOG to make backups to CD/DVD/external hard drive.

@Sebastian-Roth you’re right. it’s -aX0, that was a typo

the --rsyncable is for zstd which should also be given the option -B128 to specify the window block size that’s just about ideal for deduplication.
another option for zstd, which is functionally incompatible with --rsyncable is --long which allows you to dedicate more memory to the window of compared data in zstd, this can substantially improve the compression. the --long option however will also require the --long option to be specified during decompression.

@george1421 a new feature i want to utilize was added in 1.3.8. 1.4.0 is out now.

@george1421 awesome. if the changes i want to be made make it in to the final builds, it will allow my university to save terabytes with deduplication.

since you’re updating partclone, you guys plan on updating zstd too, right?

@george1421 well, like i alluded to with my last comment, adding checksums doesn’t make sense since we pipe it right into a compressor that will add it’s own checksums.
… actually, you can defer to my post here https://forums.fogproject.org/topic/12750/file-format-and-compression-option-request/ for my arguments for change, but the short of it is:

disable checksums with the flag -a0

the rest of my changes actually have to do with the settings we use for compression, come to think of it.

@george1421 it’s kinda always been there, but i would assume it’s because we could squeeze a little more performance out of fog by not calculating checksums. also, since the image wouldn’t decompress properly anyway if there was corruption the checksum would only catch anything that went wrong between parclone capturing and it being piped into the compressor. which isn’t likely to have any problems, and if there is there’s a lot more going on than a checksum is going to help with.

@george1421 if your goal is only to “make it work” all you have to do is remove the --ignore_crc flag

however, there’s a couple things i think we should set as the new defaults for the new version of partclone when capturing

@Wayne-Workman there really isn’t a need to do that

the reason the partitions aren’t usable is because of a bug in partclone since at least 3.11 regarding --ignore_crc, which we use in our scripting. if you remove that, it works fine. i’ve been doing testing with partclone 3.12 for a while and it is completely backward compatible with the existing images. sorry i didn’t see this discussion until now.

also, there’s new options in the latest versions of ztst and partclone that i think we need to discuss. interesting and potentially very important options have been opened up.

@george1421 another option is fog storage servers to open up more transmit slots at a time

ok, in the directory for that image, there should be a file named “d1.fixed_size_partitions”. the contents of that file would be “:1” telling it that partition one should not be resized. delete that line.

@george1421 said in Wrong Image Size indicated in the image manager.:

@Developers if its the first partition thing, can we just mark the image as resizable in the image config files?

yeah, that should work.

@processor even with legacy boot, this is far from the default setup

@george1421 uefi systems definitely couldn’t use it, but i don’t see any reason it wouldn’t be possible with windows 10. sure wouldn’t recommend it though. it just really threw me off when you said you hadn’t seen single partition setups since NT