@tom-elliott Hi Tom, sorry for the late answer, yes that sql statement solved my issue. Solved!

UPDATE globalSettings
SET settingCategory=‘FOG Boot Settings’
WHERE settingKey
IN (‘FOG_ADVANCED_MENU_LOGIN’,‘FOG_EFI_BOOT_EXIT_TYPE’,‘FOG_PXE_MENU_TIMEOUT’,‘FOG_PXE_MENU_HIDDEN’,‘FOG_PXE_ADVANCED’,‘FOG_KEY_SEQUENCE’,‘FOG_NO_MENU’,‘FOG_BOOT_EXIT_TYPE’,‘FOG_PXE_HIDDENMENU_TIMEOUT’,‘FOG_IPXE_MAIN_COLOURS’,‘FOG_IPXE_MAIN_CPAIRS’,‘FOG_IPXE_MAIN_FALLBACK_CPAIRS’,‘FOG_IPXE_VALID_HOST_COLOURS’,‘FOG_IPXE_INVALID_HOST_COLOURS’,‘FOG_IPXE_HOST_CPAIRS’,‘FOG_IPXE_BG_FILE’);

@george1421 helped out with sorting the command 😉

@culture20 FWIW, The developers put this document together a while ago. https://forums.fogproject.org/topic/6162/firewall-configuration

There is also guidance on selinux: https://forums.fogproject.org/topic/6154/selinux-policy

I have not heard of any issues having ipv6 enabled with FOG.

@brendojohnso The message is clear, the file system is not safe to mount. Look over this article and you should be able to fix it: https://wiki.fogproject.org/wiki/index.php?title=Windows_Dirty_Bit

@george1421 It is that model. And I am using 1.4.4 Fog (noticed there is 1.5) I honestly spaced checking the firmware I did see a 2013 date for it though which might be the issue. I work for a small company it is just a clients computer so I may see one again I may not kind of thing. If I get another one I will have to check the firmware I think you probably on to something. Thanks for the help again @george1421

@george1421 I just verified, that line is indeed in my fog.conf file. If you look through the code that is posted on that particular thread, the change has already been made in the code that is posted. But, I did open the file on my server just to verify. Like i said, it is correct.

@zago123 What exactly did you change. Other users might come across this and hope to find your answer.

@Kagashe Please post a picture of the error so we see what is actually going wrong.

Another question in addition to George’s:

Look in the fogsettings file: cat /opt/fog/.fogsettings and look for the field called username. What is it set to?

This username is the only account that FOG will set the password for. The default is fog.

Generally, users of FOG are quite notorious for setting up the OS with an account called ‘fog’ even though every relevant wiki article and every thread on the topic advises against it. Don’t know why really, I guess the universe wants it that way.

References:

https://wiki.fogproject.org/wiki/index.php?title=Password_Central https://wiki.fogproject.org/wiki/index.php?title=.fogsettings

@chris-whiteley Why not just put a fog storage node on the other side of the link. Then you wouldn’t run the risk of over committing your WAN. You can define a specific replication bandwidth. That IS something that fog can manage. You could even use an older dual core desktop computer as a FOG storage node. FOG Servers don’t need a lot of resources.

@wayne-workman it’s alright… Close this one please. Thanks.

@msi said in Snapin not running:

I checked the port 445. its open.

Then it’s likely just a DNS configuration issue: if the FOG server can’t resolve hostnames, then it can’t ping them. If you’d like help with that please open a new thread, though this is ultimately not a FOG issue, so it may be best to search other resources on how to configure DNS (assuming this is the issue).

ty solved

@x23piracy this is correct.

Based on the complexity requirements alone, this isn’t something easily done. Though depending on the version of FOG you’re using, you could create a crontab that could lookup all your hosts, see which are set to join the domain, and add any snapins you want automatically. You can even use the same principle during a deploy task through the use of postdownload scripts. Check if ad is to be used, if so, set the snapin for that host, and schedule that snapin task, then complete.

Of course i’m talking complex stuff to think about. But ultimately it’s not impossible, but it’s not automated in fog. Complexity level, i think, would be around a 6 or 7 on a 10 base scale meaning it’s not simple by any means, but it’s also not too hard. There’s some information on the use of the api system (assuming you’re using a version of fog with the api stuff) floating around the forums.

@wayne-workman said in Surface pro 4 gets stuck on init.xz (still):

@fry_p What caused it to be unable to image a Surface Pro 4? Has it ever worked at your location? When did it last work? What’s changed since then?

Hey guys. I realize more info is needed. However we don’t have another surface to test with. I can tell you it has been a while since we have done a pro 4. We did do a pro 3 with the same conditions without issue last week. It has worked at our location before albeit very sporadically with no rhyme or reason it seems. I’d say it has been months since the last pro 4, so I have updated FOG since then. I’m sorry I don’t have more info. If we get another pro 4 any time soon and if I am back to work, we will test. I suppose we can file this away for now. Right now, we only get 4’s for warranty replacements as the new Surface Pro is out so they are few and far between.

@george1421 I am on dnsmasq 2.76 and my ltsp.conf file is identical to what you posted.
All of my Dell’s are working 100% now. I am not sure why they did not initially, but they seem to be fine now. I will capture the pcap today with the Posiflex. Thanks!

@wayne-workman the fog client never handled this tasking.

The main tasking should work but we need to know what version of fog you’re using. Even then a new os may mean some manual intervention is required.

I’m back with some more info.
It looks like the problem was that udp-sender wasn’t started by the multicast manager service. If I restart the service, the udp-sender starts. I reboot the workstations and this time it starts deploying.

Thanks @george1421 Problem solved!

@voison If you have some time this weekend, I am willing to help you out via a screen share - PM me.