Boot File Testing for SR
-
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 -
@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?
-
@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
-
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.
-
@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
-
HEADipxe.efi: Hang on init.xz (attempted 15 times)
5cf5ffeipxe.efi: No hang on init.xz (attempted 15 times)
-
@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.xzSo 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?
-
@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.
-
@Psycholiquid Let’s see what the iPXE devs make of this: http://lists.ipxe.org/pipermail/ipxe-devel/2017-September/005837.html
-
@Psycholiquid We got an answer from Michael Brown (chief iPXE dev) and seems like we are on a good track with this. Now we need to figure out which commit broke things again. Here are some new binaries to test for you - download link.
1b67a056.efi
3ae70be.efi
9ccd8fe.efi
993fd2b.efi
6bd0060.efi
6324227.efi
a8f80a7.efiSame as before, just test and post if it hangs on init.xz or boots properly or does something different altogether. Hope you still have that setup up and running. Remember that
has_usb_nic=1
parameter… -
@sebastian-roth Always have the setup LOL. I will get them tested between user migrations today. Pray for me. Users are retarded.
-
1b67a056.efi: No hang on Init.xz
3ae70be.efi: No hang on Init.xz
9ccd8fe.efi: No hang on Init.xz
993fd2b.efi: No hang on Init.xz
6bd0060.efi: No hang on Init.xz
6324227.efi: No hang on Init.xz
a8f80a7.efi: No hang on Init.xz -
@Psycholiquid Thanks again for testing and sorry for my late reply. Somehow this doesn’t really add up but it seems like tiny changes in the (EFI) timer code break iPXE for the surfaces.
There are another couple of binaries to test (same download link). Though I am a bit in a hurry and those were compiled on a different machine that I usually do this. So hope I still got it all right. Please test and report back again in the same manner.
@Tom-Elliott Seems like after a long fight we can finally get rid of those 7156 binaries. Turns out the issue was fixed in iPXE without us even properly reporting it. If you’re fine with removing those binaries just let me know or go for it yourself. Sure some people are used to having those and need to change their DHCP config again but I think it’s worth getting rid of this old crap altogether now!
-
I will test those after lunch, no rush on the replies. Been here for years not going anywhere.
-
@sebastian-roth I’m fine with it, I don’t have access to my servers until much later though, so if you don’t mind removing them I’m okay with it too. Thanks.
-
c4ce9259.efi: No hang on Init.xz
74d90b33.efi: No hang on Init.xz, but tries to use the dock NIC 3 times before switching to USB NIC
0631a46a.efi: No hang on Init.xz, but tries to use the dock NIC 3 times before switching to USB NIC
7428ab72.efi: No hang on Init.xz
d46c53c.efi: No hang on Init.xz -
So the newer ipxe commits are working again?
I’ve been having issues with the official Surface 4 docking stations on 7156. They boot to the FOG menu just fine, but I can’t inventory or deploy with them. They get stuck at the stage where I normally unplug the USB NIC, but it doesn’t fix it for the docks.
-
This is all testing I will not comment on whether they are “working” or not. We are only testing up to the init.xz to make sure it gets past it
-
@avaryan I can say my 7156 is still working just fine with my Startec USB nic. and I am fully firmware updated on my surface.
-
@Developers @Moderators Ok, I just opened a pull request to remove the 7156 binaries. Please all keep that in mind. Might cause some minor confusion in the next weeks. But it’s good to get rid of it.
As you all can see the tests of the most recent iPXE version shows that things are back to normal again. I reported back to Michael Brown on the iPXE devel mailing list. So he’s got that in mind as well.
@Avaryan To me this sounds like a different issue. Would you mind opening a new thread on this and posting more details (FOG version, USB ID of the NIC used as shown with
lsusb
, …).I’ll mark this solved/closed now. @Psycholiquid Thanks heaps for the great work on testing all the binaries and such!