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.
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!
Okay, cool. I’ll wait for the build to complete and then pull it done for one more test. Thanks!
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
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…
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.
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.
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.
I stepped through everything until it halted. Pressing [Enter] here doesn’t do anything.
No worries! The holidays took up so much time, I haven’t had much time to work on this to expand it to non-RedHat distros.
I updated both init.xz and init_32.xz and get a similar error. I had been seeing this before, too. I definitely have a large enough drive for the image. 140-ish GB /images with the image that needs to be taken is only a 50GB disk. I noticed this when I updated to 1.5.7.86 and then subsequent updates. I noticed PartClone got updated and that’s when things started to break. If I do a new install of 1.5.7 with the old version of PartClone, everything works fine. How do I enable debug capture for iPXE? Thanks!!
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 said in FOG/Apache PKI/Certificate Authentication:
Do you know anyone who’d be keen?
No, unfortunately I don’t know anyone who is a C programmer. Most of the people I work with are .NET programmers… But, I can ask around to see if there are any other people on different teams who work with C.
I know you guys are super busy and this isn’t super important, so no worries!
Gotcha. Yeah, I feel foolish. I apologize!
I had an idea based off this webpage: http://ipxe.org/crypto#embedded_certificates. I noticed in the client certificate section when making ipxe you can add in a client certificate and its private key. I attempted to do this in various ways, but never got it to work. It did load the client certificate and the chain of CAs, but I still got the same error (http://ipxe.org/err/1c0de8). I saw you previously attempted to comment out the offending lines and then got a “cert too big” error.
The weird thing is I could use the certstore command and the HTTP address of my OCSP server and pull in a random certificate (just to verify) and the command did connect and pull in the certificate. So, there is definitely something strange with iPXE, HTTPS, and connecting to itself.
That was the only idea I really had, unfortunately. I don’t know where to go next or if it should just be counted as a loss.
Yes! I’ve seen Mr. Elliott around everywhere on these forums offering his wisdom for years. 
I read over that forum post about iPXE and it does seem like you did run into a specific issue and then iPXE (the organization) got busy or disappeared. I have an idea after reading over some iPXE documentation, but I have a question first. When I run buildipxe.sh and it makes the new files and then copies them to the right directories, do I have to restart any services for that to take effect?
The reason I ask is because I modified buildipxe.sh and completely removed the BUILDOPTS from all four make calls (BIOS and EFI, regular and 10secdelay). So, the iPXE that gets created should not have custom certificates loaded into it, right? If that’s true, I am seeing some weird behavior. Even when I reboot the FOG server, attempt to iPXE boot, it fails and I hop into the iPXE shell, I run a certstat and it still displays my custom CA certificates as being [PERMANENT]. That shouldn’t be happening?
Looks like everything is happy on Github. I see Mr. Tom Elliott has take a quick look at it already.
While that is being looked over and decided on what updates I need to make, I wanted to reach out and see if anyone could help me with the iPXE issue I am still having. If I try to boot iPXE over HTTPS, I get this error http://ipxe.org/err/1c0de8. I don’t know if iPXE technically needs HTTPS? Does that mean the imaging process is unencrypted?
Thanks to everyone for the assistance! I really appreciate all the hard work!
I think I managed to do it properly. Let me know if I need to change anything. Thanks!
@Sebastian-Roth said in FOG/Apache PKI/Certificate Authentication:
@ty900000 Yes, it’d be great if you share your changes with us. Though we probably won’t add this feature to the soon to come 1.5.8 release (only bug fixing) but to FOG 1.6…
Right, sounds good. Do you all have a preferred method as to where I can send stuff?
Thanks again everyone!
