EFI_STUB enabled custom FOG kernel causing ipxe.efi to throw error 0x2e008081
-
Will do. I was just having an issue with grub not wanting to have both grub-efi-ia32 and grub-efi-amd64 installed simultaneously. Every attempt to install one, uninstalls the other.
I’m not exactly proficient with linux, but am getting a crash course it seems…
-
Ok, I booted to the FOS and it worked to the point of loading the kernel and executing the client compatibility tests. After starting the eth0 interface and waiting on the link to come up, it did some udhcpc discover with the client IP, deleted routers, and added dns entries 3 times then failed to get a response from DHCP on the 4th run through.
-
@scott-lynch Ah sorry I forgot to tell you (its in the tutorial) you need to update grub.conf with the IP address of your fog server.
Once you get to the Grub menu, select option 6 to debug
-
LOL actually, I saw that in the tutorial and forgot about it… No biggie. Easily fixed.
-
I updated the grub.cfg with my server’s IP address and booted the client. It loaded to the DHCP testing, still threw a could not get IP address from DHCP on the 4th query of eth0, but loaded to the FOG splash screen when I hit the key to continue.
-
@scott-lynch so you are at the FOS linux command prompt?
If so there is a command to restart the dhcp process I think it
udhcpc -i eth0Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG!
-
@george1421 Just off the top of my head I can think of two reasons why its not getting dhcp.
- FOS doesn’t support your network adapter. This can be proven by
ip link show - spanning tree hasn’t started forwarding data by the time the network is ready. We see this issue if someone has standard spanning tree enabled and not one of the fast protocols.
- Its really getting an IP address, its just failing to reach the fog server. It will try this 3 times during booting then give up.
- FOS doesn’t support your network adapter. This can be proven by
-
I don’t think there is a need, I ran the ifconfig command and it shows that eth0 has an IP address and the link is up. No idea why it would say it failed to get an IP address. Regardless, it seems to be okay.
So, to begin the debug process, since I am NOT having an issue with eth0, I use the command ‘fog’ to start an image capture?
-
ip link show gives:
eth0: <BROADCAST, MULTICAST, UP, LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 3c:18:a0:0c:d6:05 brd ff:ff:ff:ff:ff:ff
The network connection looks sound. (Besides, with the trouble I went through to find a usb-to-ethernet adapter that the computer would recognize during boot, it better work… LOL)
-
I am about to leave for the day. Doc appointment. I will continue in the morning. Is there a dictionary of commands for the fos boot system somewhere I can look at to familiarize myself with the next bit of testing?
-
@scott-lynch said in EFI_STUB enabled custom FOG kernel causing ipxe.efi to throw error 0x2e008081:
I don’t think there is a need, I ran the ifconfig command and it shows that eth0 has an IP address and the link is up.
OK then its important to understand why on this. My intuition is telling me its either spanning tree or you did not key in your fog server IP address correctly. If you could snap a picture of it saying it can’t get the IP address we can find out which.
=====
In your case now how to use this usb boot
On your fog server you must first schedule a capture/deploy then usb boot from this stick. At the grub menu pick option 1 and it will do the rest. -
@scott-lynch Sorry my screen wasn’t refreshing. So I missed a few questions
-
No problem. I will start a task and do as you say on booting the client.
-
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?
