Win 10 UEFI boot; Asus AMD F1A55-M LX PLUS R2.0; http://ipxe.org/7f04818f

[george1421]

@whyzzi This worked on your old(er) fog server with the same hardware?

What version of FOG was on your old fog server?

[whyzzi]

I am trying to recall if it was .32 or 1.32; an early release and BIOS boot only. BIOS boot works on the current server, 1.5.9rc2.

[george1421]

I also noticed you are using https. While that isn’t a problem I just watned to point it out.

Oh my you were on 0.3x and now on 1.5.x series there is a world of differences between the two. No problem, but you will need to recapture your images if they were created before 1.2.0.

Ok where this is erroring out, iPXE loads both refind.conf and refind.efi and then transfers control over to refind.efi. What is happening in the picture is refind.efi is failing to start causing the error in iPXE.

Just to confirm you don’t or haven’t created any custom fog iPXE menu entries yet?

[whyzzi]

Server hardware or machine hardware?
I am looking to use UEFI because we’ll be replacing our AMD APUs with circa 2015 Lenovo’s soon. While I successfully tested a lenovo m93p on 1.5.8 and deployed an image in early March, I think I removed the network boot ability of that workstation because it loaded right up when I did my check; I did not see the iPXE menu.

[whyzzi]

@george1421
Yeah, https: I admit, when I upgraded to 1.5.9rc2 I forgot to add the command line switches for https, and re-ran the installer to include encryption (ipxe need the certs recreated)
I did create just the one entry, and I kept the original refind.conf to swap around when needed. It took me a bit because copying the files need the group and owner to go with it, or “file not found” appears during the iPXE load process.

[george1421]

@whyzzi So that still doesn’t explain why refind.efi is not starting. Can you confirm that refind_x64.efi exists. It should because it said that it transferred correctly. Note there seems to be a recent change from refind.efi to refind_x64.efi.

[whyzzi]

@george1421

Again, setting DHCP to refind_x64.efi works booting from network right into windows.

It is when loading iPXE first, seeing the menu, counts down to load the hard drive is when I see this error.

It seems to me that the iPXE.efi handoff to refind_x64.efi is what causes the problem in the hardware cited.

The staging VM loads the menu, counts down, and boots Windows without issue.

[whyzzi]

@george1421

The dir listing you asked for

drwxr-xr-x 2 fogproject www-data     4096 May 28 20:24 .
drwxr-xr-x 3 www-data   www-data     4096 May 27 20:59 ..
-rw-r--r-- 1 fogproject www-data     1966 May 27 20:59 advanced.php
-rw-r--r-- 1 fogproject www-data    21280 May 27 20:59 bg.png
-rw-r--r-- 1 fogproject www-data    16272 May 27 20:59 bgdark.png
-rw-r--r-- 1 fogproject www-data     1139 May 27 20:59 boot.php
-rw-r--r-- 1 fogproject www-data  8438432 May 27 20:59 bzImage
-rw-r--r-- 1 fogproject www-data  7836480 May 27 20:59 bzImage32
-rw-r--r-- 1 fogproject www-data   234697 May 27 20:59 grub.exe
-rw-r--r-- 1 fogproject www-data      592 May 27 20:59 index.php
-rw-r--r-- 1 fogproject www-data 20889900 May 27 20:59 init.xz
-rw-r--r-- 1 fogproject www-data 20317908 May 27 20:59 init_32.xz
-rw-r--r-- 1 fogproject www-data    25340 May 27 20:59 memdisk
-rw-r--r-- 1 fogproject www-data  1839104 May 27 20:59 memtest.bin
-rw-r--r-- 1 fogproject www-data    29875 May 28 20:24 refind.conf
-rw-r--r-- 1 fogproject www-data   262592 May 28 18:51 refind.efi
-rw-r--r-- 1 fogproject www-data   202624 May 27 20:59 refind_aa64.efi
-rw-r--r-- 1 fogproject www-data   201600 May 27 20:59 refind_ia32.efi
-rw-r--r-- 1 fogproject www-data   208776 May 27 20:59 refind_x64.efi
-rw-r--r-- 1 fogproject www-data    29719 May 28 18:35 rfind.conf.orig
-rw-r--r-- 1 fogproject www-data   262592 May 28 18:51 rfind.efi.orig
-rw-r--r-- 1 fogproject www-data   208776 May 27 20:59 rfind_x64.efi.orig
administrator@hvfog-2020:/var/www/fog/service/ipxe$

Yeah, I swapped refind.efi & refind_x64.efi just to see if there was a difference. Unfortunately, the problem remained the same. I also played with deep uefi scanning for older mainboard firmware, and is currently enabled in refind.conf.

[whyzzi]

I actually have a pre-“csm” llano apu mainboard (same processor, bios 1005). I was lucky enough to have a backup first (BIOS drive) that I had to restore and used 1.5.8 to do it. I have many boards of this model type that are firmware 1105, only that I have yet to check and verify the presence of a csm).

I also have other similar year Asus (counting 10 ~ year 2012 firmware E35M1-M PRO boards & 6 F2A85-M PRO with 2014 firmware) hardware I could test against, and as long as I make a backup first I could easily restore it with the BIOS booting process.

Are you interested in those results? My Org (a public library) is closed due to covid and currently I am working from home. But I’d have zero trouble setting something up next week for testing. I could even get back to the Lenovo m93p and give comment on that as well.

[Sebastian Roth]

@whyzzi @george1421 From what I read between the lines I would also think that iPXE fails to hand off to rEFInd, though not sure why yet.

Can you please download different versions of rEFInd and give those a try? For each version download refind-bin-0.xx.y.zip, extract that and try out refind_x64.efi. See of you can make it chainload from disk using one of these. As George said, we moved from a single rEFInd binary to platform specific ones not too long ago. And I am wondering if you have a system here that pretends it’s 64 bit actually has a 32 bit CPU or something.

I have to check on a multicast failure I had with 1.5.8 but that is a different post for when I am ready to fix it and find that I need help.

We have fixed a few things in multicasting in the latest RC version.

[whyzzi]

@Sebastian-Roth
Sure! I’ll grab a few and test them against my vm, and then against hardware next week. I recall that someone used refind version 10.9. It was the one that worked with older HP Machines, and missed where the internet location for the files were. Thank you for for helping me!

[george1421]

@Sebastian-Roth said in Win 10 UEFI boot; Asus AMD F1A55-M LX PLUS R2.0; http://ipxe.org/7f04818f:

And I am wondering if you have a system here that pretends it’s 64 bit actually has a 32 bit CPU or something.

Ah yes I have seen this two where especially in tablets there will be a 64 bit processor but it will be pinned at 32 bits. This confused iPXE into calling the wrong kernel. That may not be the case here but I remember it was a tough one to debug.

[whyzzi]

Niether 0.10.9 nor 0.11.5 of the refind binaries made a difference (same exact error). Fog works, and the booting network UEFI and into Windows is 100% fine on the Lenovo m93p.

Turns out about 30% of our public machines are without a CSM module. Because of that, and because BIOS boot works, I have decided to fall back to BIOS boot deployment for my org’s public computers. The way my fog installation is now will still allow me to grow with the Lenovo’s without having to fight with it.

Thanks for looking into this with me, I have appreciated the help.

~ P.V.