Posts made by coco65

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…

@Tom-Elliott Wow great. Fog really works for me, and for many others I can imagine, just trying to help to make it better as much I can. Thank you.

@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.

@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.

@Tom-Elliott For newbies “Quick image” is not self-explanatory.

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.

@Tom-Elliott : Before starting with a fresh install, in my previous Hyper-V version of Fog;,

At the end of ./installfog.sh you get this:

#################################################################
   FOG has adjusted to using a login system to protect what can/cannot be downloaded
   We have detected that you don't have credentials defined to perform the backup
   If you would like the database to be backed up during install please define
   in your /opt/fog/.fogsettings file

   fogguiuser='usernameOfFOGGUI'
   fogguipass='passwordOfFOGGUIUser'

   You can also re-run this installer as:

   fogguiuser='usernameOfFOGGUI' fogguipass='passwordOfFOGGUIUser' ././installfog.sh
############################################################

So I copied and pasted

fogguiuser='usernameOfFOGGUI'
fogguipass='passwordOfFOGGUIUser'

into the fogsettings file.

Maybe it should have been:

fogguiuser='fog'
fogguipass='password' 

???

Remember as a normal user I am not so smart, just good at Ctrl-C and Ctrl-V.

@Tom-Elliott :

Make sure to update your /opt/fog/.fogsettings file for the password variable.

As a distribution platform I used a laptop as fog server, Fog in virtual Debian 8 running inside Hyper-V in Windows 10, and a switch to connect a bundle of laptops as clients. The laptop hd ran out of space for images so I used a NAS as Fog storage node. All way to complicated and a laptop hd is just too slow, so now I invested in a Gigabyte BRIX micro PC with a 1 TB Intel M.2 SSD inside as Fog server. Smaller and lighter then a laptop. Did a fresh install, Debian 8 and it works great and super fast. No more FTP password errors. Only some problems getting DHCP server to auto-start, the Network-manager in gnome was in the way. Solved that. Did an image pull, an image deploy and an image multicast (Windows 10 image). All works great. Next on my list is to test the Fog client in Win10. Just for fun tried a ClamAV virus scan job, that did not work. Maybe I have to install ClamAV first? Time to read the manual/wiki again, maybe that’s not implemented yet…

I am having exactly the same issue, after updating to 8347. Will a clean install help?

@Tom-Elliott : Thank you that works (the second version with systemctrl)

@Tom-Elliott

Just updated both the fog-server and the fog-node to 7945 on debian 8 both. Nothing has changed I am afraid. The fog server runs fine but the storage node is at a constant 100% processor load. The 4 FOG services (ImageReplicator etc) keep using every processor cycle they can get.