@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.

@EAHarvey lol. He’s been a user here for two years.

@Wayne-Workman If I understand the OP’s post there were two actions that were needed.

Since there is a firewall between the two subnets, 2 rules needed to be crafted to allow communication between the devices on the subnet where the fog server was not. On the subnet where the fog server was not he had to update the dhcp to include the next server and boot file settings. On this one I gather (guess) that each subnet has its own dhcp server.

Tom Elliot has resolved the installer not asking for any info issue but now fails with error:

* Adding needed repository....................................Failed!

I’ve checked the log at /var/log/fog_error_5893.log which shows

Package epel-release-6-8.noarch already installed and latest version Nothing to do package http://rpms.remirepo.net/enterprise/remi-release-6.7.rpm is not installed Loaded plugins: fastestmirror Setting up Install Process Cannot open: http://rpms.remirepo.net/enterprise/remi-release-6.7.rpm. Skipping. Error: Nothing to do ../lib/common/functions.sh: line 439: yum-config-manager: command not found

So the remi repo needed to be enabled, doing this alone was not sufficient to fix problem, Tom Elliot also had to enable yum-config-manager. Tom has updated this in git and i’m now running on trunk@4617

Tom/Wayne, thanks again for your efforts, really do appreciate it.

regards Kiweegie.

@ManofValor We’ll need to remote in to see exactly whats causing your issue. We’ve sent you a chat message with further detail.