EFI_STUB enabled custom FOG kernel causing ipxe.efi to throw error 0x2e008081
-
Capture task started and client booted to FOS, selected option 1, and it is currently resizing the filesystem. So far, everything looks optimal. It didn’t even hiccup on the call to DHCP for an IP Address. I think the issue with it “failing” had to do with the client sending 4 requests for an IP address.
However, the client just threw a garbled error message. I’ll try and upload a picture. One sec.
-
Here is the error.
At this point I need to get to my doctor appointment. Thanks for your help.
-
@scott-lynch Ok this is a image definition configuration error.
FOG supports two different image compression tool. The legacy gzip and the newer zstd. From what I understand from the post you have gzip selected but you are using a compression level higher than 9. I’m suspecting that you are using a compression index greater than 9 as defined in the image definition
That error probably needs to be trapped in the web ui to keep people from making that same setting @Developers
BUT you getting this far also tells us that this computer is not having a problem with the FOS kernel itself, it maybe related to the hand off between iPXE and FOS (bzImage).
-
Ok, thanks heaps @george1421 to have pushed this quite far! We know FOS is running properly on this hardware. @Scott-Lynch Just let me know when you have time and we can tackle the kernel panic thing. I am fairly sure this is not a big thing. Were you still able to boot up other clients in this scenario? Would be great if you could take a picture (or even better a steady 60 fps video) of the kernel panic on screen and post here. Quite often there is more information hidden.
-
Sorry for the late reply. Other work kept me busy. I will verify the image settings and make the adjustments you mentioned and will try again. It will be Monday before I will likely get the results for you.
-
Ok, I adjusted my image settings and restarted the capture process. This time it is behaving as it “should”. At least everything seems to be optimal on the capture process.
-
Thanks for mentioning the gzip/compression settings of the image in the FOG console. I would never have thought they were a cause of one of my issues. So zstd is the preferred compression method for the images?
-
@Scott-Lynch Nice! Keeping my fingers crossed for it to finish without another hick up. I’ll mark this solved now. Just posting what I said earlier so people may find it again.
Solution here:
Other than that I am wondering if you’ve disabled secure boot? I know this questions sounds stupid but just wanna make sure as the error sounds a bit like it could be on. I do remember one case where a Lenovo device had some kind of extra security chip which needed to be disabled - read through this and this.
-
@scott-lynch said in EFI_STUB enabled custom FOG kernel causing ipxe.efi to throw error 0x2e008081:
So zstd is the preferred compression method for the images?
It’s meant to be much faster…
-
@scott-lynch said in EFI_STUB enabled custom FOG kernel causing ipxe.efi to throw error 0x2e008081:
So zstd is the preferred compression method for the images?
Yes it is much faster at decompression. There is a small performance hit on compression speeds, but for that initial capture penalty you get a much faster decompression rate.
If I remember correctly the gzip engine is (now) only use for image capture. Zstd is used as the default decompresser because it can accept both gzip and zstd images. You only get the performance increase with a zstd native image.
BTW: Wonderful that you are now capturing an image with FOS. So that tells us the issue isn’t with the FOS kernel (bzImage) but with the hand off between Firmware, iPXE and the FOS linux kernel.
