You may want to review the usefull information in this post: https://forums.fogproject.org/topic/10403/boot-iso-from-ipxe-menu/5
The post talks about Xubuntu, but it should also apply to Ubuntu. The idea here is to not deliver the whole ISO over pxe booting, but pxe boot the ubuntu kernel and then let the kernel access its files via NFS from the /images share on the fog server.
@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:
sudo wget -O /var/www/fog/lib/fog/plugin.class.php https://raw.githubusercontent.com/FOGProject/fogproject/6717f382177e714c1bd22eb11627133cfd4e0ebe/packages/web/lib/fog/plugin.class.phpI 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.
Let me see if I understand the truth table here.
Computer A in room 1 = no pxe boot
Computer A in room 2 = pxe boot and imaging.
Computer A back in room 1 = Windows boot + dhcp.
OK So I would have to ask this.
@kojote13678 I fear if you have very little control of your environment then you have little chance of integrating FOG into your network. There are articles on having a coexistence between SCCM/WDS and Linux PXE environments (as fog would be one). There is an old document here that discusses it: http://www.vcritical.com/2011/06/peaceful-coexistence-wds-and-linux-pxe-servers/ The old instructions are still relevent. The only differences is the pxe boot loader now is undionly.kpxe for bios systems and ipxe.efi for uefi systems. The pxelinux.0 file is NOT used with the new version of FOG.
I feel your only solution here is an isolated network design.
The problem you have with wds is that it also supplies proxydhcp values too and the target computer only sees that. You need to isolate target computers from seeing the wds dhcp server. How much flexibility do you have in your environment? Can you adjust your wds server. I seem to remember someone creating a menu item in WDS to chain load FOG PXE.
The other thing you can do is create a deployment network where only the target computers and the fog server exist. FOG would then supply dhcp information on your imaging subnet. In this setup if your FOG server had 2 network interfaces the fog server could also act as a router between your imaging network and your business network. Its not the ideal situation but if you have an environment where you can’t stop WDS you need a way to isolate the broadcast domains between WDS and FOG.
The last way you could do, is USB boot into the FOS engine (the customized linux OS that captures and deploys images). This route doesn’t use pxe booting at all so there won’t be a conflict between pxe booting environment. This solution is intended for testing and not production environments because it more manual of a process than what FOG was designed for.
@m-fitzgerald I’m still missing the why here, but I think I can summarize all of your posts. Let me reask the question using my words. It may not be exactly what you are asking, but it should be close.
Q: I want to introduce fog imaging to my company. I have about 800 computers located at 11 sites. Each site will have their own independent FOG server. I need to installed the FOG client on each of these 800 preexisting computers and point the fog client to their local FOG server. I have pdq deploy setup already and can use that to deploy the fog client. Is there a way to install the fog client on each computer and configure it to point to each site’s local fog server without having to visit each computer?
A: There are at least 2 ways to go about this. One method is the brute force method and the other is a bit more elegant but requires programming skills.
Brute force. Just create 11 PDQ deploy packages (one for each site). Each package will point to a single fog server in the invocation line of the MSI. Hopefully each of your 11 sites are in their own AD OU. You can then deploy (using PDQ Deploy) one of the packages to the correct AD OU. This has its advantages in that the computers in the OU belong to the same site and the same FOG server. If you have roaming computes they will get the right FOG server IP address no matter which site then happen to be at when the package is deployed. The setup can be done by anyone who knows PDQ Deploy. All you need is a fresh bottle of pepsi and about 30 minutes of quiet time.
The bit more elegant approach is to create a powershell or vbscript to identify the computer by either IP address subnet or by target computer name and use that information to point to the proper local fog server. This method requires a little programming and a look up table (simple csv matrix file or done purely in code) to index your key value to the IP address of the fog server. When I refer to using the target computer name, this assumes you encode something site specific into the computer name like the site’s OU name and then the computes asset tag (i.e. NYC7D5JXQ1). In this example NYC is the OU and also the key value to the sites FOG server. A simple look up table would be something like this:
NYC, 192.168.1.16
ATL, 192.168.2.34
LAV, 192.168.3.22
Now the other side is you could use the IP subnet of the target computer as the key value. This would be the subnet where the computer is when the install script was invoked. In this case your lookup table would look like this:
192.168.1, 192.168.1.16
192.168.2, 192.168.2.34
192.168.3, 192.168.3.22
You can see an example of the subnet lookup table here using a linux bash script: https://forums.fogproject.org/topic/7740/the-magical-mystical-fog-post-download-script/6
There are several other approaches you can take. But the above are the most efficient. Since you only have 11 sites, I probably would go with the brute force approach because of the time involved with writing and testing the script. Sometimes its just easier to “Git r’ done” using a big hammer.
@m-fitzgerald Maybe I’ve had to much salsa and corona today, but I’m still not seeing a problem here. I understand your constraints but what is the problem?
I can not find a way to deploy silently the client application with the appropriate FQDN for the fog server at each location
This I think is the root of the problem. But I’m not sure of the client application interaction with the fog server?
@m-fitzgerald said in HELP! I need to deploy FOG Client to 800 computers at 11 different locations:
The issues is I can not find a way to deploy silently the client application with the appropriate FQDN for the fog server at each location. Deploying silently is a piece of cake thanks to PDQ. Since each location shares the same DNS server (all one big AD) I can’t simply add an A record.
I REALLY do not want to install one by one at over 800 PC’s. We are a staff of TWO!
You need to explain this bit a little more. Why do you need to name of the local fog server for either image or application deployment. I have a distributed model like yours and I don’t need this. There ARE things you can do for a distributed model like look up tables and such. Buts lets get a little better idea of your exact condition first.
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.
Typically you would create an administrative installation point (google it) for both office and most other fat MS applications. You can install the installation point on a network share then from the snapin perspective just a cmd file is sent to the client to call the install string to the installer in the administrative installation point.
It may be worth reading this: https://www.404techsupport.com/2015/10/02/customize-office-2016-windows-install/
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.
@msi
Inspect the /opt/fog/.fogsettings file on the remote storage node. Then back on the master node, check the web management gui for that storage node definition. Ensure the management user ID is fog and the managment password matches the password field in the .fogsettings on the remote storage node. If they are in allignment then I have to ask you, did you muck about with the linux user fog on the remote storage node?
@manuel Then your the fog installer didn’t complete correctly. I would suggest that you reinstall fog. I will ask you the questions again since that .fogsettings file doesn’t exist.
[edit] before you do that look in the same directory as the fog installer. There is an error log directory. See if there is anything important in the error logs.
@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.
@manuel Ok you have things broken then.
What I want you to do is this.
password= line. (hint: it will help if you connect to your fog server using putty so you can copy and paste easily).fog password to match what was in the .fogsettings file./images/dev. As a test create a test directory and remove it./images and repeat the same steps.fogfogI guess I need to ask, did you use the fog user account for system management? Or have you change the linux user fog account in any way, maybe updated the password for some reason?
@tandersb said in Cannot capture image- fails at 'Saving original partition table':
git checkout dev-branch
That caused your pain. If you would have skipped that one step you would be on the current stable release.
Can you roll back? you should be able to. I say should because I’ve never did that between 1.5.0 and 1.4.4. The DB structure should be the same.
What you want to do to roll it back is
git checkout master
Then do a fog reinstall by just rerunning the installfog.sh script.
Well I’ve done quite a bit of reading and reverse engineering on this. I now see how the root file system is the size it is. Basically when buildroot is run and the init file system is created it takes the size of the files and adds in a small buffer space for log files and that becomes your initfs.
I also see that buildroot has the ability to add in some “fluff” space just in case some idiot (like me) needs to add files to the initfs dynamically. Currently the FOG buildroot config file has the “fluff” space set to 0, so we are only getting the files size + buffer space.
Ref: https://svn.code.sf.net/p/freeghost/code/trunk/src/buildroot/fog.buildroot.config.64
Field: BR2_TARGET_ROOTFS_EXT2_EXTRA_BLOCKS=0
Field: BR2_TARGET_ROOTFS_EXT2_EXTRA_INODES=0
ref: https://git.busybox.net/buildroot/commit?id=301c18e1233a4e1bbbd5368496ddfe99480909bf for the descriptions of these settings (yes I know its a diff patch file)
So its possible to add in some space into the root FS. So the questions are
For #1.
That is a slippery slope. Lets say we add in an extra 100MB. What happens when someone needs 103MB extra? Then the next guy +110MB extra? How is that process managed? Sometimes its easier to say NO. Just build it your self. The other issue is the kernel size for the kernel_ramdisk_size. Are they related? If we make the initfs too big will it bump in to the default value of 127MB for this ramdisk? Or is that something else all together?
For #2
If this change is made at a FOG foundation level will we run into issues with all of the deployments currently out there (like the comment about the kernel ramdisk size). Will that need to be adjusted to use this larger initfs?
I don’t have the answers, I’m just thinking out loud here…