Hi matijn,

did you already try this?:
https://forums.fogproject.org/topic/10006/ubuntu-is-fog-s-enemy

We’re not on Ubuntu 18.04 yet and still running 16.04. But every time we update the OS by apt-get (doesn’t matter if upgrade or dist-upgrade) and it contains a SQL update the things described in the link above needs to be done.

If that solves your problem and you have some sort of automatic updates turned on you could think about to deactivate them and run them regularly by yourself.

If that doesn’t solve your problem maybe someone else has another idea.

Hi,

we just updated from fog 1.4.4 to fog 1.5.4. As far as we tested it looks fine but the progress bar when capturing/deploying an image behaves kinda weird:

At beginning all the information is squeezed in the little green status bar and after some progress there are more readable information. It’s the same in IE and Firefox.
(Capturing was tested on an older machine with higher zstd compression so the speed/time shown there is ok)

It is not that important but sometimes made it more easy to spot a computer with a slower network connection directly.

Thanks

@ravigon how about the values of igaPrimary (wonder why I wrote igaGroup …)?

What is the ID in “Storage Management” -> “All Storage Nodes” -> your storage node (normally “DefaultMember”) -> “Storage Group”? And are the other settings there correct?
Could you also check the Image Size log in “Fog Configuration” -> “Log Viewer” if there are any errors?

The Image Size Service seems to run every hour and check the image sizes (Fog 1.4.4):

...
[10-18-17 9:21:51 am] * Starting Image Size Service.
[10-18-17 9:21:51 am] * We are group ID: 1. We are group name: default
[10-18-17 9:21:51 am] * We are node ID: 1. We are node name: DefaultMember
[10-18-17 9:21:51 am] * Finding any images associated with this group as its primary group
...
[10-18-17 10:21:51 am] * Starting Image Size Service.
[10-18-17 10:21:51 am] * We are group ID: 1. We are group name: default
[10-18-17 10:21:51 am] * We are node ID: 1. We are node name: DefaultMember
[10-18-17 10:21:51 am] * Finding any images associated with this group as its primary group
...

But we once had a problem that its was not displaying the size for one or two images. The solution was that in the table “imageGroupAssoc” the value of igaGroup (?) was not “1” (I think it was 0).
After manually changing this value to 1 the next time the Image Size Service was running all of the images was showing the “Size on Server”. Dont’ know what caused this but we didn’t have this since then anymore.

So I think it’s worth checking the imageGroupAssoc table in the database and storage settings in FOG.

@george1421 this should be the correct solution
We’re also on Ubuntu 16.04 and the fog installer is failing at exactly the same point. After running the commands to alter the root user in mysql the installer runs fine.
I think this problem re-occurs even when just updating the system by apt-get sometimes - so I am running the mysql alter commands every time after apt-get to be on the safe side.

First of all thanks for this great project. We just switched our productive system for the students computer rooms from FOG 0.32 to version 1.4.4 and want to say something about what we experienced. Currently everything is working fine.

• The capturing and deploying is more fast and, at the same time, has a better compression (old: PIGZ_COMP = -6, new: Zstd 12)
• The display of the deploy/capture progress in the web interface is really great
• The new FOG client is reacting more fast after cloning and is saving some additional time
• A date filter for imaging log and snapin log is missing (but it will be added some time later - I asked that in an earlier topic)
• Snapin files once uploaded are now kept and are not deleted when uploading a new file to an existing snapin - (I just will cleanup the snapin directory from time to time manually - think I saw a SQL statement to list the files currently assigned to snapins somewhere in the forums to make it a little bit more easy)

We had a minor problem with the new client:

• The snapins (some batch scrips and sfx-archives) created for FOG 0.32 we could use without problems on 1.4.4 and the new client, except where we used reg.exe to change registry entries: without the parameter “reg:64” the registry entries were written to HKLM\Software\Wow6432Node\abc (In the batch file the path was “HKLM\Software\abc” -> without “Wow6432Node” !). Adding “reg:64” solved that and it also might be better to tell it explicitly to write in the 64bit or the 32bit part.

Something that is also different to FOG 0.32 is the queuing behavior (when unicast group deploying a room):

• In FOG 0.32 there always was was a fixed order which computer was cloned - in the new one its like first come first serve
  – when all computers are starting simultaneously there are more deploying at the same time than allowed in the storage node’s “max clients” option: e.g. 13 are allowed and it has been 14 to 16 for the first deploy batch of a room, the later computers normally will start when it is below 13 again but it can happen that 2 will start at the same time again (depending on the moment they try to check in I think) and it might be 12->14 again
• In FOG 0.32 the text for computers when waiting in the queue displayed the number of computer in before one (based on the fixed order?) - in the new FOG it is different
  – computers that started up with the other computers but didn’t get a free slot always display “0 before me”
  – computers that didn’t start up at beginning (WoL didn’t work, network cable was plugged out, …) are displaying the number of computers deploying plus the number currently queued as computers before one. (e.g. 14 computers deploying, 5 queued = “No open slots, There are 19 before me” for the 20th computer switched on)

The queue behavior describe above is not a problem for us - we just have to get used to it.

How are the load average on the machine? Without accessing the fog web interface I can see the following load average: 0,15, 0,14, 0,10 at the moment. When more computers are turned on / logged in the load is higher but still below 1 when I remember correctly.

While cloning (unicast) on the other side the average loads are very high at around 9 but everything still works fine.

@Tom-Elliott Thanks for your hard work - good to know it will be there in a future release.

In the Snapin Log the only date/time you can sort by is the crate date/time. This seems to make no sense for me since one snapin is created only once and even after updating/editing a snapin the create date/time wont change anymore.

I think the “Start/Checked in” and/or “Completed” date/time as columns you can sort by would be better. This way it would be more easy to verify if snapins were running fine.

Also a date range selection (like in FOG 0.32) for the “Snapin Log” and the “Imaging Log” would be nice if it is not too hard to implement.

Thanks

Here is the same message when updating 1.3.0 (revision 6050) to 1.3.1 (revision 6053) on Ubuntu 14.04 - it also says it can’t find the file, but the file is there in “/images/dev/postinitscripts/” and not “/images/dev/postdownloadscripts/”:

 ls -lisa /images/dev/postinitscripts/
insgesamt 12
3670017 4 drwxrwxrwx 2 root root 4096 Jan 16 09:18 .
 262145 4 drwxrwxrwx 5 root root 4096 Jan 16 09:18 ..
3670018 4 -rwxrwxrwx 1 root root  237 Jan 16 09:18 fog.postinit

The directory postdownloadscripts is here “/images/postdownloadscripts/” (without “/dev”) - but without the file “fog.postinit”.

ls -lisa /images/postdownloadscripts/
insgesamt 12
524289 4 drwxrwxrwx  2 root root 4096 Sep 23  2015 .
     2 4 drwxrwxrwx 10 root root 4096 Nov 11 14:42 ..
524290 4 -rwxrwxrwx  1 root root  233 Sep 23  2015 fog.postdownload