@scott-b I’ve written two sets of instructions on how to do this step-by-step, but ultimately all you’re doing is taking /opt/fog/snapins/ssl on the old server and moving it to the same spot on the new server, and then re-running the installer afterwards. have you looked over this yet? https://wiki.fogproject.org/wiki/index.php?title=FOG_Client#Maintain_Control_Of_Hosts_When_Building_New_Server

@pberberian can you look at this commit please: https://github.com/FOGProject/fogproject/commit/2aa8c0e2d998bacc304b6ac74ef86be5c52e21b7

You should be able to use that as a guide to add additional Linux OSs to the list, but they all still use the Linux workflow. I’m assuming you know what a pull request is? Can you create a pull request to fog’s working branch ?

@pberberian Instead of adding your own operating system names, we can just create a bunch of different operating systems for Linux - and they all use the same OS ID (which is Linux).

For example, The ChromiumOS one just uses the linux workflow, we added ChromiumOS to the list explicitly so that people would see it’s supported.

As for tags, that’s a different story.

@lemeunier That means this host has already had it’s encryption cleared, or it’s never been issued a token before.

@lemeunier In the mean time, try to reset this client’s encryption. That’s in the web gui -> host management. It’ll be a big button on the host’s general page.

@lemeunier First thing, uninstall any antivirus you have on that machine, reboot, and try to reinstall the fog client. See what that does.

@tywyn the largest difference is that SYSTEM is not allowed (by design) any interaction with the user or userspace at all. This probably also means the user’s account too. This is Microsoft’s design, not ours - and they went that route for security reasons.

When developing snapins, if your snapin will work manually but not as a fog snapin (and you’re sure you deployed the snapin correctly), you can normally assume the problem is because of the above.

Try what @Avaryan posted.

@sebastian-roth Looks like you fixed it, good job man.

We need a lot more information before we can effectively help.

• FOG Version
• Image settings screenshot for your image called TrainingImageFor3050 (find this in Image Management)
• Make/Model of target hardware
• Has this image been deployed successfully before?

@george1421 said in Climbing Imaging Speed:

The thing to remember here that transfer rate is actually not network bandwidth but the decompression rate of the image at the client.

It’s average write speed to disk.
Maybe we should just patch part-clone it so it shows actual write speed to disk & network transfer rate and also CPU utilization.

It’s possible the network admin has implemented some sort of traffic shaping on your network that is causing this behavior.

@lemeunier Hi, thanks for reporting this. What version of FOG are you using?

@sebastian-roth said in Fog Installer - Distro check:

As we don’t backport fixes to the master branch this one will be screwed with Arch for a long time I am afraid.

That’s how it should be. Also, looks like working branch failed again today.

@sebastian-roth Arch’s default apache root dir is very interesting: /srv/http
Anyways, I added that file to there and when viewing it via browser, I don’t see any indicators that gettext is on. Here’s a copy of the page:
https://mega.nz/#!EskiSSwT!Aj2px-ZMpwcDj90TBbpJRdB6G04AcBhrMR5WcPwlj6g

Got a error on Arch across all branches this morning from apache:

[Mon Dec 04 07:43:13.301115 2017] [proxy_fcgi:error] [pid 2547:tid 140160016578304] [client 10.0.0.26:34968] AH01071: Got error 'PHP message: PHP Fatal error:  Uncaught Error: Call to undefined function _() in /srv/http/fog/commons/text.php:22\nStack trace:\n#0 /srv/http/fog/commons/base.inc.php(41): require()\n#1 /srv/http/fog/management/index.php(22): require('/srv/http/fog/c...')\n#2 {main}\n  thrown in /srv/http/fog/commons/text.php on line 22\n'

Looks like something in Arch’s repo broke this since it was in all branches. Other distributions are fine.

@andreiv I moved your last post to here since it’s a separate issue that you found: https://forums.fogproject.org/topic/11157/checking-schedule-shutdown-after-task-completion-causes-the-running-task-to-hang/2 Please follow it there.

Moving a post from another thread about a bug to here. See below. @developers

@sebastian-roth said in Issues with FOG services:

Don’t think a re-install would have cleared the left over entries in the DB. At least not that I am aware of.

The FOG Installer does not DELETE anything from the DB at all. The most it even does is A). Make a new database or B ). Upgrade an older schema database to the latest schema.

A little fog history:
There’s a great number of problems that re-running the installer will FIX though. FTP Passwords are one I pushed hard and helped with. So if the FTP passwords (storage management node passwords used for FTP purposes) are not correct for a node, all kinds of crap breaks in FOG and tons of people were needing help diagnosing & fixing that, so we changed the fog installer to just fix it every single time for all storage node Addresses that match the local machine’s address. This fixed the FTP password problem basically instantly for both master nodes and storage nodes for everyone.

@andreiv said in Issues with FOG services:

checking the “Schedule Shutdown after task completion” causes the task to hang (remain unfinished).

That feature doesn’t work for you?

@andreiv said in Issues with FOG services:

The next time I have to deploy I am going to do a test and deploy twice, once with that checkbox checked and once unchecked and I am going to capture a video of the last steps of the process on the client, to see what happens.

Please do.

I think @george1421 is right, it really seems like a uefi image was deployed to a bios system.