Hp Elitebook x360 G2 Boot Problems
-
I’m giving FOG a try because our current imaging solution is unable to boot on our new Elitebook x360s but I’m having roughly the same issues with FOG.
I have FOG setup using DNSMASQ 2.76 and have finally gotten UEFI devices network booting to the server.
When the x360 attempts to boot I get the following…
Could not select: Exec format error (http://ipxe.org/2e008081) Could not boot: Exec format error (http://ipxe.org/2e008081)
I’ve searched around and tried a few different things to get this to work to no avail.
This is my current ltsp.conf:
port=0 log-dhcp tftp-root=/tftpboot dhcp-vendorclass=BIOS,PXEClient:Arch:00000 dhcp-vendorclass=UEFI32,PXEClient:Arch:00006 dhcp-vendorclass=UEFI,PXEClient:Arch:00007 dhcp-vendorclass=UEFI64,PXEClient:Arch:00009 dhcp-boot=net:UEFI32,i386-efi/ipxe.efi,,xxx.xxx.xxx.xxx dhcp-boot=net:UEFI,ipxe.efi,,xxx.xxx.xxx.xxx dhcp-boot=net:UEFI64,ipxe.efi,,xxx.xxx.xxx.xxx dhcp-boot=net:BIOS,undionly.kpxe,,xxx.xxx.xxx.xxx # PXE menu. The first part is the text displayed to the user. The second is the timeout, in seconds. pxe-prompt="Press F8 for boot menu", 10 # The known types are x86PC, PC98, IA64_EFI, Alpha, Arc_x86, # Intel_Lean_Client, IA32_EFI, BC_EFI, Xscale_EFI and X86-64_EFI # This option is first and will be the default if there is no input from the user. # PXEClient:Arch:00000 pxe-service=X86PC, "Boot BIOS PXE", undionly # PXEClient:Arch:00007 pxe-service=BC_EFI, "Boot UEFI PXE-BC", ipxe.efi # PXEClient:Arch:00009 pxe-service=X86-64_EFI, "Boot UEFI PXE-64", ipxe.efi dhcp-range=xxx.xxx.xxx.xxx,proxy,255.240.0.0
I’m hoping someone on here could point me in the right direction on how to get this working as we are dreading setting up 80+ of these without a networked imaging solution. Any help is greatly appreciated!
-
I would start with my ltsp.conf from here: https://forums.fogproject.org/topic/8725/compiling-dnsmasq-2-76-if-you-need-uefi-support/5
It looks like you might have started with my config and then adjusted it for your network.
# Don't function as a DNS server: port=0 # Log lots of extra information about DHCP transactions. log-dhcp # Set the root directory for files available via FTP. tftp-root=/tftpboot # The boot filename, Server name, Server Ip Address dhcp-boot=undionly.kpxe,,<fog_server_IP> # Disable re-use of the DHCP servername and filename fields as extra # option space. That's to avoid confusing some old or broken DHCP clients. dhcp-no-override # inspect the vendor class string and match the text to set the tag dhcp-vendorclass=BIOS,PXEClient:Arch:00000 dhcp-vendorclass=UEFI32,PXEClient:Arch:00006 dhcp-vendorclass=UEFI,PXEClient:Arch:00007 dhcp-vendorclass=UEFI64,PXEClient:Arch:00009 # Set the boot file name based on the matching tag from the vendor class (above) dhcp-boot=net:UEFI32,i386-efi/ipxe.efi,,<fog_server_IP> dhcp-boot=net:UEFI,ipxe.efi,,<fog_server_IP> dhcp-boot=net:UEFI64,ipxe.efi,,<fog_server_IP> # PXE menu. The first part is the text displayed to the user. The second is the timeout, in seconds. pxe-prompt="Booting FOG Client", 1 # The known types are x86PC, PC98, IA64_EFI, Alpha, Arc_x86, # Intel_Lean_Client, IA32_EFI, BC_EFI, Xscale_EFI and X86-64_EFI # This option is first and will be the default if there is no input from the user. pxe-service=X86PC, "Boot to FOG", undionly.kpxe pxe-service=X86-64_EFI, "Boot to FOG UEFI", ipxe.efi pxe-service=BC_EFI, "Boot to FOG UEFI PXE-BC", ipxe.efi dhcp-range=<fog_server_ip>,proxy
-
@Crixx Looking at your script the pxe-prompt should be set to 1 since there is no value delaying the pxe booting process by 10 seconds for nothing to select but the default value.
pxe-service=X86PC, "Boot BIOS PXE", undionly
In this line you are missing .kpxe it should read
undionly.kpxe
If you still can’t get there with my config (or tweaking yours) I have another tutorial on using tcpdump to capture the pxe booting process. But one step at a time.
-
@Crixx said in Hp Elitebook x360 G2 Boot Problems:
Exec format error
This iPXE error means that it was not able to recognize the file that it is told to load and execute. There can be different reasons for this:
/tftpboot/default.ipxe
on the FOG server being empty - shouldn’t be the case after a fresh install but please check!- http://x.x.x.x/fog/service/ipxe/boot.php not returning an iPXE config - please put in your FOG server IP and open the URL in your browser - should not be empty
- You are using an iPXE binary that does not handle bzImage format (one compiled by hand or from rom-o-matic maybe)
- The kernel binary is screwed - this should not happen as the installer checks the hash sums after downloading the files
Please post a picture of the error screen! There might be something that you missed but which would help solving this issue.
-
@Sebastian-Roth and @george1421 Thanks for the prompt replies with assistance! I’ve actually managed to solve the original problem in my post by re-deploying fog in a new VM from scratch. The Hp Elitebook x360 G2 now does boot to the Fog menu but that is where I’ve run into a second, very similar problem that I haven’t been able to solve.
Doing anything in the menu, or attempting to deploy an image results in this error:
Could not boot: No such device (http://ipxe.org/2c048087)
I couldn’t find a whole lot of posts with this error in them other than one which didn’t contain anything that seemed like it would help out in this particular situation.
Thanks for any help with this new error!
-
@crixx said in Hp Elitebook x360 G2 Boot Problems:
What iPXE boot kernel are you sending to the HP? undionly.kpxe or ipxe.efi?
-
@george1421 I’m (re)using the config file from the original post so the X360 should be getting ipxe.efi
-
@crixx Ok just making sure because the error IS related to uefi.
Is the firmware up to date on this HP?
Just for reference it looks like that computer was released apr 2017. (the devs may want to know this).
-
@george1421 I installed the latest firmware as of a few weeks ago when we received them. I can check to see if there is a newer one posted to HP’s site. I can also try one of the ones we haven’t un-boxed and updated yet just to see if it makes any difference. I will post in a bit with the results and Bios version numbers.
-
I’ve tried both of the following BIOS versions and have the same error:
P80 Ver. 01.06 (3/29/2017)
P80 Ver 01.08 (6/09/2017)It does boot and function (mostly) as expected in Legacy mode but for obvious reasons that’s not preferable.
Also in case it matters secure boot was off for all tests.
-
-
@crixx Ideally we’d like to get this working with iPXE, with Sebastian’s help we should be able to get things working.
If debugging iPXE fails, we do have a fall back method to boot FOS from a usb drive. There are a few caveats to do it this way, but it is an option. Lets try to discover what hardware the iPXE kernel is having issues with first. -
snp.efi boots and lets us image with EFI. I’ve just successfully deployed an EFI win10 image using snp.efi. Nothing in else in the fog menu works however.
I’ve tried the debug efi binary you provided and this is the result when I attempt to do anything from the fog menu
-
@Crixx Sorry that I didn’t ask earlier but I keep forgetting myself: What kind of USB ethernet adapter do you use with this device(s)? We need to know this as it is part of the equation and plays a major role. Please bootup windows, open the device driver management, right click the USB ethernet adapter and select properties. Go to the details tab and select “Hardware IDs” from the dropdown. Please post the full (top most) hawrdware ID string here in the forums (copy&paste!). See here on where to find the information.
Thanks for testing the debug binary and posting the picture. Please do so for all the issues you run into. More often than not there is an important detail that we would miss. In this case I have a feeling that the iPXE menu is not generating properly and I wouldn’t have thought about this if I wouldn’t have seen the picture myself. Why do I think it’s not generating right? Because I only see
boot.php... ok
andinit.xz... ok
but nobzImage... ok
. It looks as if iPXE is just missing the information on what image/kernel to chainload next and therefore can’t go ahead.Please open the URL http://172.20.0.136/fog/service/ipxe/boot.php?mac=01:02:03:04:05:06 from any client PC which is able to reach the FOG web interface. Instead of
mac=01:02:03:04:05:06
use the MAC address of one particular client that is having an issue. Post the full text output you see here in the forum! Make sure there is no task scheduled before doing this as it sounds like iPXE code generation for tasking is working properly. -
@Sebastian-Roth We are using the USB-C to RJ45 Adapters that came with the devices (HP Model# RTL8153-03). I do have some usb to rj45 adapters from other companies that I could try out as well if it will make any difference although they don’t always play nice with pxe booting.
The hardware ID for the adapter is:
USB\VID_0BDA&PID_8153&REV_3000
The text output from the URL with one of the x360 mac addresses is:
#!ipxe set fog-ip 172.20.0.136 set fog-webroot fog set boot-url http://${fog-ip}/${fog-webroot} cpuid --ext 29 && set arch x86_64 || set arch i386 goto get_console :console_set colour --rgb 0x00567a 1 || colour --rgb 0x00567a 2 || colour --rgb 0x00567a 4 || cpair --foreground 7 --background 2 2 || goto MENU :alt_console cpair --background 0 1 || cpair --background 1 2 || goto MENU :get_console console --picture http://172.20.0.136/fog/service/ipxe/bg.png --left 100 --right 80 && goto console_set || goto alt_console :MENU menu colour --rgb 0x00567a 0 || cpair --foreground 1 1 || cpair --foreground 0 3 || cpair --foreground 4 4 || item --gap Host is registered as testx360system! item --gap -- ------------------------------------- item fog.local Boot from hard disk item fog.memtest Run Memtest86+ item fog.keyreg Update Product Key item fog.deployimage Deploy Image item fog.multijoin Join Multicast Session item fog.quickdel Quick Host Deletion item fog.sysinfo Client System Information (Compatibility) choose --default fog.local --timeout 3000 target && goto ${target} :fog.local sanboot --no-describe --drive 0x80 || goto MENU :fog.memtest kernel memdisk initrd=memtest.bin iso raw initrd memtest.bin boot || goto MENU :fog.keyreg login params param mac0 ${net0/mac} param arch ${arch} param username ${username} param password ${password} param keyreg 1 isset ${net1/mac} && param mac1 ${net1/mac} || goto bootme isset ${net2/mac} && param mac2 ${net2/mac} || goto bootme :fog.deployimage login params param mac0 ${net0/mac} param arch ${arch} param username ${username} param password ${password} param qihost 1 isset ${net1/mac} && param mac1 ${net1/mac} || goto bootme isset ${net2/mac} && param mac2 ${net2/mac} || goto bootme :fog.multijoin login params param mac0 ${net0/mac} param arch ${arch} param username ${username} param password ${password} param sessionJoin 1 isset ${net1/mac} && param mac1 ${net1/mac} || goto bootme isset ${net2/mac} && param mac2 ${net2/mac} || goto bootme :fog.quickdel login params param mac0 ${net0/mac} param arch ${arch} param username ${username} param password ${password} param delhost 1 isset ${net1/mac} && param mac1 ${net1/mac} || goto bootme isset ${net2/mac} && param mac2 ${net2/mac} || goto bootme :fog.sysinfo kernel bzImage32 loglevel=4 initrd=init_32.xz root=/dev/ram0 rw ramdisk_size=127000 web=172.20.0.136/fog/ consoleblank=0 rootfstype=ext4 storage=172.20.0.136:/images/ storageip=172.20.0.136 loglevel=4 mode=sysinfo imgfetch init_32.xz boot || goto MENU :bootme chain -ar http://172.20.0.136/fog/service/ipxe/boot.php##params || goto MENU autoboot
Thanks for all your help with this!
-
Interesting. That ID translates to a Realtek RTL8153
A quick trip to the realtek store: http://www.realtek.com.tw/DOWNLOADS/downloadsView.aspx?Langid=1&PNid=13&PFid=56&Level=5&Conn=4&DownTypeID=3&GetDown=false shows us this for a driver.
FOS Is currently running 4.11 as its kernel. So (Mr. Kernel Guy, you know who I mean), does this mean that the realtek driver won’t compile under 4.11 or they only tested it up to 4.8? Is that something that can be integrated into the FOS kernel for a small fee?
-
@george1421 The driver is already compiled with this item. That said, ipxe might not have the driver for it. So Kernel is not the problem here, it’s the iPXE Drivers that’s the issue.
-
@tom-elliott OK I stand here a bit red faced. I missed that this was in iPXE still. Too many threads, and not enough extra brain cells to pay attention all the time.
-
@crixx Which FOG menu item did you select that gave you the error we see on the picture? The menu code you posted looks pretty good to me - almost identical to what I get here except the FOG server IP. So my guess about the kernel line missing was wrong.
This is really strange. You say that you are able to image but not use any of the items from the FOG menu?! When you image then the boot.php is just delivering a different iPXE code to the client. This code looks pretty much the same as if you’d select “System Information” from the menu - just calling it with different parameters:
kernel bzImage32 loglevel=4 initrd=init_32.xz ... imgfetch init_32.xz boot
So I can’t really believe it runs into that error when selecting a menu item but things go fine when you schedule a task to image that client. I am not saying it’s impossible but I can’t get my head around it yet.
Driver for the RTL8153/2 USB NICs has been in iPXE for quite some time. Lots of (FOG) people have used it. But hey, not every USB NIC based on this particular chip is the same.
-
@crixx When iPXE throws you back to the shell (as seen in the picture) can you please run the following two commands and post another picture here:
iPXE> ifstat ... iPXE> imgstat ...