@Tom-Elliott Don’t get mad, I was making this remark to help future newcomers, not to troll you. I know how it works now, just trying to help in making it better, not only for the hardcore/oldschool users but for newcomers also.

Note that English is not my native language, I am not trying to be a grammar professor here. In the wiki the word image is mostly used as a thing (an image), not a process (to image).

See https://wiki.fogproject.org/wiki/index.php?title=Managing_FOG#Hosts

Images
Image objects in FOG are the representation of the physical files that contain the disk or partition images that are saved on the FOG server.

See https://wiki.fogproject.org/wiki/index.php?title=Managing_FOG#General_Tasks

General Tasks
The general/common Tasks in FOG include unicast image upload, and unicast image send, as well as a multicast image send. In FOG, sending an image to the server is considered an image upload, and deploying an image to the client is called a send. Both of these tasks can be started directly from the search, list all hosts, and list all groups pages.

In the wiki the terms upload and send are used and explained, but in the web console (GUI) it’s called capture and deploy in the menu and tooltip. So the wiki and GUI and boot menu are not in sync.

From a usability perspective I would suggest that you choose 2 words (like capture and deploy) and then use the same terms in the wiki, the UI and the client boot menu. One line of text describing if it goes from client to server or from server to client, would not hurt. When you are standing before a client, that just PXE booted, the wiki is not at hand.

@Wayne-Workman : You were right. I built the following: a physical fog server (a laptop) connected to a netgear pro switch, capture and deploy an other laptop, first with unicast then with multicast. Now there is almost no difference in deployment time, multicast takes about 20 seconds longer. Nothing else was connected to the test-network.

Conclusion: a good switch does make a difference. Thanks for the tip.

I wonder if the compression factor used makes a big difference in speed. Storage is cheap, time is money… Going to test that next.

@Wayne-Workman : thanks for the answer. Both the laptop and the Brix mini-pc I use have a wifi adapter that is not standard supported by the Debian installer. But since I intended to deploy using ethernet cable only, I ignored the wlan interface and indeed did not configure it. Hyper-V virtual servers don’t have a wlan adapter, so the error did not occur on that. It seems ics-dhcp has a problem with non-configured adapters.

Note: on Debian 8 (also Ubuntu I think) for the ISC DHCP server it should not be the file:
/etc/dhcp/dhcpd.conf
And also not:
/etc/default/dhcp3-server

For Debian 8 the correct file is: (it took me some time to figure this out, my Linux is not so good)
/etc/default/isc-dhcp-server
There add the line:
INTERFACES="eth0"

Running this release on a Dell Lattitude laptop in Debian 8, capturing and deploying HP, Dell, Toshiba and Asus (mostly old and donated) laptops, I cannot find an issue. It just works great. The only critique I can think of is that it says “Dashboard” twice in the console home screen, that is redundant and takes up space. Tom please don’t get mad. I’m now a real Fog fan and recommending it at educational fairs and other places I meet educational sysadmins. It’s a great solution if your working under a tight budget. Good work!

Ok this is a very small thing but I am enjoying this disk cloning solution, so I hope my small newbie contributions help a bit.

In GIT (trunk) version7917 on Debian 8. When adding a new storage node, the field Web Root is blank. The wiki does not tell what the value should be by default. After trial and error I found out it should be /fog in there, not blank. After typing that and saving, it connects in the dashboard and starts replicating after a while, just as advertised.

I made the storage node on a QNAP NAS, inside a Debian virtual machine using the QNAP “Virtualization Station” app that comes free with the NAS and followed the FOG wiki for install instructions. Works fine!

The /fog value for Web Root should be a default I think, so you don’t have to guess when adding a storange node. Keep up the good work, greetings from Holland.

Not a big problem this, more a usability suggestion:

In the Fog client there is a menu option: Quick image

Does this mean Quick Capture or Quick Deploy (image upload or image download)? Sending an image the wrong way could destroy hard work, so I have avoided an option that maybe can be useful. “Deploy on demand” would be clearer for me then “Quick image”.

Also when you choose the menu option: Full inventory (and something) at the end of many questions is asked “do you want to image now?” Again image upload (capture), or image download (deploy)? Please stay true to Fog terminology to not confuse stupid users like me.

@MRCUR

I have to disagree with this. When you use “image” as a verb, it implies that you are downloading the image to the computer.

In the past I have tried and/or worked with (but i prefer Fog over them):

• Symantec Ghost Solution Suite
• Acronis Snap Deploy
• Clonezilla
• Trinity Rescue Kit
• CloneDeploy
• WDS: Windows Deployment Services

In those systems “making an image” or imaging means copying all the data from a (client) hard disk to a file (on a server or somewhere). Bringing the data back to a client system is called deploy, send, push, download or restore. I do not care how it is called in Fog, just keep it the same in the console, the boot menu and the wiki. Capture/Deploy works fine for me.

Running this release on a Dell Lattitude laptop in Debian 8, capturing and deploying HP, Dell, Toshiba and Asus (mostly old and donated) laptops, I cannot find an issue. It just works great. The only critique I can think of is that it says “Dashboard” twice in the console home screen, that is redundant and takes up space. Tom please don’t get mad. I’m now a real Fog fan and recommending it at educational fairs and other places I meet educational sysadmins. It’s a great solution if your working under a tight budget. Good work!

@Wayne-Workman : thanks for the answer. Both the laptop and the Brix mini-pc I use have a wifi adapter that is not standard supported by the Debian installer. But since I intended to deploy using ethernet cable only, I ignored the wlan interface and indeed did not configure it. Hyper-V virtual servers don’t have a wlan adapter, so the error did not occur on that. It seems ics-dhcp has a problem with non-configured adapters.

Note: on Debian 8 (also Ubuntu I think) for the ISC DHCP server it should not be the file:
/etc/dhcp/dhcpd.conf
And also not:
/etc/default/dhcp3-server

For Debian 8 the correct file is: (it took me some time to figure this out, my Linux is not so good)
/etc/default/isc-dhcp-server
There add the line:
INTERFACES="eth0"

@Wayne-Workman

ip addr show dump:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 00:1f:16:a9:71:86 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.8/24 brd 192.168.0.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::21f:16ff:fea9:7186/64 scope link
valid_lft forever preferred_lft forever
3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000

@Wayne-Workman : You were right. I built the following: a physical fog server (a laptop) connected to a netgear pro switch, capture and deploy an other laptop, first with unicast then with multicast. Now there is almost no difference in deployment time, multicast takes about 20 seconds longer. Nothing else was connected to the test-network.

Conclusion: a good switch does make a difference. Thanks for the tip.

I wonder if the compression factor used makes a big difference in speed. Storage is cheap, time is money… Going to test that next.

Fog 8623. I have had the following issue during 2 Fog builds on physical hardware, installing fog on a laptop and also on a gigabyte Brix mini-pc. When running the install script, I choose YES when install asks if I want to use Fog DHCP server. After a reboot, the ics-dhcp server exits with an error. The strange thing is that this error does not pop up when installing Fog inside a virtual machine (Hyper-V). Operating system: Debian 8.4. I solved the problem by installing Webmin and then connecting the dhcp-server to interface eth0 and then restarting dhcp (with Webmin). But there must be a quicker solution. Here is the error:

 isc-dhcp-server.service - LSB: DHCP server
   Loaded: loaded (/etc/init.d/isc-dhcp-server)
   Active: failed (Result: exit-code) since Sun 2016-07-17 11:25:50 CEST; 4min 54s ago
  Process: 477 ExecStart=/etc/init.d/isc-dhcp-server start (code=exited, status=1/FAILURE)

Jul 17 11:25:48 acer dhcpd[555]: to which interface eth0 is attached. **
Jul 17 11:25:48 acer dhcpd[555]: 
Jul 17 11:25:48 acer dhcpd[555]: 
Jul 17 11:25:48 acer dhcpd[555]: Not configured to listen on any interfaces!
Jul 17 11:25:48 acer dhcpd[555]: 
Jul 17 11:25:50 acer isc-dhcp-server[477]: Starting ISC DHCP server: dhcpdcheck syslog for diagnostics. ... failed!
Jul 17 11:25:50 acer isc-dhcp-server[477]: failed!
Jul 17 11:25:50 acer systemd[1]: isc-dhcp-server.service: control process exited, code=exited status=1
Jul 17 11:25:50 acer systemd[1]: Failed to start LSB: DHCP server.
Jul 17 11:25:50 acer systemd[1]: Unit isc-dhcp-server.service entered failed state.

I read somewhere that if no interface is selected, the dhcp server will attempt to find one automatically. Maybe this is broken in ICS-DHCP 4.3.1 or in Debian 8.4? Strange it does work inside Hyper-V…

The dhcp config file:

0_1468751384623_dhcpd.conf

Hoping not to bother you guys to much. When starting a capture, this is the message I get. A bit confusing. I wanted to capture, not deploy. The text is off, the system works just as it should (capture, not deploy).

@Wayne-Workman : At the moment I am using a tplink 8-port switch. Just ordered a netgear pro 8 port managed switch, let’s see if it goes better with that.

@Tom-Elliott : The test I did was from a virtual server (Debian 8 inside Hyper-V) to a physical machine (a laptop). See the report picture above, “Acer” is the brand of the laptop.

@Tom-Elliott : The test was done at home, both the fog server (running on Debian in a Hyper-V virtual server) and the laptop are connected to Gb switch. There was almost zero network load during the tests. With unicast (normal deploy) I got 3 Gb/min. With multicast (to 1 client, the same laptop) I got not even 200 Mb/min. The firewall in Debian is turned off. Could the difference be because of Hyper-V? Next week at work I can try it in a different environment. Here is a photo during multicast deploy;

Is it normal for a multicast deploy session to be 30x slower then a “normal” deploy? Hope not. Maybe something is not right. I tried with the same (one) laptop, same image, same server, everything the same. Compression was set at 4.
PS unicast deploy goes really fast, probably at the max my hardware is capable of. Windows 10 deployment in 3 minutes, I like that…