A year ago maybe I tried using a snapin to remove the old client and install the new one. I didn’t have any luck, I ended up using the hammer for it (group policy computer based startup script).

Good news I see the imaging process going through now. Problem fixed. Thanks Tom.

The holidays have officially begun here, so I will be unable to check on anything until at least 1/5/2017

But yes, I will perform all your recommended steps upon my return.

Happy holidays everyone!

Hi, I can’t help you, I’m French but I’m prefer to stay with english language
I tried to choose French on mamagement login page and in fog settings - General settings change FOG_DEFAULT_LOCALE with French also, but any change on display language.

@Maorui2k Package your own init using the source.

You can chroot into FOS while it’s uncompressed and change root’s password, then exit, and package FOS into an init.

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!