Best posts made by ITSolutions

@RLane

Are you installing a completely fresh build of Trunk?
What version of trunk are you trying to install
Are you using a .fogsettings file from a previous server?
How much space does your root drive have?
Is MySQL running?

@Tom-Elliott This could be needed for security purposes. A wipe will make sure the entire disk is over written before putting down an image. With just re-writing the image you can’t ensure that forensic tools won’t be able to recover old files. I can see what he is asking for, maybe if there was a way to modify the download task to do a normal or full wipe then download to give assurance that all data has been over written at least once. This should be able to be accomplished a couple of ways, either one have the fog inits run a normal wipe then run the download, or possibly with the a hooks you could have it auto create a deploy after the wipe finishes so when the client reboots it will pull the image automatically.

@Tom-Elliott No problem, glad to help when I can. I love FOG and recommend it all the time. I just wish I had more time to help with the community.

If you formatted it as NTFS that is the start of your issues. It needs to be ext2, 3, or 4 in order to work correctly with FOG. Try reformatting and mounting it as ext 4 and see if that fixes your issue.

What version of FOG and Ubuntu are you using? Did you recently update either of them?

I would try running a chkdsk under Windows as it looks like the file system isn’t quite right for some reason.

Did you add option 67 in DHCP as undionly.kpxe? You need both 66 and 67

A couple of questions and a few starting points. First is FOG serving DHCP or is that done by a different server? Second what version of FOG are you using?

Now to the high level thoughts on starting to rebuild the server. First you should run the FOGbackup script included in the installer directory. This will get you a backup of all your necessities, such as your DB, Snapins, and images. From there you could re-install and then reload the DB and snap ins.

But in order for us to better assist you we need to know the version of FOG as there are many different ways to approach things depending on your version and what version you are looking to go to.

@pmonstad It won’t hurt to reset all the hosts, even if they are not having the issue.

DHCP settings are explained here if you need anymore info on them,

https://wiki.fogproject.org/wiki/index.php/Modifying_existing_DHCP_server_to_work_with_FOG

I was going to suggest the same setup as I almost always set my servers up that way. I like the separation.

Once you answer the questions raised by @Wayne-Workman then you can actually proceed with the rebuild. It sounds like you have a physical server from your description, does it have just a single nic or multiple? Also make sure you have the IP of the server and/or name of the server. The clients will need it to stay the same, unless you want to updated with GP and new config file. On the legacy clients it is trivial to update the config file with GP if you choose to change IP’s or names.

Also given that you are rebuilding the server this may be a time to weigh the Pros and Cons of upgrading to trunk as it is rather stable and offers many new features.

I would run the back up script and also do the export as @Wayne-Workman mentioned and save all of this to an external location either usb HDD or network location. I would also include the .fogsettings file, usually in /opt/fog/ for Ubuntu, as it has the original install settings stored in it. As long as you want it back to how it worked on install this could save sometime.

** A side note that may help, backing up your fstab file under /etc/ maybe wise also as it most likely will have the mounting point for /dev/sdb1 as the /images dir. (If the second HDD is auto mounted as /images as you have indicated). I will often unplug the second drive as to ensure it will not overwrite any thing during OS re-install(saving time on coping images back). I have had bad experiences in the past on this.

Then I would reinstall your OS and if you are staying with 1.2 then definitely use 12.04. But if you choose to upgrade to trunk then 14.04 or higher maybe a better choice. Then set you IP if it is static on the server. Proceed with the reinstall of FOG, you can copy the .fogsettings file from backup to the install location, usually /opt/fog/ if I recall correctly. After it is set up and database is configured then you can restore the database from the web gui. You can copy the “snap in” back up directory to the “/opt/fog/snap in” directory. If you chose to back up your fstab file then restore that to /etc/ (make sure to backup the original fstab in case there is a conflict), shutdown the server, plug in the second drive and reboot. If all goes well FOG should be installed and images there and ready for deployment.

@Wayne-Workman if I am missing something please chime in, I think that pretty well covers it though.

@Wayne-Workman I have to ask the question that you ask and we all ask, What version are you on? And did it just start in a recent update?

@Data31337 My instructions are for a USB or Firewire style drive.

You could instead just mount it the same way you currently do, just directly to /images instead. make sure you copy all files from the current /images including hidden files.

Can you please post what version of FOG and what OS you are using?

Ubuntu 14.04
FOG 1.3.0 rc-1
Windows 7
Client 0.11.4

I just updated to RC-1 today and deployed my first machine. After updating the client on the image(for some reason 0.9.10 client won’t update to a newer version automatically). The machine joined the domain and then started to deploy snapins, after a little while I realized that I wasn’t getting notifications of the snapins completing so I checked and all snapins (except the first one) showed canceled. I tried redeploying all snapins and the same thing happened. So I checked the client log and the second snapin showed:

ERROR: Snapin has does not exist
So I skipped it and the rest would all complete fine. I then tried re-doing that snapin and it kept giving the same error. After I realized that it had spaces, I removed the spaces and re-uploaded the file to FOG and the snapin now works.

Can we either correct the issue to allow spaces, or just have a check that will display an error if the snapin file name contains spaces?

Not sure when this started to happen as I was still on 7961 and upgraded from there.

@robza In your original screenshot I just noticed that the MSI file has spaces in it, can you remove the spaces? This would cause msiexec to error finding the file. 1603 is a common catch all error on MSI files, so this could be the issue also.

Windows 7 does have local Group policy settings that you can use without AD. You could also set a log in script that will remove all these files. you could use a simple script that will delete all files on the Desktop and Downloads file, and leave only public desktop icons. The script could be as simple as:

Del %systemdrive%\users\%username%\Downloads\*.*
Del %systemdrive%\users\%username%\Desktop\*.*

You would save that as a batch file, like logon.bat. This will remove all files in the users downloads and desktop folders, but will leave public folders as is. You can set this as a log in script in the local Group policy manager, by typing gpedit.msc in the search box in windows 7. and then go to User Configuration>Windows Settings>Scripts(Logon/Logoff), Double click log on and add the script there. You can build this into your images, so that it just works every time. If you ever need to change the script and add more things, simply create a snap in to copy a new file and over write this script and the new script will run.

There are other settings in Group policy that maybe able to accomplish this without scripts but not sure which ones work best for you. I would suggest looking around at it a little and see what is possible.

*Did you check the client log on the machine that didn’t join the domain? Domain joining is completely separate from snapins, that doesn’t even need to be pushed it is a check every time the client connects.

*Did the snapins appear in the tasks que on the server?

*Also did you check any of the client logs of those hosts to see why snapins where not deploying?

*What OS are you using, both on the server and client. Very hard to troubleshoot and correct bugs without information.

@cemicolin The menu item should be fog.fullwipe instead of Full Wipe

@Tom-Elliott Yeah, I pretty familiar with that error code, but I am not installing any differently than I have ever done in the past. I have installed the new client on almost a dozen images already with no issues up until recently. I just realized I have not installed since I last upgraded FOG, so I think I will upgrade FOG on Monday and try again. I will let you know if that solves anything.