HP Spectre x360 13-ac050ca & 15-bl018ca
I’m getting the error below:
"XZ-compressed data is corrupt
–– System halted"
I’ve now tried a total of ten (10) HP Spectre x360 laptops, 13" and 15", this isn’t normally important except for the fact the 13" uses surface mounted RAM which in other threads and (i)PXE forums most discussion is with relation to the RAM and well I’m not about to attempt to switch surface mounted anything.
I have however switched the RAM on the 15" with new, different manufacturer sticks and yet the issue persist, and therefore I feel confident that it isn’t a RAM issue per se however I’m not all that familiar with Linux to say for certain that said I can say with certainty that it will boot Windows 10 Pro, Ubuntu without issue, I also ran a couple memory burn-in tests for good measure all of which came back negative for any faults with the RAM.
Steps to error:
- PXE boot
- At the FOG menu, choose from ‘Perform full host registration’, ‘Quick registration’, ‘Deploy image’, or ‘Client System information’.
- init.xz extraction completes and then the error comes up.
It is important that I mention that the FOG server is working fine with other machines tested.
I read in another forum where that person used an uncompressed image file and it works perfectly. This is great except I do not know how to do this for use with the FOG server. Any help would be greatly appreciated.
@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.
@agent_k What was it?
@agent_k Watch the chat bubble on the fog forum tool tray at the top for additional instructions
@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.
@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?
@agent_k well yes and no, but more no than yes.
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.
@george1421 Like this?
Host Kernel: /tftpboot/i386-efi/ipxe.efi or /tftpboot/ipxe7156.efi
Host Init: /var/www/fog/service/ipxe/init_32
@agent_k You had a question earlier about where these settings go (custom kernel and custom [unpacked] inits)
@Tom-Elliott You Sir are correct, 100% no help.
@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”.
@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.
@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.
@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…
@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.
trying ipxe7156.efi instead of ipxe.efi again
OK wait a minute here… you said your dhcp option 67 was undionly.kpxe where did the efi ones come from.
What mode is this device in? Since it has win10 on it. I might think it was configured for uefi mode, in that case undionly.kpxe is the wrong iPXE kernel.