Corrupt file in image?
Hi all. First off, sorry for the wall of text and pics.
My org has been using fog for about 2 years for imaging Windows machines. Each tech has their own fog server currently. My first fog server was built by another tech and provided to me, so I only had limited knowledge in how to run it - no context for building or maintaining. Recently, the Mac laptop we had it running on died so I decided to build one on a Windows laptop using the guide provided by the original tech. Installed Ubuntu 16.04 LTS on the box, made sure it was updated and had wget, and finally installed fog 1.4.4. No kernel updates to fog have been done. I uploaded the .csv provided for our last image and copied the image to /images. Recursive ownership and permissions have been set on the directory per our guide. I’ll provide that guide if anyone feels its relevant. The server is providing DHCP services and all that is working. I’m able to PXE boot the Dell Precision 5530 (connected to the switch via a Dell TB16 dock since there is no built-in NIC on this laptop) I’m trying to apply our Win 10 1803 image to, login to fog, select the image and it starts running.
At roughly 75% of the way through the block copy, errors are thrown:
pigz: skipping <stdin>: corrupted -- invalid deflate data (invalid code lengths set) pigz: abort: internal threads error
Image failed to restore and exited with exit code 1 (writeimage)
read ERROR:No such file or directory Args Passed: /images/Windows10-v1803/d1p4.img* /dev/nvme0n1p4
Running this again using a different driver for the NIC, I got pretty much the same errors, just a bit later in the process:
I have copied this image down from our repository several times now. I’ve inflated the .7z file on my Mojave Mac before copying it to a USB drive to move it over to the fog server. I’ve downloaded it from the fog server directly and extracted it to the desktop and then copied it to /images. I’ve tried just extracting the d1p4.img file from the .7z and then using rsync to get it into the /images/Windows10-v1803 directory. After moving the file(s) in there, I’m recursively updating owner and perms on the /images directory. Other team members of mine are using the .7z containing this image without any issue, so I’m assuming the source file is good.
I am at a total loss here. Does anyone have any ideas?
then it could also potentially be something far more silly such as a faulty ethernet cable.
Or faulty RAM in the client machine.
There’s definitely been a lot of improvements for nvme drives since then 1.4.4 as George mentioned.
Other than that, if the file seems to work fine on other devices, then it could also potentially be something far more silly such as a faulty ethernet cable.
Yep, I can try that. Ok, back to the mines.
Gonna install 18.04 LTS and grab 1.5.7 from git. I’ll report back once completed.
The issue is with the image file or (more likely) the target system’s storage media. I do see that your target system has an nvme disk. So that may be a factor too.
I see that you are using fog 1.4.4 with probably an old kernel. Do you have the facilities to spin up a new FOG server using a more modern version of Ubuntu as well as FOG 1.5.7 (the git version). This issue might have been already resolved in the releases since 1.4.4.