@fry_p zstd is a newer and a bit more advanced than the gzip image compression.

Starting with FOG 1.3.5 zstd is used as the decompression engine for FOG (it can read both formats). So you will get some speed improvements over FOG 1.3.4 by just upgrading. To get the most speed out of the system you need to recapture your image using zstd. This can be as simple as deploy an image, change the image definition to zstd and then recapture the image right away. I can tell you upload is much slower than gzip, but the advantage of zstd is better data compression (on the fog server) and a much faster image deployment on dual core and better processors (on target computer).

While this thread has run on a bit I think a lot of great info has been covered.

I’m thinking I need to rebuild my whole POC setup because I think the function of the storage node is just for storage (just a guess at this time) and the master node is my current production instance (blindly upgrading svn version has disabled my production instance in the past). But that’s part of running on the bleeding edge.

What I need for this project is two (or more depending on scope creep) functioning FOG instances managed from a single master node. These may be connected across a VPN link or a MPLS link. At this time I’m not sure if FOG is the right tool. I’m not saying FOG is bad, just I’m trying to do something with it that it wasn’t really designed to do. With the idea of linking the master and secondary nodes via the database connection might prove to be problematic over a WAN connection with latency issues. Again this is just me thinking about things I’ve seen in the past on other projects. I do have the cpu bandwidth to spin up two new fog instances to setup the POC in a controlled manner without breaking our production system (which works really well).

In reality the fog server doesn’t (shouldn’t) use much CPU for imaging. During the imaging process the FOG server is reponsible for managing the imaging process and moving the imaging files from the local disk to the target computer. That’s all. All of the heavy lifting is done by the FOG client. I even setup FOG on a raspberry pi2 server. This setup ran well for up to 2 simultaneous unicast images.

The target computer is responsible for image compression and decompression.

If you want to image faster using unicast, add more spindles (disks) to the server, use faster disks, setup a network lag group to share the networking load, use the new and faster image compression formats (zstd) and deploy to fast target computers.

Your fog server cpu spiking could be related to insufficient ram in your fog server, or a slow disk subsystem.

A PRT record is a reverse lookup for DNS. Basically it asks DNS for this IP address what is its conical host name.

While I haven’t read this entire thread, for DHCP its best for option 66 to be an IP address and not a conical host name. Some PXE clients are just not that smart enough to know how to look up a name for option 66, so set it to the IP address of the FOG server.

Also I know they have been working on the boot image (in the last 3-4 days) where it was getting stuck at the initialing devices. You may want to try to update to the latest SVN. It sounds like you are almost there.

@ty900000 said in FOG Server CPU Requirements:

I’m going to turn one of our “newer” systems into a FOG beefcake server when we reimage over 20-30 machines at a time and I’ll use a RAID 10 setup.

Really if you are going to image that many systems at a time I would look at multicasting the image to the machines. That way only one data stream is sent out to all systems. You need to have a network configured to support multicasting but with FOG multicasting does work well.

I know some educational groups that will reimage an entire classroom of computers (>25) between classes using multicasting.

Not to send you down a rabbit hole here, but I take it you don’t have a reverse lookup zone created for your DNS server. Because looking at the capture its looking for the 10.0.0.51 address but the reply from DNS is name not found. Can I guess that 10.0.0.51 is your FOG server? Outside of the scope of this project you should ensure you have a reverse lookup zone created in DNS.

Here is a how to for 2012. http://www.tomshardware.com/faq/id-1954333/create-reverse-primary-dns-zone-windows-server-2012.html

@Junkhacker said in FOG Server CPU Requirements:

@george1421 said in FOG Server CPU Requirements:

I would expect a single unicast image to deploy about 6GB/m on a typical solid network.

is a typical network really that slow?

Yes I still have network envy of your setup. But not everyone has all gold and chrome computers either.

Bingo, I have it.

I have two ways to boot a MDT litetouch image via FOG.

1. The first way is how I stated to take the iso image created by MDT and move that to your FOG server (on rhel variants) in /var/www/html/iso folder. The file I used was to move LiteTouchPE_x86.iso from the MDT deployment share to that …/iso folder as ltpe_x86.iso. Then to create the PXE boot menu as I outlined below. The freeze issue I had was related to how I created the VM. I created it as a linux VM not a windows VM (shame on me). Once I reset it to a windows 7 VM the system booted to the lite touch menu.

2. By using instructions found in Wayne’s link below. http://ipxe.org/howto/winpe I used this as the bases of option 2. I’ve created WinPE USB boot drives so I already had WAIK installed and already had a boot.wim created, so I’m not going into that part. But in the target winpe environement I took the ISO folder and moved it to the fog server in /var/www/html/ISO (which is different than the <lowercase> iso folder from option 1). I placed the wimboot file (downloaded from the link provided by Wayne) in the web root folder /var/www/html. Then copied the LiteTouchPE_x86.wim from MDT deployment share to /var/www/html/ISO as boot.wim. And finally created the FOG PXE menu with these settings.
   Menu Item: winpe.BootMDT_x86
   Description: Boot MDT LiteTouch x86
   Parameters:
   kernel http://<fog_server_ip>/wimboot
   initrd http://<fog_server_ip>/ISO/boot/bcd BCD
   initrd http://<fog_server_ip>/ISO/boot/boot.sdi boot.sdi
   initrd -n boot.wim http://<fog_server_ip>/ISO/boot.wim boot.wim
   boot

I still would like to understand how I can use the variables to the fog server IP address so I don’t have to hard code the IP address into the boot menu. That would make the instructions a bit more dynamic.

Understand what I’ve done is a first pass attempt to make FOG deploy both FOG images and to launch MDT’s litetouch image without the need of a WDS server (which would have made things a bit easier in one respect)

Its not possible to capture an image live like that. FOG uses a customized linux image that is deployed to the target computer over the network. You have to stop and properly close the image before it can be cloned. This is the same case for tools like clonezilla and to a lesser extent Symantec ghost. The target OS must be powered off.

FWIW: All of the 7010 SFF Dells we have have “Intel 82579LM Gigabit Network Connection” according to our inventory tool.

@chris178 Look in the FOG community scripts on git-hub: https://github.com/FOGProject/fog-community-scripts

Wayne wrote an excellent script called MakeFogMobile Download and install that. His script sets up a cron job to check to see if the IP address changes if so then it updates the fog configuration.

Well now I’m confused. Here is what you posted before.

This is what it shows when I try to boot to the fogserver:

CLIENT MAC ADDR: 00 22 64 BB 04 DF GUID: 0CD117C8 1FDC DD11 BBDA 64BB04DF0022

CLIENT IP: 10.1.8.59 MASK IP: 255.255.255.0 DHCP IP: 10.1.8.254
GATEWAY IP: 10.1.8.254
PXE-E32: TFTP open yimeout
TFTP…

And you also stated

well the fogserver ip is 10.1.8.1

I’m only seeing a single subnet net here. And all devices mentioned are on 10.1.8.0/24 subnet. The root of the issue I see so far is that the FOG server 10.1.8.1 is not being used for dhcp so any settings you make to FOG will not impact the booting process so far. But the client is reporting that 10.1.8.254 is being used for dhcp booting (which I’m still suspecting is a router). Reading a bit more into the what as not been said yet. Since you introduced the concept of a quarantine network, I get the feeling that 10.1.8.254 is a router interface that has a dhcp-relay setup on it that points to a master dhcp server some place else on another network.

I’m trying to help here but I’m not getting the big picture of how this is setup.

@dpotesta50 (snarky: I did amend my original post to reduce the snark level).

The unattend.xml and setupcomplete.cmd files are something created by your previous admin to tweak your windows 10 build post image deployment with company/site specific settings. You may want to review these files to understand why he felt the need to do this. I can tell you its common practice to use the unattend.xml and setupcomplete.cmd files. So the short answer is yes you may need them.

If you don’t have them, and your previous admin used them, I can tell you how to collect them (assuming they are in your master image today). Take a computer and deploy your standard image to it, when FOG is done, power off the computer. Take the hard drive out and add it as a second drive temporarily in another computer. This will give you access to the media to collect these files.

While I’m not the sharpest tool in the shed, but wouldn’t this imply that the OP has the right settings for dhcp?

When I try to pxe boot, I am getting the message “Could not start download: Operation not supported (http://ipxe.org/3c092003)”

If the OP is getting a warning message that indicates “ipxe.org”, it would seem that the ipxe boot file [udnionly.kpxe] made it to the target computer, since the PXE boot loader doesn’t know anything about ipxe? and ipxe is generating the error.

OP are you getting any bits of the boot menu? Maybe a screen (mobile phone) shot of the boot screen might give an indication of the root of the error. The error basically says you tried to use a protocol that isn’t supported by this ipx kernel. This is not something that is in the OPs control.

If you install FOG you will solve points 3 and 4 of your task list. FOG will automatically setup tftp booting and NFS. FOG uses both to pxe boot target computers. I have a few tutorials on how to setup dnsmasq. It is not very hard. Plus many of the distributions are now offering dnsmasq versions 2.76 or newer so you don’t have to compile your own version. Version 2.76 or newer is required to support dynamically switching boot files between uefi and bios/legacy target computers. Each firmware type takes their own specific boot file.

Using your distribution’s packaging tool, go ahead and install dnsmasq package. I have to get ready for my commute into work, but I will provide you with a functioning configuration for dnsmasq in about 1.5 hrs.

edit: Use the ltsp.conf file from the end of this post: https://forums.fogproject.org/topic/8725/compiling-dnsmasq-2-76-if-you-need-uefi-support/6 replacing your fog server’s IP address in the config file.

@bacelo said:

@george1421 and the thing that bugs me more is that they have this working in other schools. They say that they don’t have a firewall. And I don’t think that they will let me manege the dhcp

Are they unable to update the dhcp settings for you? All they need to do is to change dhcp settings 66 to point to the ip address of your fog server and dhcp option 67 to point to the boot file. That is all the action they need to do for your dhcp scope. Nothing else needs to be managed.

@cmcgonag Now we know that you are talking ubuntu here. There are things you can do today to make this happen. There is no need to image a ram drive, just use a live boot media. Then use FOG iPXE to deliver the live boot media to the target computer.

Ref: https://forums.fogproject.org/topic/10944/using-fog-to-pxe-boot-into-your-favorite-installer-images

This will give you the same results as deploying to a ram drive in that it will have to be rebuilt each time you boot. You will just need to setup an NFS share to keep persistent data. Beyond that you can create a custom ubuntu live boot image and still deploy that via iPXE to your target computers, using FOG.

@kbramhall If fog doesn’t fully setup the first time then no it will not display the console login.

I would suggest that you go back from the beginning and select no for dns and no for dhcp. You can set those up later if you really need them. The packages are downloaded and installed then the database is configured then the apache settings are configured.

@junkhacker Other issues as Wayne pointed out. The Pi is an ARM processor.

[enable brain storming mode]
So the ipxe files need to be recompiled for ARM (cortex) processors. From what I found there are ARM compatible iPXE boot files. The developers would need to cross compile the iPXE boot files to include the FOG scripts into ARM version of iPXE.

Also FOS is currently based on IA86 arch, meaning FOS (bzImage) and init.zx need to be cross compiled for ARM. I’ve done a little work with buildroot (used to create FOS) and buildroot does support cross compiling for Cortex processors.

So technically its possible to have FOG deploy to raspberry pi systems. The last bit we would have to deal with is the motivation of the developers to go down this path. (not speaking for the developers, only my opinion) I’m not seeing the “market share” of deployments required to go down this path. I really see this as a one off solution, were there are other documented and proven ways to deploy to the Pis. I do agree that it would be a really neat feature to add, but again not as a focus for the developers. There are enough issues with new “bleeding-edge” IA86 compatible systems coming out to keep them very busy as it were.
[disable brain storming mode]

In addition to MBR disks, ensure you are in BIOS mode not UEFI. The two mentioned version of FOG do not support UEFI very swell (0.3x ==no, 1.2.0 == some times)