FOG USB Boot media with Intel NUC7i5BNH

  • Hello, I work with a company managing ~2000 devices. We’re rolling out windows 10 and ran into problems with our current imaging solution not pushing drivers for some AMD systems or Intel NUCs. I found FOG project and we were able to set it up successfully. We already have a linux based virtual pc deployment system set up on our network to PXE boot so we have been using FOG with USB boot media. I used to create the EFI file. Have successfully captured and deployed images for multiple HP models (including the AMD systems we had problems with) but have been unable to get our NUCs to boot to fog.

    We have the Intel NUC7i5BNH model. It gets to "Configuring net0 macaddress… and times out with error “no config methods succeeded” which only flashes on the screen for a second before it reverts back to the bios boot menu.

    Our FOG version is 1.5.6. Any insight is appreciated

    Thank you!

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

  • Senior Developer

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

  • @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.

  • Senior Developer

    @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…

  • Moderator

    @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.

  • @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.

  • Moderator

    @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.

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

  • Moderator

    @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.

  • @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:

  • Moderator

    @theland10 said in FOG USB Boot media with Intel NUC7i5BNH:

    Fatal Error: Unknown request type :: null

    This error can be tracked back to one of the caveats of this process. You MUST schedule the task on the FOG server before picking option 1 from the grub menu. If you do that then imaging will work. This is one of the issues without using iPXE. You loose the tight integration with FOG. But sometimes you have no choice.

    Now for the NUC…
    From the FOS Linux usb boot device, select option 6 for debug mode. Once its booted you will be dropped to the FOS LInux command prompt. Key in the following commands to FOS Linux

    1. ip addr show
    2. lsblk

    Based on the results of these commands we have a few more, but lets see which direction first (networking or disk).

  • @theland10 No luck with the FOS Boot stick. On the NUC7i5 tried to capture and partclone gives an error with the text broken and spread across the screen, part of it says ‘Maybe check the server to make sure space is good to go?’.

    Tried imaging one of our other HP models that I have successfully captured and imaged with the regular USB boot media and receive the following error:

    Fatal Error: Unknown request type :: null

    Kernel Variables and settings:
    boot_image=/boot/bzimage loglevel=4 initrd=init.xz root=/dev/ram0 rw ramdisk_size=127000 keymap= web= boottype=usb consoleblank=0 rootfstype=ext4.

    Tried with both original bzimage, bzimage32, init.xz,init_32.xz files and files from our fog server.

  • @george1421 Yes, I got it! I tested and was able to successfully register the device as host with both quick and full registration options. Will test deploy and capture tomorrow. Thank you!

  • Moderator

    @theland10 I did add some hints for booting straight into FOS via usb in the forum chat. Look at the chat bubble in the upper right corner of the browser window.

  • @Sebastian-Roth I was confused about that myself. The is our fog server. is the server for our virtual devices we have set up for PXE booting, and the reason why we are using the USB boot media as opposed to using straight PXE booting for fog. That IP was not entered anywhere in the setup on rom-o-matic for the efi file. I’m going to try a slight change to the script on that.

  • Senior Developer

    @theland10 Hmmmmm, in the picture I see Received DHCP answer on interface net0 … Looks very different to what you told us before. Maybe debugging causes different timings within the driver and make it work?!

    The error in the picture makes me think that maybe the default gateway option is not properly propagated to the client and it cannot reach IP because of that?! Why is the IP different on the first TFTP pull (ipxe.efi) than on the second one (default.ipxe). Possibly it’s for a good reason but things just don’t add up for me here.

  • @Sebastian-Roth Here is the output from the debugger: Debug2.jpg

    Also, our resident linux guru (I’m very much a beginner but I pick up quickly) and myself have been trying to set up the FOS Linux boot stick in the meantime. We are able to get to the selection menu to choose quick register/full register/capture etc. It sees both our DHCP servers and pulls an IP ok but ends with an error unable to access FogserverIP/fog/index.php or FogserverIP/index.php.

  • Senior Developer

    @theland10 Then I suppose we are down to the bones and need to enable debugging in iPXE. When requesting a binary from rom-o-matic there is a field Debug build. Put intel into that field and you should get some more output - fancy in colors.

  • @Sebastian-Roth Yes and yes. That ifstat output was directly after ensuring I had link lights from replugging the Lan cable. Which was directly after entering the ipxe menu from a failed boot using the intel.efi