This worked great! The Wiki for installing Mono should be updated for Debian Jessie, as apt-get does not work for installing Mono. I had to resort to the instructions on this page:

apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 3FA7E0328081BFF6A14DA29AA6A19B38D3D831EF echo "deb http://download.mono-project.com/repo/debian wheezy main" | tee /etc/apt/sources.list.d/mono-xamarin.list echo "deb http://download.mono-project.com/repo/debian wheezy-apache24-compat main" | tee -a /etc/apt/sources.list.d/mono-xamarin.list echo "deb http://download.mono-project.com/repo/debian wheezy-libjpeg62-compat main" | tee -a /etc/apt/sources.list.d/mono-xamarin.list apt-get update apt-get install mono-complete

@Tom-Elliott said in FOGImagereplicator not working:

@Neil-Underwood DHCP Server if FOG is to be the dhcp server.

It defines the start and end range of DHCP.

Got it. So this does not apply to my setup then. Must have been defined a long time ago when I was playing with that. Thanks!

Tom figured out the problem was due to mis-matching storage node versions and main server version of fog. the main server is behind a little from the recent node installations. Tom was able to create a patch that solved the issue without me having to update the main server, it is working good.

@bmyers said:

I did try the Grub with that one also as stated above.

Is that one an UEFI machine? Have you tried all the other exit types? Ah right… You also changed boot option in the BIOS to boot straight from disk and still didn’t work, right?

I did use resizable image since we have had some systems replaced with a different size hard drive in the past. Let me look into FOG Trunk and see what that is about.

The file listing and stuff you posted shows a non-resizable image. Maybe you changed the image type somewhere along the way? Please create a complete new image (whichever type you like), fresh upload, then download and see if you still have the issue. Other than that you better make sure you have the IDE/AHCI settings all matching on your systems!

@Wayne-Workman Ah. Thank you. In hindsight I probably could have saved some trouble by copying the dev folder out of the previous /images (now /oldImages) directory. I just copied the image I knew I needed to keep and then created a new dev directory. Just should’ve copied both 😐

Troubleshoot NFS

@EAHarvey said:

Disk is good to go.

Does this mean you found the issue and fixed it? Please tell us more about it. And what about the commands I requested?

@ITSolutions

Yup that is my current method so far, but if I were to do that, then my images would easily run past 40 GBs. Which is why I copy it to the mounted drive, then hop over with File Explorer and Cut/Paste it into a “Archived Folder” I have linked. Essentially the same thing just a bit more confusing than just being able write to the mounted drive. When I replace the drive locally, I’ll report back with the results and maybe we can figure something out thats not as step-intensive.

If you want a complete list of steps that I do, it goes:
Instructions dependant on cifs-utils package

Login to the Ubuntu Navigate to the /images folder (cd <folder path>) Delete any old images being used (rm –r <dirname>) Pull Needed image from Archive Directory from the external drive (Copy + Paste to NetworkImages) Navigate to the NetworkImages Directory Copy the image you want to use (cp –r <dirname>) Set the permissions for everyone to read/write/execute (chmod 777 <dirname) Review the folder contents using ls –l and make sure its highlighted green Set task in FOG using correct image Profit

I know this seems like a lot of work, but it really isn’t. Still takes less time than manually running to each PC and plugging my USB in and entering needed commands. With this, can run 10 PCs to a switch and image them all at the same time, which is exactly what we need because we build 10 - 15 PCs every quarter and in the start, there wasn’t ANY imaging solution. I had to build each OS by hand.

@Yamakazi It’s all explained in the man page I posted:

–mcast-rdv-address address
Uses a non-standard multicast address for the control (rendez-vous) connection.
…
By default “mcast-rdv-address” is the Ethernet broadcast address if “ttl” is 1, and 224.0.0.1 otherwise. …

So multicast control connection should be on address 224.0.0.1 I suspect! And then:

–mcast-data-address address
Uses the given address for multicasting the data. If not specified, the program will
automatically derive a multicast address from its own IP (by keeping the last 27 bits
of the IP and then prepending 232).

Means 232.x.x.x if I don’t get that wrong.

That’s why I post both. I have no idea what type your system is going to use so I just brute force them all.

In either case, this shouldn’t be a problem even on subsequent updates now.

@Wayne-Workman Yes fog is working fine, I use plex as a media server on the same system. I use it so I can use the xbox in my room to view many media I have on my drives.

I simply used the gui to set the permissions on the drive.

Trunk installed without issues.

@splatterbuns Also some documentation here:
https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_MySQL#Ubuntu_13.04_14.04_15.04_and_higher_with_FOG_1.2.0

@Sebastian-Roth

You don’t need to reinstall you Ubuntu system all the time if you stick to the trunk version for now. No need to bother you VM admin. Just try to fix things and re-run the installer. As well you can easily update to a newer version without having to start from scratch. Note down the things you fixed and where to find logs and stuff. Then when you feel you got it all fine you can still get back to your VM admin, get a fresh one and pull up a clean new system then.

This is what I ended up doing and it fixed the problem I was having. Thanks again for your help!

For Win10, gpt disks, and uefi firmware yo must use the trunk build of fog. The last stable release 1.2.0 stable doesn’t support the previously mentioned features.

Understand that the trunk build is a dev build so there are still a few bugs in the system. But they get patched quickly when reported. Plan on updating your install a few times to get new functions before 1.3.0 is finally released.

@Junkhacker @Quazz Thank you both ! I did try re-installing FOG on one server and it worked. Then I tried just restarting another server and that worked too. I then restarted ALL the affected servers and they all worked. Don’t know why the problem occurred, never seen that happen in 10 years so I guess I learned something today and I can sleep well tonight 🙂

@Sebastian-Roth Ours was quite a few firmware updates behind and we weren’t able to jump from our current strait to the newest, but stepping up just one version solved it.

@TreyBentley Ultimately, it will break MUCH more than just ldap. It will break pretty much ALL of fog.

Thanks a lot for letting us know! Feel free to post again if you find this is still not properly working somehow.

I had this issue too
I ran ./installfog.sh -K to fix it
I am running CentOS Linux release 7.2.1511

@Wayne-Workman Yes, force people to set a MySQL root password when installing. But it would still fail if people have MySQL server pre-installed (with empty password)… Other than that I don’t think we have any chance to hook into the auth_socket thing. See if you can find anything related to php and auth_socket