@sebastian-roth I need to fill in a bit of detail here. I helped Hugo setup a partitioned FOG Master server. This is where he has some images in /images and other images in /images2. There is a storage group associated with each images container where the full fog server is the master node in each storage group. From what I gather the storage group that points to /images is replicating just fine to its storage node. But the storage group connected to /images2 is not replicating to its storage node.

@Hugo What we would like to see is a screen shot of “Storage Management -> All Storage Nodes” page. This will tell us if you have the proper grouping right.

We would also like to see your master node configuration for the /images2 container.

@donutsrule5 Just for clarity, (choosing ipxe.kpxe isn’t a bad decision) the undionly,kpxe driver is the most common used because it uses the undi driver built into each network card. This driver supports the most network adapters because almost all network drivers have undi built in. With that said some implementations of undi is broken which cause undionly.kpxe to fail. The kernel ipxe.kpxe contains all of the known drivers provided by the iPXE group. So this kernel “should” work on all of the common network interfaces.

Please confirm that FOG Settings->Web Server ->FOG_WEB_ROOT is configured correctly. It should contain /fog/

This also could be a spanning tree issue in that standard spanning tree is enabled and not one of the fast protocols (RSTP, MSTP, FastSTP, etc). But you should see this earlier in the process.

This error above usually relates to the dhcp client not being able to reach the FOG server during FOS booting. It will typically do this process 3 times and then give up.

udhcpc: started, v1.26.2 
udhcpc: sending discover 
udhcpc: sending discover
udhcpc: sending discover
udhcpc: no lease, failing
udhcpc: started, v1.26.2
...

Its a bit misleading in that the target computer may be getting a dhcp address but unable to reach the fog server for some reason.

@sebastian-roth I forgot updating this thread yesterday. After a chat session we agreed to do a TV session. There was a number of things that went wrong with the upgrade. The first was using the linux fog account for system management. The fog installer change the linux fog user’s password to something and (I feel) the fog installer didn’t complete the first time since not all of the info was saved to the .fogsettings file. So the fog user password was not saved in the .fogsettings. It was a bit of a bad situation.

The OP had to go through the ubuntu password recover process to gain control of FOG server’s fog account. Once that was done, he created a new user for FOG server administration and then switched to that account for system administration. He was using isc-dhcp for the imaging dhcp server on an isolated network because of some incompatibilities with the primary dhcp server on the business network. When trying to complete the 1.4.4 upgrade again the installer was aborting because of some missing settings in the .fogsettings file. We decided to disable the isc-dhcp server and switched over to dnsmasq to supply the missing pxe boot information. We had to call off the debugging do to end of business day. He has to get with his networking engineer to update their dhcp-helper service to include the FOG server IP since the fog server is on one subnet, dhcp server on another, and the pxe booting clients on several other subnets.

I feel the OP is pretty close to getting his fog server operational again with everything connected to the business network.

@noelpd The change will be automatic, once installed.

For people to be able to login using ldap they must be listed on the group identified by admin group field.

@jim-graczyk said in FOG installed on small VM. Possible to drag and drop images when needed for deployments?:

I would also offer the suggestion that you separate the /images folder onto a separate virtual disk.

I would also recommend this. The issue I’ve seen is filling up /images with images will take down the OS since /images is part of the root file system. Its roughly equivalent to filling up the drive of a windows computer. You typically don’t place uncontrolled growth data on your OS disk in windows, the same applies to linux.

I don’t personally like the idea of shuttling in and out images as needed. But if one had some just a little bash shell scripting skills it could be done. You might think about it as a poor man’s hierarchical storage solution. You would keep active images on high speed disk and then shuttle the image to lower speed (possibly usb attached) storage.

In regards to moving the images off the root partition. I did create a tutorial on how to do this with centos, similar concept can be done with ubuntu. https://forums.fogproject.org/topic/6642/moving-fog-s-images-files-off-the-root-partition

@merilious OK I just wanted to make sure that the password was blank. Then the instructions in the thread are spot on. Go ahead and follow the steps. Then you probably should update to current 1.4.0 had several issues with single disk resizable that was fixed in 1.4.1. But for now you need to get control of your fog server.

@dew12 If you are running 2.76, then use my ltsp.conf file from the tutorial. Your config is missing some bits at the end (and in the middle too).

Lets first talk about what is going on behind the screen here.

When you capture an image with FOG, it uploads the image to /images/dev/<mac_address>. Once the capture is complete the target computer logs into the FOG server over the FTP protocol and requests the /images/dev/<mac_address> directory to be moved to /images/<image_name> using the linux service account called fog This is the point at which your image capture is failing.

The linux user fog needs to have Read/Write/Execute permissions to the /images and /images/dev directories for this transfer to happen. So I would start there to ensure that the fog user can do what is needed.

@anthony-delarosa No the fog client works the other way around, the clients check into the master fog server for things to do. They also post inventory info and such.

Since you have a great performance data so far, I wonder if you would be willing to help the fog project by doing something I had on the back burner for a while.

The idea is simply to install php-fpm and have apache use that instead of its internal php engine. I’m interested to know how that impact:

1. Performance of the web gui
2. Impact on performance of the entire fog server CPU usage.

I see you are using an older OS, but the php-fpm package should still be available in epel or in the centos repository. If you have a little time to test this idea let me know and I will put together a tutorial on how to set this up. Reverting back to the default apache php can be done by just commenting out one line. I would do it on my production fog server, but I only have a small campus. I’ve been looking for someone who had around 1000 clients to see if the test was dramatic.

@thebrennan47 Boy, you are just full of good news.

OK what is 10.2.102.49? You keep throwing new IP addresses at this poor pxe booting client?

It really sounds like you have two or more dhcp servers in your broadcast domain .

After reviewing the pcap file we found there IS a second dhcp server on the OP’s network. The OP is currently addressing the second dhcp server issue.

@natsufiree I wrote a tutorial on how to compile dnsmasq 2.76. If you need to support both bios (legacy mode) computers and uefi computers then you will need to use dnsmasq 2.76 or newer. Not all linux distributions have an updated version of dnsmasq. If your linux distribution does then the setup is pretty easy. Just use the ltsp.conf config file I have posted in the thread. Update the <fog_server_IP> directives with the IP address of your fog server and restart the dnsmasq service.

If your linux distribution does not have version 2.76 or newer then you must follow the instructions in the tutorial on compiling your own version of dnsmasq. The instructions I created for ubuntu, but should work for debian.

https://forums.fogproject.org/topic/8725/compiling-dnsmasq-2-76-if-you-need-uefi-support/6

Once you have the current version of dnsmasq installed then update the config file and start the dnsmasq service.

@ljedi What hardware are you deploying to?

Did you use single disk resizable?

Did you upgrade windows to get to 1703 or did you install it from a newly created reference image?

There has to be something in common here.

@manuel Sorry for the slow response.

To view hidden files you need to issue the following command ls -la /opt/fog

If you don’t have the .fogsettings file then the fog installer did not complete the first time you ran it.

I worked with the OP via IM for a bit and we have things working for dhcp. The root cause is the dhcp config file had a wrong subnet scope defined (10.x.x.x) where the fog server was on the 192.168.1.x subnet. Once we got the configuration file fixed the target computers pxe booted without issue. At this point the OP can pxe boot the computers. He has an issue with imported images from FOG 1.2.0, but that is a story for a new thread.

Well I can’t prove that its broken here. I deployed a Win10 1703 reference image to a 7040 in bios mode and it boots correctly through an pxe boot. I built a UEFI version of Win10 1703 and deployed that to the 7040 in uefi mode. First to the nvme disk and second to a sata ssd. Both booted through pxe to the OS. I tested these configurations with both our production server running FOG 1.4.4 and a dev box I spun up running FOG 1.5.0RC8.

In uefi mode right after iPXE exits and before Windows starts to boot there is some text and a blue banner displayed. I’m a quick reader but its only on the screen for a split second before Windows boots, so I missed even the context of what it said.

On our production server I’m sure I mucked with refind.conf file at some point in time. The 1.5.0RC8 was left as it was when I unboxed it. I did nothing to 1.5.0RC8 other than install it and login to register the test system.

The 7040 has firmware 1.4.5 installed I know there is a later bios release, but that is what was installed on the box. When I registered the system I went into the host configuration and set the exit mode for bios to SANBOOT and uefi to rEFInd.

Now this test may be flawed since I captured and deployed both images (win10 bios and win10 uefi) using our production server (1.4.4) and only used 1.5.0RC8 to pxe boot through. When I setup the test system I didn’t give it a big enough HD to take the 25GB Win10 image. I’ll have to rebuild the test server again to be able to capture the image from our reference VMs. I’ll do that after the holiday.

@coxm There is a bug in 1.4.4 that needs to be patched with a hot fix.

Here is the process to get and apply the patch:

1. Open a linux command prompt on your FOG server.
2. Key in the following command:
   sudo wget -O /var/www/fog/lib/fog/plugin.class.php https://raw.githubusercontent.com/FOGProject/fogproject/6717f382177e714c1bd22eb11627133cfd4e0ebe/packages/web/lib/fog/plugin.class.php
3. Remove the location plugin (make sure to document your current location settings)
4. Reinstall the plugin
5. Add in your plugin settings and save

I would recommend that you follow the process until you get to step 3. You may not need to remove and reinstall the plugin. This will keep you from potentially loosing your current settings if the plugin was already installed when you upgraded to 1.4.4. This patch has been integrated into the next release of fog, which is still in development stage right now.

@george1421 I just found a compiled version of dnsmasq 2.76: ftp://ftp.pbone.net/mirror/rnd.rajven.net/centos/7.0.1406/os/x86_64/dnsmasq-2.76-1cnt7.x86_64.rpm

I can’t speak to the efficacy of the rpm, but it would jump you ahead of the compiling of the source. I’m going to still work on the compiler part, but only for my satisfaction