@chanstag Your picture is interesting, in that after ipxe.efi there is an unprintable character shown as a block character. Make sure there isn’t any spaces or other junk after .efi in your router’s configuration.
It is also safe to assume the fog server is at 192.168.1.2?
If after checking your router settings and still are not having luck, we’ll get a pcap of the pxe booting process and look at what is flying down the network wires.
@The-Dealman The replicator is pretty simple in that it should be a sequential replication node by node. If I remember correctly the images are replicated based on their image ID sequence and not by image name. You can prove this out by looking at the fog replicator log. There will be a master replicator log and then one log per storage node.
@Pistachio said in How do you re-compress an image file?:
We’ve captured an image with “6” level of compression and we want to compress it further using “18”. Do we need to recapture or just update the compression level via the web GUI?
If you want to take advantage of the higher compression index (i.e. to get a reduce disk space footprint on your FOG server), you need to recapture your image. I would also suggest that you switch over to the zstd compressor with an index of 11 to start. The zstd compressor (in opposition to gzip), is slower on the compression side, but much faster on the decompression side than gzip. Consider that you typically compress the image one and decompress it many times. Personally I can live with a slower image capture once than many image deployments. I can tell you in my environment I can deploy a 25GB image in about 4 minutes.
@langerwo said in Questions about how FOG is Working:
Hardware/Software inventory ( i think there is no software inventory)
Hardware inventory is done either through the registration process of a new computer, or via the fog client service that gets installed in your golden image prior to capture. There is no software inventory. If you need this kind of information then you need to use a third party tool like PDQ Inventory, OCS, Spiceworks Desktop, etc.
software deployment
Software deployment is done by creating what FOG calls snap-in packages. These are deployment packages picked up by the FOG client service running on the deployed computers. Or you can use a tool like PDQ Deploy
unattend installation
This is a function of your target system OS. FOG does’t care about OOBE or kickstart operations of the target OS. If you are talking about MS Window, then you will need to build a golden image, sysprep it, capture with FOG and then deploy with FOG.
i know for the unattend i need a prepared Image and the Software deployment works with some kind of plungins
Again if we are talking about MS Windows, you need to build your golden image in Audit mode, or use Microsoft Deployment Toolkit (MDT) to create your golden image with all of the windows updates and applications installed. There is no fog plugin to do this, FOG is an image cloning tool.
but how is the Hardware inventory working? is there a PXE image loaded? And whats inside?
FOG uses the PXE process to transfer the FOS (Fog Operating System) to the target computer to capture and deploy images. FOS is a highly customized linux operating system built specifically for image capture and deploying withing the FOG environment.
@Pistachio I’m not sure I totally understand your question, but let me tell you how fog works.
There are two elements to a fog image. The first is the meta data that is stored in the database. This describes the image. The second is the raw image files stored in /images/<image_name> directory. If you update the meta data then only the database record is changed. If you recapture an image then the raw data files are updated.
Now you have to be careful if you change certain meta data that describes the information contained in the raw image. For example if you captured an image using gzip partclone and then change it to something else or change the format from single disk non-resizable to single disk resizable you will have issues. Because the actual image files will not match what the meta data is telling it to do during deployment.
There are some meta data that if changed will not have an impact on an already captured image like compression index. That value is only used when the image is captured. On deployment the fog image decompressor just decompresses what has already be compressed it doesn’t care about the compression ratio.
When you see NBP in the pxe boot loader that tells us your target computer is in UEFI mode, the error picture indicates you are sending undionly.kpxe to the target computer. Undionly,kpxe is a bios mode boot loader. For a UEFI system you need to send ipxe.efi boot loader. From the screen shot of your router’s dhcp settings it appears that it doesn’t support dynamic pxe boot file names. In that it will send a bios boot loader name for a bios system and a uefi boot loader name for a uefi base system.
static ip address management post install. Not a problem. DHCP is only required if you need to PXE boot into the FOG iPXE menu or for capture/deploy activity. After image deployment the target computer checks-in to the FOG server using the FOG Client service so that is how the FOG server knows about the target computer.
Driver install for single golden image. Its not easy, but not hard either. If you use Dell computers then Dell provides the driver cab files as you need them. You can look over these tutorials: https://forums.fogproject.org/topic/11126/using-fog-postinstall-scripts-for-windows-driver-injection-2017-ed and https://forums.fogproject.org/topic/8889/fog-post-install-script-for-win-driver-injection for guidance. You will need a little linux experience to setup, but its not too hard.
MDT driver less: Yes you can. We will build our golden image using a virtual machine. We use ESXi virtualization, but you could use Hyper-V or VirtualBox to build your golden image. Then capture from that visualized machine. But I do recommend that you install the Dell Win10PE drivers in the Out of box drivers section to make your deployment life a bit easier. These are generic drivers that will allow your target computer to initially get connected to the network and talk to the storage device. There are plenty of how tos out there on how to setup and MDT environment. The deployment research web site is pretty handy too with info.
@agray said in Generic Questions about FOG Project:
Would out company using a static network pose any problem with the PXE booting process?
Yes and no. FOG (actually PXE Booting) requires a dhcp server to send out the proper net boot information. This is a requirement of PXE booting specifically. FOG leverages this to send a boot kernel to the target computer over the network then that boot kernel loads the imaging operating system called FOS. Once imaging is complete your target OS can use static IP addresses. If you can’t (by some regulatory requirement) use dhcp on your business network, then setup a specific and isolated imaging network where you can pxe boot computers to capture and deploy target computers. Its a bit more work to do it this way but it will meet your regulatory requirements. An isolated imaging network can consist of just a fog server and isolated network switch.
We usually buy a bulk of 5-8 Dell Optiplexes. I read FOG was hardware independent on the website, would that allow for the use of say a image of an Optiplex 3040 to be put on a 3050?
Typically what some will do is create a single golden image for all target hardware. Then all of your systems are exactly alike in configuration. The only thing you need to work out is to ensure the 3040 drivers are loaded on the 3040 hardware and the same for the 3050. This is an issue you will need to address regardless of the final imaging solution you pick. Some deployment tools will allow you to inject model specific drivers post imaging. There are ways to do this with FOG. Its not a native solution but not too hard to setup. I have a few tutorials on how to do this. Another solution some people pick is to just install all drivers for all models into the golden image. This makes a very fat and bloated image, but its one way to go about it. On my fog server I have about 15GB of drivers for about 20 different models of Dell computers. If that was in my golden image I would have to push out all of those drivers if they were needed or not on every deployment. The last way I’ve seen people do this is to have an image per hardware model. So in your case you would have one image for the 3040 and one image for the 3050 with the proper drivers loaded in each. It gets a bit messy having to manage one image per model but that way can work too.
In my company’s case we have one golden image for all and then inject the proper drivers based on the target hardware using FOG’s post install scripts.
@Tom-Elliott said in Generic Questions about FOG Project:
I like @george1421 method of imaging however. Use the MDT utility to build a reference image quickly. Then use FOG to capture the reference for easy deploying.
This is the approach that we’ve been using in house since 2013. If you are smart with your task sequences and use folders for your task sequences you can quickly upload a new Win10 release, copy over your task sequences folder and deploy the next release in about 10 minutes. MDT has saved us a bunch of time not having to do things by hand in Audit mode.
Tom you also hit on a very good differences between (MDT/WDS/SCCM) in that they use file level imaging which is surely slower than what FOG and clonezilla uses with block level imaging. Both methods have their advantages, but if your main constraint is time, FOG/Clonezilla is much faster to push an image than MDT/WDS/SCCM. With FOG I can push a 25GB reference image to a bare metal target computer in just about 4 minutes. That’s going from bare metal to Windows OOBE running in about 5 minutes. At the end of OOBE I have a computer connected to AD and is ready to move to the desktop that has all of the common SOE applications already installed.
@agray said in Generic Questions about FOG Project:
So, would it be possible to just run the server in a VM on a windows server?
Unfortunately I’m the only one with any Linux experience (about a year) and I’ll only be here till I graduate. You say “to run the application code,” would there be a way to put the server on a Windows Server without a Linux VM?
FOG only runs on Linux. You can run it as a VM in a Hyper-V environment, but FOG has the requirement of Linux under the hood. The target computer OS can be linux, windows, chromeOS.
Is fog only remote? If so, how does that play into us getting new PCs via Dell/Amazon? Would we just need to plug them into the network and then use the Management Interface?
FOG uses the PXE booting process where you bring in a bare metal computer connect it to your network and then net boot it into the FOG iPXE menu. From there you can register the target computer with FOG and then manage it from the FOG server or just pick the deploy menu if its a load and go environment where the fog server will never see the target computer again, such as in a PC remanufacturer.
If you are going to have a mix of hardware, such as buying the cheapest computer every time, you will have a hard time managing your fleet of computers with what ever solution you work with. The issue is the drivers required. If you follow the lite touch approach you only load the drivers that are necessary to get the system booted then during Windows OOBE the proper drivers are loaded into the system. You can do this by including every possible driver in your golden image or by having your deployment tool inject the proper drivers during the image push.
