FOG USB Boot media with Intel NUC7i5BNH

[theland10]

@george1421 Ahhh, I see, thank you, I was able to successfully image another device with the FOS USB after queuing the task first in fog.

As for the NUC see below:

[george1421]

@theland10 Well that’s a good thing and a bad thing. The good part is both the network adapter (eno1) and the disk drive (nvme0n1) are being seen by the FOS Linux OS. The bad part is that there is no indication of what the actual error is.

Ideally we’d like to get a screen shot of the error that is displayed (it should be working!!).

let me think for a moment.

[theland10]

Here is the actual error in partclone when I attempt to capture from the NUC.

[george1421]

@george1421 On your FOS Linux usb stick, the grub.conf file you edited to include your FOG server’s IP address. There is a menu entry

“1. FOG Image Deploy/Capture” On the line that starts out with linux $myimage… append isdebug=yes to that line and save it.

Then reschedule a capture/deploy on the fog server and then usb boot the target computer and pick menu item 1. This will again put the deployment in debug mode. After you are dropped to the FOS Linux command prompt key in fog at this point you will be single stepped through your deployment. You will need to hit enter at each breakpoint. This should give you the option to capture the actual error message. Post the screen shot of the very first error here. If you can’t get the error we can then hit ctrl-C to access the command prompt again and then look at the partlone.log file to see why its unhappy. This partclone.log file will be on the target computer not the fog server.

[theland10]

@george1421 Ok, bad news and good news. Bad news is, I changed it and stepped through the debug process. It did not throw an error until on partclone and gave basically the same screen as can be seen here:

The good news is, on the image options in fog image management. I changed image manager from partclone Gzip to partclone Zstd and it is currently capturing fingers crossed.

[george1421]

@theland10 We’ll need to get one of the @Developers to look at the error, but it appears pigz was having an issue with a compression level 0 (??), which might explain why changing over to zstd solved the issue. You should be using zstd anyways but its that is a moot point.

[Sebastian Roth]

@theland10 I have not seen the pigz: abort: only levels 0 error before and I am not sure what it might mean yet. A quick search did not reveal much. I might need to take a look at the pigz source code to get an idea. Not sure when I will get to that though.

This is when capturing the image!?! So using the wrong compression settings on deployment of an image with a different compression is definitely not the case here. Maybe use Zstd and see if it comes out differently…

[theland10]

@Sebastian-Roth Yes, see my reply @george1421. Switching to Zstd I was able to successfully capture the image but it took much longer than when I had partclone gzip selected (~1hr 15min). When I attempted to deploy the image after capture I encountered an error and it did not deploy correctly. I changed to partclone uncompressed and successfully captured (much quicker this time to capture). I just successfully deployed my first image on another NUC.

Thank you both for all your help on this project. This thing has been a bugger, lol.

[Sebastian Roth]

@theland10 Does this NUC have a rotten CPU? Celeron or what?

[theland10]

@Sebastian-Roth Intel Core i5-7260U @ 2.2GHz * -shrugs- *