@Polii123 Just to verify if the db really has no user tracking data in it, try to select the data manually.

mysql -D fog
select * from userTracking;
quit

@george1421 said in FOG will not boot - "Failed to get an IP via DHCP!:

You can test this by putting a dumb (unmanaged) switch between the booting computer and the building network switch.

He did that, in his first post:

I’ve simplified the infrastructure to the client and the FOG server connected through a dumb switch.

@Wirefall What is the model of the problematic host? Is this a server?

@Dogy007 Dude you can’t give up that easily - this is I.T. and giving up that fast is not acceptable no matter what your title or where you work. If you want to move forward in your career - like in any other career - you must put forth effort.

The first thing you should have done is Google searched the terminology that George and Tom used. And not just once but many times with a phrase change to each search. Read results, read read read.

You can start your reading here:
https://wiki.fogproject.org/wiki/index.php?title=Modifying_existing_DHCP_server_to_work_with_FOG
After reading that, you should be able to tell us what DHCP Option 067 is set to on your DHCP server.

@abos_systemax What’s the name of the image you’re trying to deploy? Also, permissions on /images should be 777 recursive for troubleshooting purposes. We first want it working, you can change whatever you want after it’s working.

You might also try to mount the NFS share manually using debug mode to see what sort of error you get. Instructions on that (and other stuff) are here:
https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_NFS

Also - you’re adding another drive to the system. Why? Is SDA full? If so, this would cause some pretty major weirdness. Check with this command: df -h and look for mount points with 99% or 100% usage.

FOG + the new FOG Client can activate windows for you automatically. You can assign MAKs individually to hosts or via groups.

George’s answer is how to protect an image in FOG.

I’ll add a little more to it though. If you want to keep your old image while making a completely new image, create a new image in Image Management, and then assign the new image to the host you wish to capture from.

At my old job, I named images with month and year included in the name. I purposely left out the day because I didn’t care to get that precise and just makes the name longer - thus making under-the-hood work more difficult because names are longer. I.E. Optiplex_7010_Jan_2017 or Lenovo_L530_July_2016

After the new image has been properly vetted, use Group Management to assign the image to the correct hosts en-mass.

If the fog server’s IP changed - first make sure it doesn’t change again. Do that with either a DHCP reservation or a static address. After that, there’s a tool I put together in this repository that will update the IP address in all the places on your FOG server for you: https://github.com/FOGProject/fog-community-scripts It’s the updateIP one. You would clone that entire project with git clone just as you would for the fog repository.

For future readers: https://wiki.fogproject.org/wiki/index.php?title=Migrate_FOG

For future readers: https://wiki.fogproject.org/wiki/index.php?title=Migrate_FOG

Just a guess, but it sounds like FTP credentials are not right if the captured image is staying in /images/dev which is unusual for fog 1.3.3 because when the installer is run it ensures the credentials are set properly - unless they were changed after the installer ran.

You’re going to need to watch the capture process with a laptop on your lap to also watch the task management page in FOG. Towards the end of the capture pay attention. Does the capture task clear? What messages are displayed on the machine’s monitor? Grab a video of it with your smart phone to capture the exact messages. Then share with us exactly what’s happening.

@kibade cool beans.

The troubleshooting articles most times will lead you to the problem if nothing else. Glad to see they are still helping folks.

@george1421 said in fog and sid number:

@digi I guess I’m a bit confused here. We can image 100s of systems a week and don’t really interact with the target computers post imaging. Once imaging starts we don’t touch the computers until the very end where we confirm that the systems boot up, connected to AD and users can login.

The normal setup for deployment is to build a single reference image, load all windows updates, install all common software, make any configuration changes needed, then sysprep and shut down the image. This becomes our golden/mother/reference image. Then we pxe boot into FOG and capture our reference image into FOG. We build the reference image completely using Microsoft MDT. This way we get a consistent reference image each time we need to rebuild the reference image.

From that point we pxe boot the target computers and then deploy the FOG captured image. After FOG completes and the target computer reboots, windows OOBE takes over and completes the installation without any human interactions. At the end the computer is ready to move to the work site.

I think this is #wiki worthy. We should have an area in the wiki about how people build their images in general. It doesn’t have to be technical, but just using the correct terms so people can read it and google search things in it, get ideas, and learn.

Most likely you have FTP Image Size turned on. Listing the images does take longer when this is enabled because the web interface is getting the size of all the images. The more images you have, the longer this process takes.

You can find the setting here:
Web Interface -> FOG Configuration -> FOG Settings -> General Settings -> FOG_FTP_IMAGE_SIZE

I’m going to ask @Tom-Elliott to help with this one.

I know it’s possible to do and you’ve already found the thread with the best stuff in it for this project. And that’s about all I can say on the matter at the moment.

@Ben-Acheff said in Reclaim Used Disk Space on FOG Server?:

Using the option to remove the image definition and data doesn’t result in the image being removed

Deleting definitions directly from the “list all” listing does not delete image data. That’s by design. The developers didn’t want it to be so easy to obliterate every image, and I agree with their choice. However, @Developers there probably should be some sort of message displayed when this method is used saying “hey, the data won’t be deleted if you do it this way.”

The below are simplified instructions for FOG 1.3.x, for the Linux newbie on how to do it right, and how to clean up the mess. Not calling you a noob, but I write for future readers too, not just you.

How to quickly delete definitions but not data:
Web Interface -> Image Management -> List All Images -> Click the checkboxes to the left of the image definitions -> Click "Delete All Selected Images?" at bottom of page -> Click "Are you sure you wish to delete these items?" -> Authenticate to confirm

How to delete a single image definition and it’s data too:
Web Interface -> Image Management -> List All Images -> Click the name of the image you want to delete -> Click "Delete" from the left menu -> Check the box labled "Delete file data" -> Click "Remove" -> Authenticate to confirm

If the above steps don’t actually delete the image data too, you’re FTP credentials are likely incorrect, refer to this article on how to fix that: https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_FTP

How to clean up the stuff you didn’t delete the data for:
On your FOG Server via Terminal or SSH, become root properly with:
sudo -i
Access the database via CLI with:
mysql -D fog or if it’s password protected: mysql -D fog -u root -p
Get a listing of the legitimate image paths (not the same as image names):
select imagePath from images;
Exit mysql once you have the list:
quit

These paths do not have the image path directory with them. The default image path is /images on your server. If you inherited the server, it may not be the default. You can check what it is with this query (in the fog database):
select ngmRootPath from nfsGroupMembers;
Or by looking in the web interface here:
Web Interface -> Storage Mangement -> [click node name] -> Image Path

Now, once you have the Image Path, you can do something like this:
ls -l /images or whatever the image path is.
Compare this list to the output from the database.

The dev directory or any file named .mntcheck these are required for FOG to operate.

Say you have an image that showed up in the ls output, but not in the database output. Say that image was called Acerbase. First, all things in Linux are case sensitive - you mistype a case and this doesn’t work, or does something you don’t want to happen.

Here’s how to delete that image:
rm -rf /images/Acerbase

After getting this done, you might look inside of the dev directory to see if there are any partial images from failed uploads.
ls -l /images/dev
Again, do not delete any file named .mntcheck but it’s safe to delete everything else in here, but just not the dev directory itself.

Take your time with this, it’s not a race.

#wiki worthy.

@shoong Don’t use FOG 1.2.0, and don’t build a new server using Ubuntu 14.

Use the latest stuff. Ubuntu 16.04 and FOG 1.3.x

Because - when 1.2.0 doesn’t do this and doesn’t work for that and all the other things that can go wrong with it and just not work with new hardware - all of us here are going to tell you to go to the latest FOG Version.

@george1421 I’ve never had to tweak it, but I know a few people here have.

The 1.3.x installer automatically makes backups of the database, they are in /home/fogDBbackups
Import one of those files like this:
mysql < file
You will have to have matching web files for the version you choose, you need to restore the correct web files inside of /home to /var/www/html/fog