Development FOG not capturing image - PartClone update
-
I did test with several of the other compression types. As far as I can figure the Partclone Uncompressed is the only one that throws the above error with the 1 minute time out. And I also noticed it is not capturing sda3 - which is the raw partition on my particular Windows image. I think when it gets done with sda2 and attempts to move to sda3, it throws the Usage: unset_name [OPTIONS] error from farther above.
The only reason I am using Uncompressed is because the Gzip and Zstd image captures with 6 compression were slower than I remember them being in older (much older) versions of FOG - about 3 GB/min capture and deploy whereas the uncompressed was 6+GB/min, which I know is about line speed. We had a server at my last job and we were getting 6+GB/min when we captured and deployed a machine with Zstd level 6 compression. I need to do some testing tomorrow with a physical machine capture and deploy to see what’s going on with my network…
-
I pulled the latest init just now, too. Using both uncompressed and Zstd
-
@shruggy said in Development FOG not capturing image - PartClone update:
@Tom-Elliott said in Development FOG not capturing image - PartClone update:
I pushed another fix and believe the issue was as @Quazz noted is the -c argument was missing. Strange as that is, as the -c argument doesn’t appear to be a part of the spec list (unless somebody already added that to the patch for partclone and I didn’t know it?)
My understanding of it is this:
- images captured with
partclone.imager -cneed to be restored withpartclone.restore, raw images captured withpartclone.ddor withpartclone.imagerwithout-cneed to be restored withpartclone.dd - the options for
partclone.imagerare basically the same as for anypartclone.$ftype(including-cand-a), it’spartclone.ddthat is a special case. The symbolDDonly pertains topartclone.dd, the symbolIMGis specifically defined inMakefileforpartclone.imager, but never gets used in upstream Partclone code.
Adding on to this,
partclone.imageris generated usingpartclone.ddsource files.As per the makefile: https://github.com/Thomas-Tsai/partclone/blob/master/src/Makefile.am#L56
Making this commit: https://github.com/Thomas-Tsai/partclone/commit/2d1ee7c94139f390453ea8cb8675f67173bde33b problematic.
The special code for RAW is then locked to
partclone.ddwhilepartclone.imageris stuck using the “normal” code, which doesn’t work properly for its scenario.Restoring the old code for
partclone.imagershould work. (there is no option to change the if conditionmain.csince there is no opt for imager…)The stuff in https://forums.fogproject.org/topic/14078/1-5-7-89-partclone-doesn-t-capture-an-image-in-dd-mode-wrong-options-in-fog-upload/17 should work.
We just need to create a patch for it imo.
- images captured with
-
-
That seems to work better. It is pull the ‘raw’ partition 3 and works when using uncompressed capture and deploy, Zstd compression 6 worked well too. I did see a few errors that didn’t seem to affect anything. The first one was after imaging with complete and the second image was before it started.
-
-
Okay, cool. I’ll wait for the build to complete and then pull it done for one more test. Thanks!
-
@ty900000 That build does not yet include the partclone fixes, though. But we are getting close to that.
-
@ty900000 said in Development FOG not capturing image - PartClone update:
I did test with several of the other compression types. As far as I can figure the Partclone Uncompressed is the only one that throws the above error with the 1 minute time out.
and…
I pulled the latest init just now, too. Using both uncompressed and Zstd
… picture with segmentation fault …Those two answers don’t add up for me. Can you please do a simple test with the different compressions (none, Gzip, Zstd) and post which error exact you get for each.
-
My apologies; I know my previous message was confusing.
A few days ago, the init from Jenkins and using Uncompressed would throw the error when it deployed - the image above about /dev/sda3. A few hours after that a new init was pushed to Jenkins that I tried. That one reintroduced the segmentation error during image capture, not matter what compression I tried.
I currently am using the init @shruggy suggested yesterday and that one seems to have fixed everything for me during image capture and deployment.
I haven’t pulled the latest init from the Jenkins. Would you like me to do that?
Thanks everyone!
-
@ty900000 said:
A few days ago, the init from Jenkins and using Uncompressed would throw the error when it deployed - the image above about /dev/sda3.
I guess you mean this error:
That would mean the capture did run fine and partclone did not segfault when capturing. Though we probably can’t figure out which version it was you were using back then as too many things were tried in a rush. Nevermind.
I currently am using the init @shruggy suggested yesterday …
@shruggy Would you mind telling us which version of partclone this is?
-
I’m sorry! I had to backtrace this information, if you still want it: FOS 112 had the segmentation fault, FOS 113 had the segmentation fault (also tried the debug with this one), FOS 114 captured without the segmentation fault and introduced the unset_name [OPTIONS] error during capture and subsequently the /dev/sda3 error during deployment, and FOS 115 reintroduced the segmentation error.
I can redownload FOS 114 files and test with those again, if need be.
-
@ty900000 The problem with using 114, is it’s missing an argument. So the Segfault is double’d due to -c/-a0 and not likely due to either of the arguments, but rather the fact partclone is segfaulting as it cannot determine file size, as it is literally commented out of the code. This means, a raw (imager) image file will not be generated at all. (/images/<imagename>/d1p<#ofparttion_to_be_cloned_in_imager_format>.img will be missing comletely.)
In my case the partition number was 2, and in yours it appears the partition number is 3.
I have created a fork of the partclone repository and implemented what I would think should address the issue by reimplementing the filesize display capabilities. As @Sebastian-Roth learned, simply uncommenting the line allowed partclone to work properly (as far as we could tell).
Until we patch the issue on our side (either by using our forked copy of the repository or directly implementing it as a part of the build process), this is still going to be a problem. I think we have a way to fix it, just haven’t had time to implement and have you (or anybody else who’d be willing) to test it.
-
@Sebastian-Roth said in Development FOG not capturing image - PartClone update:
@shruggy Would you mind telling us which version of partclone this is?
It’s the latest git shapshot:
https://github.com/Thomas-Tsai/partclone/tree/58d138da6e0f473acd80a7c9b8544d104377d50f
with the fix you suggested:$ cd git/fos/Buildroot/package/partclone $ ls Config.in partclone-0.3.12.patch partclone.imager.patch partclone.mk $ cat partclone.imager.patch diff --git a/src/ddclone.c b/src/ddclone.c index 04f8775..cab5386 100644 --- a/src/ddclone.c +++ b/src/ddclone.c @@ -30,7 +30,9 @@ void read_super_blocks(char* device, file_system_info* fs_info) } strncpy(fs_info->fs, raw_MAGIC, FS_MAGIC_SIZE); fs_info->block_size = PART_SECTOR_SIZE; - //fs_info->device_size = get_partition_size(&src); +#ifdef IMG + fs_info->device_size = get_partition_size(&src); +#endif fs_info->totalblock = fs_info->device_size / PART_SECTOR_SIZE; fs_info->usedblocks = fs_info->device_size / PART_SECTOR_SIZE; close(src);I haven’t yet pulled the latest FOS, however. So it doesn’t contain the changes to
func.shby @Tom-Elliott i.e. no special case forpartclone.imager.On the other note, when using unpatched Partclone 0.3.12 I also sometimes got segmentation fault, but didn’t report it. The case when Partclone finished successfully, but actually didn’t capture the partition was the more common outcome. I’d say, somewhere in the relation of 4 (empty) successes to 1 segfault, IIRC. And I didn’t notice any pattern to segfaults then (e.g. it could happen with or without compression).
-
@ty900000 Sorry, forgot to update this topic as well. We have added a fix. Please update to the latest
dev-branchand it should be all good to go again,
