PXE Boot HP X2 210 (Hybrid tablet Windows 10 Pro)

[Matthieu Jacquart]

@Sebastian-Roth OK done, but I saw no differences…

[Sebastian Roth]

@Matthieu-Jacquart Thanks a lot for all the testing and pictures! No output from the kernel whatsoever?! This is a really hard one we are tackling here. Looking through the iPXE source code again I might have found some more debugging options we could try. Download this iPXE binary (DEBUG=image_cmd,image,efi_image) and give it a try. Will bring you to the shell again. Just try the same commands as before.

[george1421]

@Sebastian-Roth Its interesting here, in that bzImage (I suspect) is getting corrupted, where in my test bzImage was getting downloaded but instead the root fs was being corrupted (somehow). Again this is only speculation, but it seems consistent with the bzImage or init not making it to the client correctly to be executed.

[Tom Elliott]

@george1421 maybe secure boot is blocking it?

[george1421]

@Tom-Elliott said:

@george1421 maybe secure boot is blocking it?

Good point since bzImage is an OS. The OP should check to see if secure boot is turned off, or even can be turned off.

[Matthieu Jacquart]

@Sebastian-Roth Ok, I think there are interesting things
Are the command ok for you ?

@Tom-Elliott @george1421 Secure boot is disable in bios, if not I couldn’t even boot on ipxe file

[Sebastian Roth]

@Matthieu-Jacquart At least we get some more information now. From what I can tell this looks all reasonable. shell.ipxe is detected as script and bzImage is detected as EFI binary. The message “format not recognized” seams kind of odd but makes sense when looking at the source code. I don’t know why the iPXE developers have it this way, but seams ok!
Just init.xz is not properly recognized. But again according to the source code that seams fine - see this comment in src/core/image.c:

        /* Try to detect image type, if applicable.  Ignore failures,
         * since we expect to handle some unrecognised images
         * (e.g. kernel initrds, multiboot modules, random files
         * provided via our EFI virtual filesystem, etc).
         */

So what I am wondering about is what happens when you run the boot command after this? Do you see any more debug messages (you should from what I see in the code)? Please try and wait at least for 5 minutes to see if anything happens. As well you might want to try the bzImage_epk binary (plus debug earlyprintk=efi parameters) again.

[Matthieu Jacquart]

@Sebastian-Roth Ok, I forgot to tell you but after taking pictures I’ve entered boot command and waited at least15 minutes, nothing happens
I’m going to test with bzImage_epk

[Matthieu Jacquart]

@Sebastian-Roth Something strange with bzImage_epk, it worked yesterday with previous efi file.

[Sebastian Roth]

@Matthieu-Jacquart Could you please try again. “Connection timed out” sounds a bit like the network or webserver on your FOG was not ready yet. Kind of weird but please try again. If you can do it with the bzImage binary then bzImage_epk should work as well (if it is still in place!).

Would be awesome if you can get a picture with a clean try using bzImage_epk and boot at the end. All debug messages readable. Then I will get in contact with the iPXE devs to see what ideas they have about it.

[Matthieu Jacquart]

@Sebastian-Roth Arf I’m stupid, I made a mistake one IP adress… I hate azerty keyboard
Let’s go for a last fresh try

[Matthieu Jacquart]

@Sebastian-Roth Ok last one !
No change for boot, even after 5 minutes

[Sebastian Roth]

@Matthieu-Jacquart Ok, great. Will see what the iPXE devs think about this… Will let you know soon.

[george1421]

@Sebastian-Roth I’m wondering if the efi environment needs to be able to understand the disk image and the .xz image is not understood. If I look at the rom-o-matic setting under image type the .xz format is not listed. But the other image test types (yellow in pict below) are. Since it can’t identify the .xz image it gives the format not recognized error. The format no understood command it troubling since someone put that test in the code, it makes me think its an important check.

It would be really nice if the ipxe developers could add a md5sum command to ipxe so we could ensure the image in memory has the same hash as the images on the FOG server. Right now there is no way to know if the image is getting corrupted in transit.

[Tom Elliott]

@george1421 To my understanding, iPXE doesn’t need nor care about the format of the file (gz, xz, bz2, lzma, etc…) as that’s handled when the kernel loads anyway.

[Sebastian Roth]

@george1421 I am pretty sure the .xz image format does not need to be understood by iPXE. This is handled by the kernel (later on in the process). See my post with the C comment a little further down! As well the message “format not recognized” does not play a roll for us. See the C code here if you like. This might be a minor print out bug in iPXE which does not cause any issue!

@Matthieu-Jacquart Meanwhile I compiled a new iPXE binary with some added custom debug output. Please put this in your /tftpboot and same procedure… hopefully we will see messages after boot!

[Matthieu Jacquart]

@Sebastian-Roth ok thaere’s some new info !

Do you want me tot test also with bzImage_epk binary (plus debug earlyprintk=efi) ?

[Sebastian Roth]

@Matthieu-Jacquart Thanks again! Sorry but this will be step by step as we just don’t really know where it starts hanging. Good to see that at least we now have some output after boot. No need to try bzImage_epk at the moment. Will probably upload the next ipxe binary in a few minutes…

[Sebastian Roth]

Here is a new one! Removed some of the debug statements (just saying so that you don’t wonder) and added some new ones. Please give it a try. Will hang again but we know better where.

[Matthieu Jacquart]

@Sebastian-Roth ok, 2 pictures, before and after “boot” command