EFI_STUB enabled custom FOG kernel causing ipxe.efi to throw error 0x2e008081
-
Incidentally, what are the other possible formats in which the kernel can be built?
I have little to no experience building linux kernels of any kind. I only know that all of the documentation I have seen talks about building the kernel as “bzImage”. The only other kernel mentioned in the documentation is called something like “vmlinuz”, but I have no clue how it is built since make complains there is no recipe to build “vmlinuz”.
Thanks again for the help!
-
I just noticed your question about me trying to get an old FOG server UEFI capable. The answer is no, I only have 1 FOG server currently running on Ubuntu Server 16.04.03.
I am going through the custom kernel builds because everything I have been reading said the most likely cause for the exec format error was the kernel was lacking these two settings enabled:
EFI runtime service support = y
EFI stub support = y -
My intent is to give you a hand with this later today. I’m sorry for the delay, but my work is occupying my time today. I think the answer is in these posts. As I said before we have a last resort option of booting FOS from a usb stick. We have to go that route for some Mac systems that have had firmware updates that make it incompatible with iPXE. So by booting FOS directly from the usb stick we can bypass iPXE with certain caveats. So there ARE options here we haven’t tested.
-
My work day is about to end; however, I would be happy to go through the process with you sometime soon.
I did test loading FOG via UEFI on a completely different model of machine. The new machine doesn’t complain about the exec format error. The new machine loads to the FOG boot menu like it should; but, when a task is selected it immediately reloads ipxe and unloads it, and then reloads ipxe in an almost continues loop, when it finally stops, it loads the reFind.efi which gives restart and reboot as its two main options.
-
@scott-lynch After reviewing this thread, I think we should attempt to boot FOS directly from the usb stick (fall back plan). Right now its not clear if its the hand off between ipxe and FOS, or in the FOS kernel itself.
ref: https://forums.fogproject.org/topic/7727/building-usb-booting-fos-image
Lets stick to the tutorial with the stock FOG kernel.
-
@george1421 As far as I understand @Scott-Lynch has already tried USB booting - which worked for other models but not on this one.
I don’t have much time right now but will get back to you later on today. Most probably I can offer some help on this.
-
@Scott-Lynch Talked to George and he’s right about testing to boot FOS Linux directly from USB is good to test. We have seen crappy UEFI firmware where even that failed.
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.
-
Ok, I’ll go through the tutorial now. I have the FOG server reset to the stock kernel, so everything should be good to go. Will post back with results.
-
No problem. I do have secure boot disabled on the WinBook and the 2nd test computer. Neither computer would boot to the USB stick with the secure boot option turned on. I will go through the FOS tutorial and get back with the results.
-
@Scott-Lynch The security chip mentioned is something else. Please read through the links I posted.
-
My bad. The Intel TPM chip was still enabled. I just disabled it and, just for kicks, ran the PXE boot sequence. I made it to the FOG boot menu. It correctly showed the host as being already registered. (I had manually entered the information into the FOG console since I am having to use a usb-to-ethernet adapter to get things rolling client side.) I then attempted to have it run the Client System Information (Compatibility) at which point it successfully loaded the stock bzImage. It threw a few ACPI errors before going into kernel panic. Exact message for the kernel panic is:
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0)
In truth, this is a bit of headway given that, before, it wouldn’t even load the kernel, much less read it and attempt to execute it.
-
@scott-lynch said in EFI_STUB enabled custom FOG kernel causing ipxe.efi to throw error 0x2e008081:
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0)
It may not fit exactly this case, but historically every time we’ve seen this the FOG admin had somehow tried to pxe boot with pxelinux.0, which was how fog 1.1 use to pxe boot before FOG switching over the iPXE. Please ensure you are using fog delivered pxe boot files.
The other implications of this is that the init.xz file is damaged in some way.
The APCI messages are only warnings and not something to be concerned about.
-
I am still working through the FOS build, but have run into a few snags I am attempting to get through. Namely, should I be looking at the multiboot instructions? They seem to be the only set that mentions EFI…
-
@scott-lynch Look at the FOG chat bubble above on the fog tool tray. If you follow the process the usb drive will be universal both uefi and bios booting.
-
Well, to get everything set up for all of this, I deleted the bzImage and bzImage32 files located in /var/www/fog/service/ipxe, but I didn’t touch either the init.xz nor the init_32.xz. I also deleted anything with ‘ipxe’ in its filename from /tftpboot/
I then ran the FOG installfog.sh in fog_1.4.4/bin to have it put everything back that I’d removed.
-
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.
