Boot File Testing for SR

[Tom Elliott]

Are you just trying to find out when Surface Pro booting became an issue? From the boot file you should post the ipxe version. It appears in the “ipxe (abcdef)” of the connection request. The parenthesis should show us the version when it worked.

[Psycholiquid]

Not sure exactly what SR is looking for, he just requested that I try each file and let him know the result as posted. Using his template.

We have about the same time frame work wise so I told him I would test them all for him today

[Psycholiquid]

This isn’t a resolvable post really. More of a testing platform post for him to see what his files are doing.

[Sebastian Roth]

@psycholiquid Thanks again for the testing. Looks good to me.

@Tom-Elliott This was intended to double check that this issue is not something we have caused (e.g. by some specific header config or what). So beside testing all the iPXE git commits I also grabbed our original binaries from SVN to see if the results match up. See the spread sheet called 00_iPXE svn commits here and you’ll understand what I am up to with this. The results are consistent with what you see in 00_iPXE git commits: Seems iPXE git commit 757ab983811ac8d3f65efb65b8309738bd33bea3 was the first to show this problem - hangs on init.xz.

So now we can get to the interesting part of finding out what exactly does cause the issue. So I compiled a debug enabled (DEBUG=efi_timer) version and it kind of seems like the issue went away with debug enabled.

@Psycholiquid Just to make I compiled a binary from the exact same source but without the debug - please test 02_efi_timer_ipxe_wo_debug.efi when you have time and see if that hangs or not.

PS: I moved most of the other testing posts here as well.

[Sebastian Roth]

@Psycholiquid And here I have another one for you to test as well. I won’t be around today. So I hope you can make it work and we get some more results from that. Take a USB key, format as FAT32 (!) and create the directories EFI\boot\ (or EFI/boot/ if doing this on linux) and copy the iPXE binaries to that directory. Now first rename 02_efi_timer_ipxe.efi to bootx64.efi, pop that into the surface and boot from the USB key. See what you get. Hang on init.xz or not. Then go back and rename bootx64.efi to 02_efi_timer_ipxe.efi and 02_efi_timer_ipxe_wo_debug.efi to bootx64.efi and try again.

[Psycholiquid]

I am out today but will do this first thing tomorrow morning.

[Psycholiquid]

02_efi_timer_ipxe.efi: No hang on init.xz

Hating you right now and you must feel in my pain of how small the text is on these dang Surfaces. 4K FTL

[Psycholiquid]

02_efi_timer_ipxe_wo_debug: No hang on init.xz

[george1421]

@psycholiquid Pssst… to adjust the small font size try this FOS kernel parameter vga=792

vga=792 should be 1024x768x24 video mode, and clean your monitor, please!!!

ref: https://unix.stackexchange.com/questions/71231/grub2-and-kernel-vga-parameter/114980

[Psycholiquid]

@george1421 Stupid thing requires I constantly touch it. I hate these surfaces. in order to boot from anything other than Windows Boot I have to swipe the screen I need those white gloves jewelers use.

[Sebastian Roth]

@Psycholiquid This is confusing me more and more. If I didn’t do anything wrong then those two binaries were compiled from most current iPXE source with our FOG header files and would show that the initial issue was fixed in the iPXE code since then and we didn’t notice…

Would you please do me another favor and test those new binaries as well: 302f1eeipxe.efi, 694c18ipxe.efi, c917687ipxe.efi, e09331aipxe.efi, 5cf5ffeipxe.efi, 757ab9ipxe.efi, d37e025ipxe.efi and HEADipxe.efi (download. Just post short notes on each binary “No hang on init.xz” or “Hang on init.xz”. Thanks!

[Psycholiquid]

ok, doing it now. Sorry roaming profiles migration making me manic…

[Psycholiquid]

@sebastian-roth

302f1eeipxe.efi: wont boot at all on my surface
694c18ipxe.efi: Hang on init.xz
c917687ipxe.efi: Hang on init.xz
e09331aipxe.efi: Hang on init.xz
5cf5ffeipxe.efi: No hang on init.xz
757ab9ipxe.efi: Hang on init.xz
d37e025ipxe.efi: No hang on init.xz
HEADipxe.efi: Hang on init.xz

[Sebastian Roth]

@Psycholiquid Something must have gone wrong here. Maybe I uploaded the wrong HEADipxe.efi or your test failed somehow. Could you please re-test that one binary?

[Psycholiquid]

@sebastian-roth said in Boot File Testing for SR:

@Psycholiquid Something must have gone wrong here. Maybe I uploaded the wrong HEADipxe.efi or your test failed somehow. Could you please re-test that one binary?

HEADipxe.efi: Hang on init.xz

Same result

[Sebastian Roth]

The other possible explanation I can comes up with is that this is all a timing issue and we see it working and sometimes hanging with the same binary… Could you try a dozen times? As well please try one of the non-hanging binaries several times.

[Psycholiquid]

@sebastian-roth said in Boot File Testing for SR:

The other possible explanation I can comes up with is that this is all a timing issue and we see it working and sometimes hanging with the same binary… Could you try a dozen times? As well please try one of the non-hanging binaries several times.

Yep not a problem

[Psycholiquid]

HEADipxe.efi: Hang on init.xz (attempted 15 times)

5cf5ffeipxe.efi: No hang on init.xz (attempted 15 times)

[Sebastian Roth]

@Psycholiquid Thanks heaps! I can’t stop scratching my head. Let me try to sort this. For you to understand, I just picked a couple of git commits from the iPXE repo where changes were made to the efi timer code:

757ab9 - Wed, 4 May 2016 - Hang on init.xz
c917687 - Mon, 20 Jun 2016 - Hang on init.xz
694c18 - Mon, 20 Jun 2016 - Hang on init.xz
e09331a - Wed, 7 Dec 2016 - Hang on init.xz
5cf5ffe - Wed, 7 Dec 2016 - No hang on init.xz
d37e025 - Wed, 25 Jan 2017 - No hang on init.xz
302f1ee - Thu, 26 Jan 2017 - wont boot at all on my surface
d46c53c (HEAD revision couple of days ago) - Wed, 13 Sep 2017 - Hang on init.xz

So to me it looks as if we have a regression here. Worked nicely with some changes made Dezember 16/January 17 but we are back to hang again on the latest versions.

More to the point - commit 5cf5ffe seems to have fixed the issue. Reading this commit message I can kind of imagine why this stuff is causing problems…

EFI provides no clean way for device drivers to shut down in
preparation for handover to a booted operating system. The platform
firmware simply doesn’t bother to call the drivers’ Stop() methods.
Instead, drivers must register an EVT_SIGNAL_EXIT_BOOT_SERVICES event
to be signalled when ExitBootServices() is called, and clean up
without any reference to the EFI driver model.

So what to do next?

[Psycholiquid]

@sebastian-roth No problem, I am really not liking these Surfaces and it looks like M$ is pretty much giving up them also. Go figure, they release something they no longer want ot make anymore.