Boot issues with UEFI32 & x86_64 CPU

[EspenU]

Server

• FOG Version: 1.3.0 RC23
• OS: Ubuntu 16.04 x64 server

Client

• Service Version: N/A
• OS: N/A

Description

I’m working on a touch screen panel PC that is giving me a LOT of headaches (not only FOG related).
Although it’s using an x86_64 CPU, the rest of the PC is 32-bit. So it needs to boot a 32-bit kernel.
It boots to the FOG menu fine, so far so good.
But if I try quick registration from there, it loads a couple of files, and then jumps back to a non-graphical version of the menu.
Other PC’s can do quick registration without any issues.

Eventually I managed to figure out what goes wrong.
The DHCP request from the PC sets the correct arch and loads i386-efi/ipxe.efi.
In the “default.ipxe” file the first line sets the arch again. But it checks what arch the CPU is. Since the CPU arch is x86_64, the system assumes from there on out that it’s a 64-bit system and loads 64-bit files.
This of course does not go very well and it fails.

My temporary solution has been to modify the first line of “default.ipxe” to only read “set arch i386”.
So… Can this check be improved to check the running kernel arch instead of the CPU arch?

[george1421]

@EspenU If you manually register this system, you can define what kernel to use. If you manually define the kernel does it boot and re-register properly?

[Tom Elliott]

@EspenU I’m totally confused by this. What is it actually doing ? The arch isn’t something that’s been reported before. Not in the sense you’re describing. Loading the kernels and units are completely independent on what ipxe is loaded. Just because it loads i386/ipxe.efi does not mean the system must load a 32 bit kernel/init.

[EspenU]

@Tom-Elliott Ah, yes I see your point that there might be situations where you would want it to load a 64-bit kernel even if you’ve loaded a 32-bit ipxe.efi.
In my situation that does not work. The PC cannot handle a 64-bit environment, even though the CPU is 64-bit… So the arch check done in default.ipxe is “correct”, but it just will not work for this PC…
Hmmm… Then I might have to live with having a modified default.ipxe, since other PC’s seem to work fine with it as well.

If you’re still confused, I can try to explain it again from scratch, I’m just having a hard time finding the right way to describe it…

[Tom Elliott]

@EspenU I think saying, “this doesn’t work well” doesn’t help anybody because we have no reference point. “This of course doesn’t go well” what exactly happens when it tries to load?

[EspenU]

@george1421 I can try that later today to see what happens. Although it will not work as a production solution since I will be imaging around 100 of these per year…

[EspenU]

@Tom-Elliott Right, sorry about that.
What happens when it “does not go very well” is what I described further up in my post.
It just jumps back to a non-graphical version of the FOG boot menu. No errors or messages of any kind as far as I can see.

[Tom Elliott]

@EspenU Often times the menu is refreshed as you described because something failed while it was trying to load. All of the “failures” revert to “goto MENU”.

I don’t know why you would need 32 bit though. Maybe UEFI 32 can only pass off to a 32 bit binary, but that makes no sense either.

[george1421]

@Tom-Elliott There are FOG configuration settings where you can globally change what kernels are sent to the client. Just change the 64 bit setting to send the 32 bit kernel and inits. There should be no harm for using the 32 bit kernels for everything since the 64 bit CPUs are backwards compatible. The 32 bit version of FOS should work just fine for deploying both x32 and x64 systems.

Again I use the words “should” because I have not personally tried this myself.

[Tom Elliott]

Location is:

FOG Configuration Page->FOG Settings->TFTP Server-> FOG_TFTP_PXE_KERNEL FOG_PXE_BOOT_IMAGE

Just change bzImage and init.xz to bzImage32 and init_32.xz respectively.

[Tom Elliott]

And pictures might go a lot further than trying to describe it, either pictures or a short video would go a long way for us to better see the issue and hopefully figure out a solution.

I’m going to move this post into FOG Problems as this, from what I can tell, is NOT a bug at least where fog is concerned. Of course, please provide a browser output of what’s being presented as well.

I think you could do this with:

http://fogserver/fog/service/ipxe/boot.php?arch=x86_64&platform=efi

[EspenU]

@Tom-Elliott said in Boot issues with UEFI32 & x86_64 CPU:

Location is:

FOG Configuration Page->FOG Settings->TFTP Server-> FOG_TFTP_PXE_KERNEL FOG_PXE_BOOT_IMAGE

Just change bzImage and init.xz to bzImage32 and init_32.xz respectively.

I’ll try that. Thanks.

[EspenU]

@Tom-Elliott said in Boot issues with UEFI32 & x86_64 CPU:

And pictures might go a lot further than trying to describe it, either pictures or a short video would go a long way for us to better see the issue and hopefully figure out a solution.

I’m going to move this post into FOG Problems as this, from what I can tell, is NOT a bug at least where fog is concerned. Of course, please provide a browser output of what’s being presented as well.

I think you could do this with:

http://fogserver/fog/service/ipxe/boot.php?arch=x86_64&platform=efi

I’ll try to compile some more information during the week so it’s easier to see.
However, since it’s possible to work around the issue by changing the default kernel it might be just as good to use that as a “solution” and close the issue.
This strange combination of 32-bit and 64-bit hardware is probably not very common, and for those edge cases it should be fine just to force the 32-bit kernel.

Thanks for your help :-).

[george1421]

@EspenU As I posted before, if you have issues with the 64 bit kernel for some reason, just use the 32 bit kernel for all imaging needs. You can use this kernel universally for both 32 bit and 64 bit systems. There is no technical advantage of the 64 bit over the 32 bit kernel. Just renaming the global 64 bit kernel and inits values to point to the 32 bits stuff should be sufficient for all of your imaging needs.