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

I’ve solved the thread.

The timeout was because this system is on an isolated network.

The isolated network IP is 192.168.1.1, but the wifi lan is set to 192.168.1.207 (which gives the device internet for upgraded/updating).

To enable the installation to operate, I changed the IP address to 192.168.1.207 as the DB settings were already set.

This ipaddress was used to generate the default.ipxe file which was what was causing the problem and I over looked it.

Sorry 😞

@templink People new to FOG always blame every little bump in the road on FOG… I’ve been getting hit with nonsense from co-workers for almost a year now. Just seems like that’s how it goes.

Either way, you’re always more than welcome to post issues here.

Hey, after tessting it really looks like the problem is on that SSD. Could deploy and upload on other clients. I guess the first imaging tool brokes it. But after all fog is better than that anyway. Thank you for your help!

What OS are you using on the FOG server?
Ubuntu LTS 14.04.3 -> ubuntu-14.04.3-desktop-amd64.iso

What version of FOG are you using. I will guess 1.2.0, but did you upgrade to the trunk version (i.e. pre 1.3.0)?
1.2.0

yesterday evening i think about this options and now i am sure that i mixed up with Norton Ghost.
In FOG u build the the Hosts to Groups and if all Groupmembers ready then starts the Multicasting-Task.
As is told, in Ghost there was the 2 Options (‘wait for last member then start’ or ‘start on my command’)
confusing on my side - already fine…
u can close this thread 😃

@Wayne-Workman While that is true, it’s not always a possibility.

I would highly recommend upgrading if that was an option, but from the sounds of it, this is not necessarily the case. I’d really highly recommend going to trunk rather than 1.2 as well, if only so I can get more feedback on bugs and what not.

@cotec said:

The user which i can setup in FOG-WebGUI are admins or user? has this user access to webgui?

They are all sort of equal. the switch for “mobile only” really isn’t good because FOG mobile is in a state of disarray at the moment.

There is an access control plugin that is intended to limit what users can do based on location - but it doesn’t totally work right.

If you are concerned with other people goofing things up - just make everyone an account and tell them to use their own account. There is a history table in the database that will list most actions and the user that executed those actions.

Also - training goes a long way.

What version of fog @Sparky? I ask because in dev versions there is no more “Red X”