Hey guys, since PartClone got updated in 1.5.7.86 I can no longer take images.

@george1421

I added a Cisco switch in the mix, but I couldn’t get it to pass any traffic, even from the switch itself. I don’t know if adding a layer 3 switch into the mix confused everything?

Anyway, I’ll wait until we get new equipment and then debug it from there, like you suggested. We’re going to be reimaging multiple machines at a time before we get new network equipment anyway, so I most likely need to get a RAID 10 set up.

Once we get new equipment in, I’ll give the Multicast a shot and then reply back to this thread. But, that’s way in the future. Probably several months or more.

I appreciate all the help you guys have put in to this! Thanks a bunch!

I am having a few issues and I don’t know how to resolve them. And they are making me wonder if this configuration is even viable for general usage.

One of the issues I am having is if I enable the Apache rewrite to HTTPS, when I try to inventory a machine or deploy an image and when FOS adds/checks the MAC address, I get an error that states “No viable mac to use.” If I disable HTTPS rewrite, it works first time, every time. I don’t know if a FOG URI needs to be excluded from the rewrite, like I had to do for iPXE to boot. I have a hunch this might be an easy fix?

The second major issue I am having is even if I disable HTTPS rewrite and the SSL certificate checks, I get the error in the attached image. I even just did a base Debian install using 1.5.7.88, none of my extra code, and I still got the error. Don’t know if I am doing something wrong? I know all the Linux installs I have been testing with have more than enough space to captures images, even a full disk, non-resized image. And it’s typically the ‘raw’ partition or the ‘ntfs’ partition of a Windows Server image. It’s all very strange…

@Sebastian-Roth

I think I managed to do it properly. Let me know if I need to change anything. Thanks!

@Sebastian-Roth

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.

@Sebastian-Roth

Yes, sir! My apologies for not doing this sooner.

https://forums.fogproject.org/topic/14116/development-fog-not-capturing-image-partclone-update

@Sebastian-Roth

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.

@Sebastian-Roth

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!

@shruggy

Okay, cool. I’ll wait for the build to complete and then pull it done for one more test. Thanks!

@shruggy

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.

I pulled the latest init just now, too. Using both uncompressed and Zstd

@Sebastian-Roth

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…

@Sebastian-Roth

To start, I am using Hyper-V for everything. Yes, I do get that above image when I try to capture other images - either Windows or Linux. When I attempt to deploy the Windows image (the original image I’ve been trying to take), I get this error. But it does seem to complete. It does something similar for the the Linux image.

@Tom-Elliott

Yes! It worked perfectly. I’ve tested it a bunch of times and it works great. I do get this output after one of the partitions. It doesn’t affect anything it seems, but I’ve just noticed it.

@Sebastian-Roth

Yes, sir! My apologies for not doing this sooner.

https://forums.fogproject.org/topic/14116/development-fog-not-capturing-image-partclone-update

Hey guys, since PartClone got updated in 1.5.7.86 I can no longer take images.