Posts made by gwhitfield

@Sebastian-Roth VMWare 5.5 workstation

@Boyan-Biandov I also have basically re-used my Win7 unattend, though I did run it through the Win10 SIM to validate it. The only place I put it is in C:\Windows\Systems32\Sysprep folder. However, I have had the “Windows could not parse…” error and in looking at the setuperr.log in C:\Windows\Panther\UnattendGC folder (this one is different than the setuperr.log in C:\Windows\Panther, I don’t recall how though), it pointed me in the general direction of the <ProductKey>xxx</ProductKey> entry in “Specialize” pass. I ended up removing all product key entries and don’t have the error anymore. I have never really used audit mode, I just enter product key during installation and run “c:\Windows\System32\SLMGR.VBS” /ato" to re-activate after imaging (in setupcomplete.cmd). Good luck!

Edit: Forgot to mention that it always seemed to me that the unattend in C:\Windows\Panther was a post-sysprep record with all the sensitive data removed from the file by Windows as it processed it. I never before ran into any instructions to put it both places so I never have. Now if someone could tell me how they make the Win10 Default User profile keep the pinned icons on the taskbar I’d be the happiest camper alive.

@Sebastian-Roth @Wayne-Workman I have noticed that using REFIND_EFI almost works, but I’m presented with a prompt to “Hit any key to continue”, at which point if I press the anykey my system boots properly. I have tried editing the refind.conf file to include “also_scan_dirs” to include \EFI\Microsoft\Boot where the boot loader resides but can’t seem to bypass the prompt to press a key. In boot.php I see:

:fog.local
imgfetch ${boot-url}/service/ipxe/refind.conf
chain -ar ${boot-url}/service/ipxe/refind.efi || goto MENU

I don’t suppose the prompt is can be bypassed by something in the boot.php script?

EDIT: I tried earlier to mention that my upload image task works fine, it’s just when rebooting afterwards, or when there’s no task waiting that the boot appears to fail. Now I’m not so sure it’s even a FOG problem, but rather refind.efi that’s not quite doing what we’re hoping. I see in the documentation that is doesn’t recursively scan the possible boot folders, maybe it’s just not getting to the boot loader.

I haven’t done any UEFI booting in months and ran into this error this morning (Trunk 8499 - just updated):

I found and edited my copy of the default.ipxe file but thought I’d mention it since maybe an error has crept into it on SF.net.

@Joe-Schmitt Having same issue on trunk 8415 version client 11.2, happening on Win10 CBB, Win 7 and VMWare machines. Is client 11.3 available that I could try it out? I also have it setupcomplete.cmd but had to add startup task running a bat file containing only “net start FOGService” that delays 90 seconds. This does seem to work if it’s of any help. Just seems to be a timing thing.

edit: Noticed service isn’t running immediately after installation either, this being on a WIN 10 CBB VM (1511). haven’t tried on physical hardware just yet.

@Wayne-Workman @Joe-Schmitt I’ve had some initial success with using a “net start FOGService” batch file as a boot time task. 100% so far in 3-4 individual attempts, just haven’t proven it out as 100% successful on a large group of 790’s. If I find the crazy driver that’s doing this I will report back in this thread.

The client works on everything I have newer than the 790 both with LTSB and CBB images (both 10240 and 1511) , and has been perfect in Win7 on every machine I’ve tried, even MUCH older ones. In the long run (for me anyway), as the legacy machines go away hopefully it becomes a distant memory. I don’t envy you trying to deal with demon ninja gremlins of various operating systems and hardwares!

@Joe-Schmitt Well, no good news to report at the moment. I remembered this morning that Dell doesn’t offer Win10 drivers for the 790 so it’s extremely difficult to tell whether the “correct” drivers were installed by Windows. There are no obvious problems in Device Manager. I have toyed with several ideas:

1. Creating a scheduled task to “net start FOGService” that I can either set up in Task Manager prior to sysprepping the image, or to use GPO to push the task (which of course doesnt work if the machines aren’t joined to the domain yet).
2. Since I have been pushing drivers using Lee Rowlett’s scripts, maybe I’ll stop doing that for the 790 and let the Windows install figure them out, maybe it will come up with different ones than I was sending.

So many projects underway, it may be a while before I can get through these tests but I’ll let you know what happens as I do them.

@Joe-Schmitt Joe, I edited my post (a couple times now) of logs to include a machine that DID join the domain, but then the service didn’t restart after the second reboot. These have both been manually rebooted a couple times since and the service refuses to start.

There IS one machine which seems to have experienced the same failures (non-joining domain and service start failure), but after a single manual reboot, the service did restart and the machine joined the domain and the service has continued to successfully restart during multiple manual reboots since. Unfortunately I will have to wait until tomorrow to get those logs since this machine is sleeping soundly and won’t wake-on-LAN.

EDIT: reading back early in the thread I find it may help to note these machines are WIN 10x64 LTSB (10240)

Thanks for your help and Wayne’s input as well!!

@Joe-Schmitt - Trunk 8257 - Joe, I had client 11.2 deploy to 25 Dell 790 machines today as a test and only 2 of them joined the domain. They all renamed but the service doesn’t appear to restart after the first reboot. No logs on PC after first shutdown command. I am attaching a fog.log from one of the machines and the apache error log during the time of the task. Hopefully this will tell you something:

APACHE ERROR LOG IMMED AFTER IMAGING COMPLETED
1_1467056255448_apache error 11.2 client non-restart.txt

APACHE ERROR LOG NEXT 60 MINUTES
0_1467072182110_apache err 11.2 next 60 minutes.txt

MACHINE THAT DIDN’T JOIN DOMAIN - 192.168.132.165
0_1467056255444_fog.log
0_1467060379059_zazzles.log
0_1467060828192_.fog_user.log

MACHINE THAT DID JOIN DOMAIN - 192.168.132.154
0_1467071798888_fog.log
0_1467071815418_zazzles.log
0_1467071823241_.fog_user.log

Oddly, I don’t have this issue on all machines I’ve been working on, mainly Dell 7020 and later. Maybe it’s a problem with the older hardware keeping up??

Edits: I found the zazzles log and user log thought that may also help so I just uploaded them. Seems like a clue here but fog.log hasn’t changed any since it stopped at 1:36.

@Joe-Schmitt Sweet. Will do!

@Joe-Schmitt I am having a similar issue though I have already updated to client 11.1 after I read this post a couple days ago. Ubuntu 14.0.4, FOG trunk 8095. In a lab of 25 Dell 790’s I had 10 or so not join the domain. I found the FOG service not running on each of them. I had no problems with my lab of Dell 7020’s or Dell 7040’s, both of which have better processors and more memory. The fog.log has no errors, immediately after imaging it commands a shutdown to rename/rejoin and then the logging stops. Unfortunately I am off-site until Monday so I can’t reach a machine to test much but I am trying to get one of my slower VM’s tested to see if it happens there.

@Wayne-Workman Thanks a ton for you offer to assist!!! I’m going to put these servers right. Need to read up on how environments change in Linux as I’m guessing it has to do with my problem. Live and learn! This should be marked solved I think as we can reasonable guess the problem is hidden in how the server was built/upgraded in the first place.

@Wayne-Workman I have been working on this as much as possible today and realize that my process was built on old instructions, that there are more recent instructions to do this. Specifically in how I have been logged in as my admin account rather than root (sudo -i) and using sudo to get me by, as well as the location of the installation not being /root/fogproject/. I have cleaned that up and feel pretty confident I can produce a better server. My boss has allocated a bit more time to this so I’m prepared to rebuild these servers. We can skip the TeamViewer session if it’s a hassle for you, I just don’t want to cause you any troubles. If you feel it’s something important to look at I’m all for it though?

@Wayne-Workman I can do that. Thank you!

@Wayne-Workman Simply trying to not waste anyone’s time, that’s all. I don’t look forward to re-doing 15 FOG servers but being a linux noob makes troubleshooting super difficult.

So anyway I just now tried what Tom suggested and it didn’t work. Logged in as my “administrator” account. Entered “sudo -i” and re-ran the installer. Rebooted and logged back in as “administrator”, FOGMulticastManager service is not running. Ran "sudo -i " and tried to restart service and it would not. Tried stopping the service, then starting again and it would not. tried restarting and it would not. I also believe it probably has something to do with dependencies and permissions that got changed somehow by the process I was following to do trunk updates but I have no idea where to begin, just not that Linux savvy.

@Tom-Elliott My best bet may be to simply rebuild these servers and quit everyone chasing this. I have tested saving the hosts and images on the original server to another location then replacing them once the update to trunk is done from 1.2 (where I last snapshotted it). I’m multicasting just fine with this one now. Not knowing what caused it leaves me open to doing it to myself again but with good backups I don’t suppose it’s necessary to get too wrapped up in it unless there’s something we can all learn from it. I’m going to have a couple problem servers available for a while as I’m not going to get to them all in the next several weeks.

@Wayne-Workman - I have yet to compare the folder rights but will do so tomorrow in HIGH hopes its as simple as changing them to mimic a working installation.

Thanks to both of you gentlemen!!

@Tom-Elliott It doesn’t appear to help any, the log files still aren’t being created and the FOGMulticastManager service still isn’t starting. Unfortunately I don’t really understand how to use “sudo” I guess. When in terminal mode (using PuTTY, not GUI) I only append it to a command if I get an “access denied” response to the user “administrator” that I’ve created and I’ve done that a thousand times when upgrading to trunk.

I’m wondering now if there isn’t something in my upgrading process that left me vulnerable to this issue. I follow these instructions I got off another post:

1. Log in as Administrator
2. Run “sudo apt-get autoremove”, enter root password and approve
3. Reboot server (“sudo reboot now”)
4. Run “sudo apt-get update”, enter password
5. Run “sudo apt-get upgrade”
6. Run “sudo apt-get install subversion” - (Go to Step 9 for any server already at Trunk since svn folder is already created)
7. Enter “cd ~”
8. Enter “mkdir svn”
9. Enter “cd svn”
10. Enter “sudo svn co https://svn.code.sf.net/p/freeghost/code/trunk”
11. Enter “cd ~/svn/trunk/bin”
12. Enter “sudo ./installfog.sh”
13. When prompted, open WEB GUI and update database per the prompt

@Tom-Elliott I created a user “Administrator” for all GUI interaction so I’m always logged into the GUI as that user. I don’t really ever use the GUI terminal though I have been using root when connected on my Win10 desktop via “WinSCP” to move or copy files such as the scripts for hardware independent driver installs or copying the drivers themselves. I also use PuTTY regularly to do the trunk upgrades but log in as “administrator” and use “sudo” when necessary. This was the case on 5/18 when every one of the servers I updated appears to have stopped working (as far as logging goes).

Since I don’t use the GUI terminal I’m understanding that I should still try running installer through PuTTY but use “sudo -i” instead of just “sudo”?

@Wayne-Workman I did try clearing tables on one server and it didn’t appear to work but I’ll try a couple others since that one server is now currently in the process of rebuilding from a previous snapshot.

Thank you both for your replies!