This is a known issue. In systems with two NICs, the 1st NIC in iPXE isn’t always the 1st NIC in FOS (fog operating system). This messes with tasking. Also, I’m not entirely sure if both NICs or just the first NIC gets registered.

A long while back, I suggested that we should loop through all the NICs in FOS and try to get an address on them one at a time, and with each one try to contact the FOG Server from each. Once a NIC is found to be successful, exit the loop and proceed.

Some clarifications:

Snapins
A snapin is simply a way to get the client to run an executable. So why is there no EXE template? Well on windows .exe can simply be executed as is without a helper program. So no snapin fields have to be set. Imagine snapins like this:

Open a CMD prompt How do you want to perform your action? Is it an EXE? If so you just type MyProgram.exe and it runs. Want to run a batch script? You’d type something like cmd.exe /c MyScript.cmd. The bottom Snapin Command shows the end result of your snapin configuration

Snapin Packs
Now snapins are pretty limited, but that’s what legacy FOG was built with so we kept it for compatibility. In your post you say I generated a “SFX” silent printer installer that’s a work-a-round that snapins forced onto people. And when the new client introduced Linux and Mac support things like the SFX work-a-round were no longer viable as it’s Windows only.

So we came up with a concept being being able to “pack” up multiple files and deploy them using the pre-built snapin system (ergo “Snapin Pack”). I’ll admit we don’t have the best documentation when it comes to things like Snapins and Snapin Packs but it’s community driven documentation. Where people think it lacks, they add to the documentation.

@Wayne-Workman has done an awesome job providing almost all of the snapin pack documentation we have (https://wiki.fogproject.org/wiki/index.php?title=SnapinPacks).

The basic idea: zip up a bunch of files you need, and provide 1 runnable file/script in that zip to handle everything (e.g. a batch script to move all of your printer driver files in place).

If you’re using the default script, I believe it looks for /dev/sda, which nvme drives aren’t.

You’ll need to alter the script to a more universal version, I believe there’s a thread where some people were working on that a bit.

Thanks, that did it. I was able to push down the old images. Tks

@Tom-Elliott thanks, we managed to push the image with our work around in time, I can try your fix out soon when we re image the machines

I tried a few kernels and confirmed the issue is related to kernel version, kernels older than 3.14 worked in my host.

The exception might be an exception… I could not reproduce it.

Also just adding tidbits of info to the discussion, 0.32 and 1.2.0 used the same FOG Client. If it worked in 0.32, it most surely can work in 1.2.0.

Also, at this point I’d advise just using the release candidate of 1.3.0, it’s worlds beyond prior stuff.

@ethompson66 Thats great to hear it was just a driver. Some time down the road we can talk about having a universal image (that is sysprep’d) and injecting the model specific drivers during FOG imaging. That is what we do for our Dell fleet.

@Tom-Elliott working good now, thanks!

Thank you for your help.

Best regards.

i dont know how to update topic status to solved

Thanks a lot for the help, it is working.

I believed that the “fog.advancedlogin” menu item is itself the advanced sub-menu item, and every other menu item that i configure to show with " Advanced Login Required" will be an item in that sub-menu. Since that was not working i fuzzed with fog.advanced, and fog.advancedlogin, menu visibilities, and the "advanced menu login.

TBH now i’m very confused, but at least i have a working solution. Thanks a lot again.

@Albertus The hosts that aren’t working, please place them into a group and select:

Reset Encryption Data

I’m seeing the message:

2016/12/14 4:28 PM Middleware::Response Invalid security token

@Warrender6 Here’s an example. You should just re-write this whole configuration. ISC-DHCP can support both BIOS and UEFI at the same time, you don’t need to go in there commenting and uncommenting filename lines.
https://wiki.fogproject.org/wiki/index.php?title=BIOS_and_UEFI_Co-Existence#Example_2

Updated to RC36, and both full & quick registration worked as expected!

I found nothing abnormal in the interfaces. Not knowing what to do, I completely reinstalled my virtual server, which restored the functioning of fog. Thank you for your answers

Did FOS in 1.2.0 reboot on error in 1 minute or 2, I thought it was 2?

@Olduser are you creating a pack or a normal snapins?

If others of the same model work, but only some have issues, it could be a hardware issue. You could try updating the firmware, or try swapping the HDD with one from a working system and seeing if that makes a difference or not.

@Quazz Thanks, this will work, setting it to 87000 so it is just over 24hrs, that way I can unthrottle it and have the service start at 2am. Each image takes about 30 mins so I cannot imagine this being a problem at 7am when people start showing up. Thanks!