Surface Pro 4 won't get to registration menu

[Tom Elliott]

@george1421 I think you’re right, but it’s been something like 3000 commits since 1.2.0. While I do try to ensure the init’s will work regardless of the version (at least starting from 1.0.0), I don’t know all possibilities.

@sarge_212 As you’re able to boot the client, can you get it to boot to a debug window and get us a lspci, lsusb output?

[Sebastian Roth]

@george1421 said:

So it appears that the inits are being corrupted in transit (??) or the memory they are being saved into is being damaged somehow.

I thought about this too but somehow hoped that it’s not true. Why would we see this on several UEFI machines? Do we need to verify init.xz when downloading it to the client (iPXE command imgverify)?? Awesome stuff that you found with your VM booting in UEFI mode. Thanks for hanging in there.

@Tom-Elliott said:

@sarge_212 As you’re able to boot the client, can you get it to boot to a debug window and get us a lspci, lsusb output?

Up to now he only was able to boot into debug using George’s flos/flogger USB stick. What do you expect to see in lspci/lsusb?

[george1421]

Take the hint from Sebastian for image verify here is what I did so far.

I created a new snponly.efi image from the rom-o-matic. The script will chain to my dev fog server running the trunk build, but contains fog 1.2.0 stable kernels (yields better error messages).

This is the ipxe chain command: chain tftp://192.168.1.88/tester.ipxe

The tester.ipxe script file was populated with the code used for the quick reg action.

#!ipxe

kernel bzImage init=/sbin/init initrd=init.xz root=/dev/ram0 rw ramdisk_size=127000 web=192.168.1.88/fog/ consoleblank=0 debug loglevel=7 mode=autoreg
initrd  init.xz
boot

So that is the testing environment.

[round 1]
I copied the bzImage and init.xz files (fog 1.2.0 stable) to the /tftpboot directory so I could load them via tftp instead of http. The system was booted and the transfer (as expected) was terribly slow. But the results were the same “corrupt init.xz”

[round 2]
I updated the ipxe file to use http to download the image file.

#!ipxe

kernel http://192.168.1.88/fog/service/ipxe/bzImage init=/sbin/init initrd=init.xz root=/dev/ram0 rw ramdisk_size=127000 web=192.168.1.88/fog/ consoleblank=0 debug loglevel=7 mode=autoreg
initrd  http://192.168.1.88/fog/service/ipxe/init.xz
boot

Same results: “corrupt init.xz”

[round 3]
Increased the size of the ram drive to 250000
Results: “corrupt init.xz”

[round 4]
Attempted to boot bzImage32 and init_32.xz
Results: boot failed

[round 5]
Reset bzImage and init.xz

Updated the tester.ipxe to use image verify command and built the self signed ca and then signed both bzImage and init.xz creating the required .sig files.

#!ipxe

imgtrust --permanent

kernel http://192.168.1.88/fog/service/ipxe/bzImage init=/sbin/init initrd=init.xz root=/dev/ram0 rw ramdisk_size=250000 web=192.168.1.88/fog/ consoleblank=0 debug loglevel=7 mode=autoreg
initrd  http://192.168.1.88/fog/service/ipxe/init.xz
imgverify bzImage http://192.168.1.88/fog/service/ipxe/bzImage.sig

boot

Results: imgverify command not found (!!nuts!!)

[round 6]
rebuilt the ipxe.efi to include the IMAGE_TRUST_CMD. updated dhcp to use ipxe.efi instead of snponly.efi
Results: Failure the ipxe.efi was not compiled with a valid certificate. Ugh! unless the ipxe.efi file was compiled with the self signing certificate the imgverify command won’t work.

[Tom Elliott]

@Sebastian-Roth I think I’m just hoping to see nic information. While efi issues are still present the original issue which registration was failing the output may help us get at least drivers for the nic.

[sarge_212]

@Tom-Elliott In which OS should I do this? Will I do this in the Flogger OS or in the ubuntu live image or where should I run this command?

[Tom Elliott]

@sarge_212 Yes in FOS/FLOGGER

[sarge_212]

@Tom-Elliott Here is the output from those 2 commands:

Let me know what else I can do, thanks!

[Tom Elliott]

So this system doesn’t have an onboard nic? Is the usb nic plugged in when you ran these commands.

[sarge_212]

@Tom-Elliott
Correct, the surface pro 4 does not have an onboard nic. Let me compare output but I think the USB nic is plugged in when I ran this. I might be able to boot from the USB stick in the dock and with the 2.0 USB network adapter plugged in, would that be helpful?

[Tom Elliott]

@sarge_212 I think/hope so maybe. I don’t really know though,

[sarge_212]

@Tom-Elliott So I tried that, with the USB network-adapter, and it just added a device in the output of lsusb. Not sure where to go from here.

[Sebastian Roth]

@sarge_212 You might wanna try this bzImage_epk kernel image. Download it and put it into /var/www/fog/service/ipxe on your FOG server. I compiled this kernel with something called earlyprintk enabled. Possibly we see some more information before we hit the kernel panic. I mean use this kernel and try PXE booting your device with the USB NIC. Just use this kernel binary instead of the normal one. Plus use earlyprintk=efi as kernel parameter for this host - register this host/MAC by hand in the WebGUI, add the kernel parameter to it and run a debug task with it.

[sarge_212]

@Sebastian-Roth So I can manually register the host in the WebGUI with the MAC address? I will try that out.

[sarge_212]

@Sebastian-Roth I’ve done the manual registration and pushed the bzImage_epk to the host with the kernel arguments and it did give a lot of text printing before the kernel panic. Video coming soon…

[sarge_212]

@sarge_212 Here is some video output of the pxe boot and kernel panic. Hope this helps!

https://www.youtube.com/watch?v=YvzswksAOUg

[Sebastian Roth]

@sarge_212 Thanks for the video. I get the impression but it’s impossible to read what’s going on there. Are you able to take a series of pictures? Most cameras can do this. And having the camera in a fixed position would also help I guess. As a start, can you take a clear picture of the full screen when it gets to the end (kernel panic). Possibly we see something there already.

[sarge_212]

@Sebastian-Roth Sorry! Yeah I can do that.

[george1421]

@Sebastian-Roth I would think if you could get the camera in a fixed postiion and then only try to record the bottom half of the screen (sharply) then that may yield better results. I did see that my iPhone 5 has a slow motion mode (120 fps) that would allow more time to try to read the information before it scrolls off.

[sarge_212]

@Sebastian-Roth Yeah I have an iPhone 6 with the Slo Mo, think that might be of help ? The bigger problem is a fixed position. IF only we had a selfie stick in the office!

[Sebastian Roth]

Doesn’t need to be in a self standing position I reckon. Would be a lot better if you can arrange things so that your phone is “standing” on ground (table, books, …). That way the shaking is a lot less. Best if you can cramp it in between two books to make it stand by itself… you will figure it out I am sure.