@Tom-Elliott If you want a whole slew of fog.log files from these hosts I can provide them or I can deploy some debugging scripts if you want since it seems like I can reproduce the issue on command currently. I can even send you our image for testing if you’d like.

For reference we’re using a gold master image with the auto driver install method from the wiki. The only software installed in the image is the FOG Client 0.11.5 with the FOGService set to “Disabled” before sysprep. We are using a KMS key so setupcomplete.cmd runs after without an issue. As part of the auto driver install we push up a fresh copy of setupcomplete.cmd right after the image is finished deploying that contains the follow:

net STOP "FOGService"
start "Reset C:\Drivers Perms" /wait "icacls" C:\drivers /reset /T >>"C:\FOGDrivers.log" 2>&1
sc config FOGService start= auto
shutdown -t 0 -r

I did notice on the run that I left over the weekend that the client did try to update and then started throwing the errors so I updated the client in the image before retrying. After that deployment all clients exhibited the issue immediately. I can provide the logs from that second run.

Oddly I don’t see this issue if I only image a single station but if I image the entire batch of 24 it seems to show up consistently. As I mentioned I noticed that the server was getting hammered with sha2sum processes as soon as the clients start checking in with a full batch of 24. The specs on the VM the server was running are 1 core 2.7 GHz, 4 GBs RAM, 10 Gb VMXNET3 Ethernet. I have since upped this to 2 core 2.7 GHz and 8 GBs RAM but have yet to retest just in case you need me to reproduce this issue.

Should that be necessary immediately after being imaged though? It seems odd that I’d need to do that on a freshly imaged machine right after it changes the hostname and joins the domain.

Looking at the FOG server it has maxed out it’s CPU usage from a whole slew of sha512sum processes now and is intermittently dumping me to the database schema installer/updater screen when navigating the web interface.

EDIT: I was able to get back to a stable web interface by shutting down the entire batch of clients that had just been imaged. This allowed me to reset the encryption on one of them to test this out. It does appear to fix the issue for the client. The web interface issue though seems to be a legitimate bug as 24 clients checking in while in this state were able to completely cripple it. I’m going to reset the encryption on all of them, start them back up, and see if the web interface stays stable.

EDIT #2: I went to the group that this batch of laptops are a part of clicked on “Reset Encryption Data” and then clicked “Update”. After that I started them all back up and am receiving the same error messages as before. I tried “Reset Encryption Data” on one of the individual unit’s host entries as well while they were all still running. This didn’t correct the issue for that unit like it did when I tested with only the single unit. With all 24 clients powered on the web interface is getting increasingly sluggish but is yet to become unstable.

@Joe-Schmitt Thinking of it that way I see your point. I hadn’t considered the malicious halting but now that you mention it I could see that being a major issue. I withdraw my request/suggestion on this one. Thanks for the time to explain your thinking.

Server

• Version: 1.3-RC8
• OS: CentOS 7

Client

• Version: 0.11.5
• OS: Windows 7 Enterprise

Description

On Friday when I left for the weekend I kicked off an imaging task for a group of laptops. When I came back on Monday I found a number of them had not completed their hostnamechanger or snapin tasks and were logging two middleware errors every time they checked in with the server.

Middleware: :Response ERROR: Unable to get subsection
Middleware: :Response ERROR: Object reference not set to an instance of an object.

Figuring it was just a fluke I set them all to re-image and now all of them produce the same result immediately after the reboot for joining the domain. I’ve rebooted the FOG server as well just to be sure but the issue still persists after that as well. I did notice while rebooting the FOG server that it hung shortly after being issued the reboot command so it had to be hard powered off; may be unrelated but figured it was worth mentioning. I can provide any logs needed to troubleshoot.

Well it looks like this is definitely a problem with this model of laptop. The Windows 7 Enterprise installer finished copying and expanding all of it’s files and then as soon as the first reboot happens the computer hangs at the same black screen I receive after imaging it. Looks like I’m destined for the HP support line to kick this up the chain for a fix :(.

Edit: I just rebooted without the network cable plugged in and now the installer continued without an issue. More testing needed but maybe an issue with how the FOG boot menu is handing back off to the boot cycle on this model. I’ll update once I’ve done more thorough testing.

Edit 2: The solution for this is that the “Host Bios Exit Type” for this model must be set to “GRUB” or it will hang before the OOBE portion of the Windows install process starts. “SANBOOT” causes this 100% of the time on our units and “EXIT” returns an error. Presumably any of the “GRUB” options would work but I haven’t verified any other than the basic “GRUB” option.

@Wayne-Workman @Quazz I checked HP’s site and they don’t have any firmware or BIOS updates for this model beyond what it shipped with currently. Good thought though; wouldn’t be the first time I was shipped something that had buggy firmware right out of the box.

On a whim I tried imaging one of the units and then attempting to install a fresh copy of Windows just to see if it made a difference. Oddly enough this allowed it to go past the missing drivers without a hitch so it must be either picking them up from the hard drive repository or my previous attempt failed to load something critical off of the DVD. Either way the install seems to be proceeding so once that’s finished I’ll build out a new sysprepped image and see if that will deploy to these.

@Wayne-Workman That’s the same thought I had. I’m trying to track down what driver is the cause of the installer halt currently. Oddly enough on a unit with the HP image on it both the hard drive and CD/DVD drive hardware IDs show as SCSI devices but no SCSI controller is listed in device manager. My current thinking is they must be running the CD/DVD drive though the USB system since the SATA controller driver doesn’t appear to correct the problem. Once I track it down I’ll post up the solution so that other can find it if they’re in the same boat as me.

@Wayne-Workman I’ve followed all of those steps for the master image prior to capturing it. The image works great on all of our other hardware so it’s something specific to the 650 G2 that’s causing it from the looks of it.

I did try to install a clean copy of Windows 7 Enterprise right from the install DVD and it gets hung up needing a driver for the CD/DVD drive of all things. Seems like HP is doing something non-standard with the hardware in these units to cause an issue like that. My guess is that they’re using something other than a standard bus and that’s what causes both issues but it’s just a hunch at this point.

I’m a bit baffled by this one so hopefully some of you have had success with this model and can help me out. We have a stack of HP Probook 650 G2 (L8U45AV) that seem to freeze immediately after the “updating registry” step of the Windows setup process just prior to the OOBE starting. The screen goes black and all hard drive activity ceases. I left one on overnight just to be sure and it’s in the same state this morning. This is the only model of computer that I’ve run into any problems with while using our hardware agnostic gold master image. We’re using the auto driver install method from the wiki to push drivers into the image but I don’t think that’s the issue since it’s not getting to the OOBE step that loads drivers. We’re running FOG 1.3 RC8 currently but I doubt it’s a problem there since the image deploys without issues. Our master image is built in VMWare with Windows 7 Enterprise and is completely bare bones (ie it has updates installed, a few registry changes, and the FOG Client installed). If I can’t solve this my last ditch solution is to build a new gold image on one of the units and try to deploy it to the rest of them. I’d rather not have to do that unless absolutely necessary though.

@Tom-Elliott I’m wondering if just a simple process check for msiexec and the like before starting snapins would address detecting installs.

As for the exit codes my feeling is that since these are generally standardized for most installers a simple success/failure/unknown message based on a general group of codes for each category would be helpful. If this isn’t the intended behavior already then that would fall under a feature request as well but if it is meant to do a check there then, at least for the 1618 exit code, it’s not serving the correct message.

@Wayne-Workman In this case it was the first snapin in the chain that spit out the 1618 so I’m guessing a Windows update or GPO install hadn’t quite finished with msiexec yet in the background. All of the installs specifically handled by the FOG client waited appropriately so it doesn’t appear to be an issue there.

I’m using RC8 with client 0.11.5 and noticed that the messages given by the FOG Client don’t accurately reflect the exit codes of failed snapins. For example I have a snapin that exited with code 1618 yet still received the “Installation has finished and is now ready for use” message. Since a 1618 means that the installer halted due to another install being in progress the software didn’t install at all. Since the exit codes are being logged it appears that either they’re not being checked before the message is sent or the checking is broken.

Tangential to that it would be nice if the client could detect installs in progress and delay snapin execution until they’re completed but that’s more a feature request than a bug.

Let me know if you need any log files and I can provide them.

After reading Tom’s reasoning I tend to agree with the warning instead of recreation. I knew what I was doing when I deleted it and simply forgot to recreate it before continuing testing today. The warning would have given me a nice reminder to fix what I broke :).

I noticed a bug/omission on the RC5 installer when upgrading this morning due to a mistake on my part from prior troubleshooting. If an admin has deleted the home directory for the ‘fog’ user but left the user account otherwise intact the installer doesn’t recreate the home directory when checking if the ‘fog’ user account is configured. This causes image captures to fail with an ftp error when the script tries to switch to /home/fog (which doesn’t exist). Recreating /home/fog and changing ownership/group to ‘fog’ fixes the issue. I can provide the exact error message from the httpd ‘error_log’ file if needed as well.

I only see an empty ‘fog’ directory in the /home location. I removed it and re-ran the installer but got the same result.

Ran both of those and verified directory removal. Re-ran installer; fails out with the same message.

I’m having an issue with the installer for RC4 not working correctly on CentOS 7 that appears to be a bug. I followed the wiki steps for installing on a fresh install of CentOS 7 using git but the installer script fails out at “* Copying new files to web folder” with the error message “cp: cannot overwrite non-directory ‘/var/www/html/fog/fog’ with directory ‘…/packages/web/fog’”.

When I took a look at ‘/var/www/html/fog/fog’ I noticed that it looks to be a symlink back to ‘/var/www/html/fog’ which is why cp is failing out. Deleting the symlink before rerunning the install script doesn’t correct the issue and neither does manually running the failing cp command sans the final /fog so it seem like the installer is creating the symlink that’s causing the issue. Any help would be appreciated. Please let me know what log files, if any, are needed to track this down.

Thanks for the official response Junkhacker it saves me from spending the day looking into it on my end :).

That’s the same result I got gimili. I did notice that there is still talk about Green FOG in the new client development thread here: [url]http://fogproject.org/forum/threads/new-client-progress.12136/[/url]. Hopefully that means it’s either coming back or getting fixed if it’s broken for more than just us. I’m pretty sure I saw one of the devs say they were overhauling Green FOG to be able to do per group/PC tasks but I can’t seem to find where I saw it now. I’ll let you know if I find anything that fixes it.

One thing to check is to make sure that you’ve set your timezone in php.ini. Be sure to reload/restart your apache service after making the change or it won’t take effect. I had forgotten to do make that change on my new install and it wasn’t sending the shutdown/reboot requests at the expected time as a result. I’m running some tests tonight to make sure that corrected the issue for me and will let you know if I’m successful or back to the drawing board.