Posts made by Trevelyan

I haven’t really noticed this before until I was just browsing the replicator, task scheduler and multicast logs. They seemed to have been updated fairly frequently, but then they stopped. It was then that I noticed that the respective services just weren’t running at all and had to be manually started. However, at first they fail; until I manually attempt to stop them (although they didn’t appear to be running):

Restarting FOG Computer Imaging Solution: FOGImageReplicator                 start-stop-daemon: warning: failed to kill 1154: No such process
Restarting FOG Computer Imaging Solution: FOGScheduler                       start-stop-daemon: warning: failed to kill 1230: No such process
Restarting FOG Computer Imaging Solution: FOGMulticastManager                start-stop-daemon: warning: failed to kill 1197: No such process

Now when I try to start them, they work. They’re started from init.d - so are they supposed to have been started on system boot?

Cheers

How did this work? I never really used it before; did a host checkin its IP to its entry in the FOG database when the FOG service started (or when it PXE booted)?

So I just tried something else instead;

• Fresh FOG install
• Gave the database a password again
• Same error

Looking at /opt/fog/.fogsettings, there is no username or hostname there under snmysqluser or snmysqlhost; how come? Could this be the cause at all?

After filling both in, I ran dpkg-reconfigure mysql-server-5.5 as suggested somewhere else and that has fixed it. There is just one mysql service running now.

Also - that is some broken formatting below

Is it just avoiding possible data corruption, or certain data corruption? I haven’t seen any ill effects of not changing, to be honest. I’ll keep going without changing it but keep it in mind anyway. Thanks for explaining it!

Cheers for the responses guys, works either way I guess. Still not sure why those two lines were commented out in the above guide - and I haven’t actually had to change my /etc/exports file either.

Thanks!

Hi guys, just looking for some explanations really

First of all, I haven’t really been able to understand, or find anything on, what “undionly.0” is and why its needed. Here’s my ltsp.conf file, modified after a 1.2 FOG installation:

[CODE]
port=0
log-dhcp
tftp-root=/tftpboot
dhcp-boot=undionly.kpxe,10.1.63.202
dhcp-option=17,/images
dhcp-option=vendor:PXEClient,6,2b
dhcp-no-override
pxe-prompt=“Booting FOG”, 0
pxe-service=X86PC, “Boot from network”, undionly
pxe-service=X86PC, “Boot from local hard disk”, 0
[/CODE]
This gives a “TFTP Error - File Not Found” at PXE boot. If I copy undionly.kxpe to undionly.0, however, it works fine. I’d imagine a symlink should sort this; but what I don’t understand is
[LIST]
[]Why this didn’t come in the fog installation by default (I had to do this myself)
[]What the significance of the .kpxe file not loading and why a .0 file has to be used instead?
[*]Finally, I don’t remember doing this before when I set a 1.2 FOG server up, but I must have done, since it exists, now that I have had a check. It was, however, “modified” after the rest, so I suppose I made it myself!
[/LIST]
Next - what do the following two lines do? They appear to be commented out in the new version of the guide for [URL=‘http://jbob.io/wiki/index.php/Using_FOG_with_an_unmodifiable_DHCP_server/_Using_FOG_with_no_DHCP_server#DNSMASQ_settings_for_iPXE’]DNSMASQ configuration for iPXE[/URL] - but it isn’t actually explained why.
[CODE]
#dhcp-option=17,/images
#dhcp-option=vendor:PXEClient,6,2b
[/CODE]
Finally, I don’t really understand why [I]/etc/exports [/I]is changed from:
[CODE]/images *(ro,async,no_wdelay,insecure_locks,no_root_squash,insecure)
/images/dev *(rw,async,no_wdelay,no_root_squash,insecure)[/CODE]
to
[CODE]/images *(ro,sync,no_wdelay,insecure_locks,no_root_squash,insecure,fsid=1)
/images/dev *(rw,sync,no_wdelay,no_root_squash,insecure,fsid=2)[/CODE]
Any explanations are very much appreciated

Thanks!

need2 - yes, and you get the usual error relating to the DB already existing. Unless you mean to reinstall FOG…

Tom - somewhere you suggested at https://github.com/fogproject/fogproject/issues/1 this - so now actually, all I’ve had to do is the line where it says:

echo manual | sudo tee /etc/init/mysql.override

The output suggests that mysql isn’t running at all now - just mysql_d/safe.

root      1459  0.0  0.0  4440  700 ?        S    16:55  0:00 /bin/sh /usr/bin/mysqld_safe
mysql    1811  1.6  1.3 615736 53348 ?        Sl  16:55  0:03 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib/mysql/plugin --user=mysql --log-error=/var/log/mysql/error.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock --port=3306

So far, it works fine. Hopefully one day a definitive cause to everything will be found and things will make sense

Cheers again!

Yeah I just used the PIDs as thats what I have at the moment, I know itll change, but you get the idea

I’ll keep digging then and update this if I find anything else!

Cheers

Hi all,

Had it before, and I know there’s a few causes of this, but is there a definitive writeup on the causes for this?

• New 14.04.2 server
• Installed FOG
• Imported over an existing database
• Everything seemed to work fine
• Altered /opt/fog/.fogsettings to remove the password from the password field, but I kept the snmysqlpass, since my sql database has a password

On system startup, everything works fine… for a while. Then eventually, that database schema message comes up. Can’t say how or why, either.

Here is what happens on a system reboot:

[CODE]local_admin@fog:~$ ps aux | grep mysql
mysql 1089 2.3 1.2 821128 49136 ? Ssl 16:11 0:00 /usr/sbin/mysqld
root 1486 0.0 0.0 4440 700 ? S 16:11 0:00 /bin/sh /usr/bin/mysqld_safe
mysql 1838 0.1 0.8 380768 33084 ? Sl 16:11 0:00 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib/mysql/plugin --user=mysql --log-error=/var/log/mysql/error.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock --port=3306
[/CODE]

Eventually, you get the schema message. I can either kill process 1089 (which kills all three sql processes and restarts a new one) or I can wait even longer and just 1486 and 1838 die anyway, leaving 1089 (which I have to also restart). Either way, on a restart it looks like this:

[CODE]local_admin@fog:~$ ps aux | grep mysql
mysql 2627 7.0 1.0 418540 41640 ? Ssl 16:16 0:00 /usr/sbin/mysqld
[/CODE]
So all the SQL services died, but then just one will end up running and Fog web management works fine again.
I had this before and totally forgot what I actually did to fix it!
Cheers,
Oliver

Ah cool, there hasn’t been a client update in a long time, right? What’s the plan for it?

Works fine after doing delayed start.

But this kind of tallies with this:

[QUOTE][FONT=sans-serif][COLOR=#000000]One of the first things we try to do in mStart is to sleep for a fair amount of time if the process we are doing does not need to run right at service startup. [B]The idea behind this is that the Windows startup process can be very slow in the first place, so we don’t want the fog service to break the proverbial “Camel’s Back”.[/B][/COLOR][/FONT][/QUOTE]

[url]http://www.fogproject.org/wiki/index.php/Creating_Custom_FOG_Service_Modules[/url]

Im convinced its to do with the speed of services starting up, affected by the SSD in a system. If anyone disagrees, suggest an alternative

A similar thread to this seemed to die - if these are broken, the wiki should be updated with that…

Hi all,

Does anyone have any idea how these services work and whether or not they actually work properly in Windows 7?

I enabled Directory Cleaner and specified the directory C:\Users - thinking that it would delete all folders in there and not the Users folder (as stated on the fog guide).

However, I get this kind of error:

25/11/2014 10:59 FOG::DirCleaner at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.Directory.DeleteHelper(String fullPath, String userPath, Boolean recursive)
at System.IO.Directory.Delete(String fullPath, String userPath, Boolean recursive)
at FOG.DirCleaner.recursiveDelete(String strRoot)
25/11/2014 10:59 FOG::DirCleaner [B]The directory is not empty.[/B]

Well of course it isn’t empty, that’s why im telling it to clean it.

User cleanup also seems to not, well, clean any users either. I would have thought that one of them would remove a user’s folder on logout at least but it seems not.

Any ideas or suggestions?

Cheers!

Un-ethically, we have everything set to not power down or use power saving modes currently. WOL might work but for the last year or so its been put on the backburner because getting it to work with systems we have limited control over was proving a hassle.

Windows 7. But this sounds kind of logical…

Yeah we know about it and have worked around it with no hassle - actually that has been a way to determine if someone has plugged a machine into the wrong port and we have actually started disabling the second network controller in bios often. I am pretty certain that the adapter isn’t the issue (if it was, it wouldn’t work in either of the cases)

But the key point is that with the same image, on essentially the same hardware, the fog service acts differently - seemingly down to whether or not it uses an SSD. On the SSD machine, the fog service gives the errors - but if you restart the service (stop and start), it works fine.

I just tried to set it to “Automatic (Delayed Start)” and - bizarrely - it is now working fine for those machines that I have done. Could it possibly be that some service is being relied on by FOG that hasn’t started at the point which it is needed? Its really all I can think of - and that could be down to my individual build ultimately. But it isn’t something we have ever seen as an issue before.

On most of our PCs there are, yes - DQ77MK motherboards have an Intel AMT management port and we avoid using this. I’ll reply back here after I try out the delayed start works as I thought it might - but I don’t think having an SSD on the system should make any difference at all. But… it does seem to. Somehow.

I’ll try and update to it - is it going to eventually be a part of the next FOG update then?

And what do you think would make this issue present on only some machines (which happen to all be machines with SSDs)? I never accepted any of the pending MAC addresses (as this did give an issue in 0.32 when I tried to accept one, once) and unless the machine boots from an SSD, it works fine.

Thanks!