@palloquin alright. I ask because the output of your sestatus command indicates some modifications of other selinux files (e.g. /sys/fs/selinux/deny_unknown and /sys/fs/selinux/mls). In general all that is needed to make SELinux permissive is to run:

• setenforce 0 to set the runtime selinux enforcement policy
• Edit /etc/selinux/config to read SELINUX=permissive instead of SELINUX=enforcing

But since selinux was already disabled, there’s no point in doing this now (your server setup will be fine and everything should work as normal). I do want to point out though to any @Moderators who maintain the wiki that tutorials should not instruct users to disable selinux, but instead set to permissive.

@palloquin how did you set SELinux to permissive mode? To repeat, permissive mode will absolutely work if completely set.

To expand why disabling SELinux is not advised: SELinux works by labeling files on your system. In permissive mode the labeling still takes place, but no policies are actually enforced. But when you disable SELinux that labeling system is shut off. To re-enable SELinux once disabled, it’s going to take some time. You would first have to set SELinux back into permissive mode (NEVER set back into enforced once disabled unless you know SELinux well). Once your kernel boots back into permissive mode, you would need to initiate a full filesystem relabeling which can take some time. Once that finishes you can finally safely enable SELinux.

@Quazz that is incorrect. Permissive mode will absolutely work if configured correctly.

@palloquin selinux should be left permissive. Disabling it is strongly advised against, since it requires a bit of work to properly enable selinux once disabled.

@Wayne-Workman if there’s enough demand for such a snapin I can make it (It just requires some know-how concerning the design of the legacy and new client).

@pixomondo said in New Fog Client - The Computer Restarted Unexpectedly:

In the past I used to deactivate the fog client to prevent it from rebooting the machine while sysprep was running and this seemed to have fixed it again

That’s exactly what the link I gave you (the wiki article on sysprepping) says.

@zacksiga If you’re willing to have your server run SEPermissive for a little bit, I can assist with creating a policy from the collected data, and if it works I’ll update our main repository with the new policy.

@Ric41 teamviewer usually will take TeamViewer.exe /S as a valid parameter (note that it is capital S). However teamviewer likes to start itself after being installed, so you would probably have to get the PID of the spawned process and kill it after the installer finishes.

@pixomondo said in New Fog Client - The Computer Restarted Unexpectedly:

fog prep VM reboots after sysprepping

Two things:

1. FOGPrep is no longer needed
2. https://wiki.fogproject.org/wiki/index.php?title=FOG_Client#FOG_Client_with_Sysprep

@sapeurorca legacy client issues were fixed in 1.3.4 RC 1 (https://news.fogproject.org/fog-1-3-4-rc-1/).

As for the new client, it uses a different field for setting the AD password (since FOGCrypt is not used anymore). Make sure the new field is set.

The log says ‘Shutdown aborted by calling module’. That means the server is telling the client to abort. @Tom-Elliott server issue.

@alv000h FOG already removes page files (swap) and hibernation files on capture.

Yup. You can thank @tom-s for the name.

@Wayne-Workman setupcompletes are .cmd he probably had .bat

@kyle.heath you need to fix this error:

1/10/2017 10:30 AM HostnameChanger Logon failure: unknown username or bad password, code = 1326

before anything else. You don’t need to keep on re-capturing or deploying either. Just set up a computer with the client, monitor the fog.log file until you fix your credentials.

@Quazz better?

nl-BE

@Quazz is this correct?

nl-BE

@x23piracy, oh sorry. Yeah that’s not an issue with how the translation files are built.

@x23piracy if the client cannot match your system’s language to a translation file then it defaults to english already.

@kyle.heath use the snippet i posted (remove the net start FOGService in yours). Manually starting the client is hit or miss right after sysprep and especially if you are invoking a shutdown it will cause many issues. I’m still working on better sysprep integration with the client, but it’s difficult work.