@BASURILLABAS2 Ok, now you have a trunk version installed with the good settings in Multicast ?

@Andrew-Aitken I’m not saying there isn’t a way, but there is no way that I know of to convert an image other than deploy and recapture. Maybe one of the devs has a better idea. But the quickest route is to deploy and recapture.

@nbuursma said:

Got it, okay first thing that fails is
Attempting to check in… Failed

Then screen is filled with complete GARBAGE

Can you get us a picture?

How is it that it fails on check in, when before it failed at the very end? What changed?

Cool - issue resolved!

This was absolutely an issue on our network, but we’re not sure if it was an old static Rendezvous Point that was configured on our core or if it was our VPC redundancy between our two nexus switches, but we were able to solve it by disabling pim on one of the nexuses and removing that static RP.

Thanks for the help on investigating, everyone. It’s much appreciated.

@Arrowhead-IT

“What version of Ubuntu are you running?”

Ubuntu 14.04 LTS

@Scott-B What I’m saying, somebody edited something in the code.

I’m not enforcing any PHP 7 anywhere.

Edit the /opt/fog/.fogsettings file and remove the packages line. Then try re-installing. Maybe it’ll work better?

@Wayne-Workman said:

If you liked that, FOG Trunk will blow your socks off. 👍

As far as I know, imaging unregistered computers using FOG Trunk only works with Unicast.

You can set (in storage management) how many active tasks are allowed. I keep mine set at 2. Then you network boot all machines. 2 will start. The rest wait in line and automatically start.

Thanks for the suggestion to move to trunk, and thanks Quazz for the clarification on whether or not multicast worked. This is exactly what I wanted/needed! 🙂

For any wayward googlers:
I upgraded my install to trunk using these instructions: https://wiki.fogproject.org/wiki/index.php/Upgrade_to_trunk pretty straight forward.

After the upgrade completed, I went back to image management in the web gui, selected multicast image, started a new session for the amount of clients I wanted, netbooted each client to fog’s boot menu and selected join multicast session. it goes when the specified number of clients connect.

Wonderful. Thanks a lot, guys. 🙂

@cotec sudo is not needed if you’re root, but it mainly depends on how you are in as root. For example, sudo su does not source the root environment which can leave other the paths in a strange status which could cause problems. sudo su - sources the environment but it is more appropriate to use sudo -i.

Tom, Thank you for the quick reply. All things are new including pulling the XP image. Vista images are working. We understand we will be moving from the 1.2 Stable to the current Trunk.

@Julianh WOW! Not something I’d have ever come up with. Thanks a lot for reporting back. I am really glad that we don’t need any kind of special kernel patch to make this work.

@Julianh

Depending on your comfort level - you can make a copy of the image manually, and then manipulate the copy, and create an image definition to match.

for example, lets say I have /images/MyAwesomeWin7Image

I could copy it like this:
cp -R /images/MyAwesomeWin7Image /images/CopyOfMyAwesomeWin7Image

Then I could work with just the copy, and delete the disk 2 partitions like this:
rm -f /images/CopyOfMyAwesomeWin7Image/d2.mbr
rm -f /images/CopyOfMyAwesomeWin7Image/d2p1.img

Then, in the web interface I would go to “create new image” and put the image name and image path as CopyOfMyAwesomeWin7Image and select “Single Disk Multiple partition non-resizable” as the image type.

And then just assign that image to a host and try it out…

But if you’re using FOG 1.2.0, it does not work with totally blank HDDs. However FOG Trunk can handle blank HDDs - but it is developmental. I use FOG Trunk in production, others do to. You simply need to understand there will be bugs that you won’t expect, and when you find those, just report them here in the bugs section, the developers are really good at fixing bugs.

Hi Tom,
Location selection issue has been resolved in trunk 5929 so you may set this as resolved.
Thanks again!

@Wayne-Workman, Well I could just copy the key from a backup and be ok then. But the issue then comes into why did my snapins directory get cleared out and recreated. I hadn’t had that happen before. It should have been left there and the key should have been present. Might be an issue for @Tom-Elliott to look at. Unless he feels that this could have been a fluke. I might be able to copy my server in a couple days and try the update again and see if I get the same results with the snapin folder being cleared. But if it shouldn’t be cleared I will just copy the file from a back up for now.

Although the new clients are working as is, even with the key missing.

I appreciate the help and all the effort everyone puts into FOG. I wish I had more time to contribute to the product. But unfortunately I am not able to much at the time. So I understand the dedication it takes to keep this awesome product moving forward.

@Jbob ah ok. I’m slowly figuring out how this works.
Solved and Thanks !

@Wayne-Workman Ubuntu Server 14.04

@cotec , can you post this to a new topic, otherwise it will get buried.

@Wayne-Workman HI Wayne, we’re all good.

Only steps needed to get this operational above and beyond your suggestions were to run exportfs -a after editing path in etc/exports and then making sure a .mntcheck file existed in each locaton /home/fog/images and /home/fog/images/dev

regards Kiweegie

@Jbob I’ll have to try tomorrow and let ya know.

Image is still copying this morning but is being accurately limited to the 500kbps setting set on the storage node. Not sure what the issue was but suspect it may even have been erroneous reporting within our monitoring tool PRTG. Marking as resolved.

cheers, Kiweegie.