HP Spectre x360 13-ac050ca & 15-bl018ca

[agent_k]

@george1421 so I think between @Tom-Elliott and I something got lost in translation. To be clear I’ve ONLY used the undionly.kpxe never *.efi

[Tom Elliott]

@agent_k I based my information off the ipxe thread where the user was using efi. If you’re not booting via EFI, then you should be fine.

Though it might be worth a shot if you can use EFI Network stack to boot these machines to see if things work a little better for you.

[agent_k]

@Tom-Elliott I appreciate all the help and I’m willing to try just about anything you suggest. I apologize for the confusion of that other thread it was just that person seemed to have a eureka moment by having his inits uncompressed…

[george1421]

@agent_k Can we confirm for absolute if this device is a legacy (bios) or uefi system? Check to see if secure boot is an option and its turned off in the device firmware.

[agent_k]

@george1421 100% in BIOS mode, secure boot off and in fact when I attempted in UEFI mode it doesn’t even get an IP.

I’m going to attempt the instructions here https://wiki.fogproject.org/wiki/index.php/BIOS_and_UEFI_Co-Existence and report back, thankfully it does appear to be isolated to a specific set of hardware and quite frankly using UEFI mode might make all difference anyways. Thanks again for your help, I’ve monopolized enough of your time and @Tom-Elliott 's for one day.

[Tom Elliott]

@agent_k You can still try the decompressed init’s I suggested earlier without having to make any major changes.

While I don’t suspect it will work, it’s worth a “try”.

[Tom Elliott]

@Tom-Elliott https://forums.fogproject.org/topic/9981/hp-spectre-x360-13-ac050ca-15-bl018ca/8#

[agent_k]

@Tom-Elliott You Sir are correct, 100% no help.

[george1421]

@agent_k You had a question earlier about where these settings go (custom kernel and custom [unpacked] inits)

[agent_k]

@george1421 Like this?

Host Kernel: /tftpboot/i386-efi/ipxe.efi or /tftpboot/ipxe7156.efi
Host Init: /var/www/fog/service/ipxe/init_32

[george1421]

@agent_k well yes and no, but more no than yes.

kernel: bzImage32
host init:init_32.xz

If that doesn’t work then extract the 32 bit image like tom outlined. Place the file in the same location as the init_32.xz (/var/www/html/fog/service/ipxe). Then change host init to: init_32

The 32 bit kernel will boot just fine on a 64 bit cpu.

FWIW: The kernel you referenced is for the iPXE menu not FOS. Not a bit issue, it just won’t do what you think.

[agent_k]

@george1421 So the force 32bit approach isn’t working, both the xz and uncompressed attempts end with the same error we started with. Any other suggestions?

[george1421]

@agent_k well my bag of tricks are getting a bit empty on this one.

I do have one left. We can try to usb boot the fog engine directly and bypass pxe booting all together. With usb booting we loose the tight integration with FOG, but I’m interested in seeing if this is a iPXE issue vs FOS.

ref: https://forums.fogproject.org/topic/7727/building-usb-booting-fos-image

[george1421]

@agent_k Watch the chat bubble on the fog forum tool tray at the top for additional instructions

[agent_k]

@george1421 Thank you, thank you, thank you! and @Tom-Elliott thank you too!!

[Tom Elliott]

@agent_k What was it?

[agent_k]

@Tom-Elliott @george1421 's black magic USB boot image, which he thinks you are correct about “ipxe kernel doing something bad to the init.xz before starting fos.”

[george1421]

@Tom-Elliott Sorry I was helping someone else in a chat session so I’m now just getting back to this.

Taking Tom’s specilation that iPXE was not managing the boot files correctly on this system for some reason, I asked the OP to usb boot into FOS as a test. We’ve had to do this in the past with a few other systems that just failed to pxe boot properly. The OP was able to usb boot into FOS so that told me the kernel and the init.xz were fine. I created the boot image on Apr 6, so the kernel and inits were current of that time.

Will this process work for now for imaging, yes. Is this a long term solution, I hope not. Hopefully either a iPXE kernel update or a firmware update on the target computer will fixed the issue so that PXE booting can continue to be used in the future.