PXE Boot stopped working
-
Great, I’ll give it a try
-
[LIST]
[]Try using the TFTP troubleshooting. It may clue you in on the rights and existence of the files needed for IPXE boot. [url]http://fogproject.org/wiki/index.php/Tftp_timeout…#TFTP_Testing[/url]
[]Have you restarted the server lately? It is possible that the firewall re-initialized at boot. [url]http://fogproject.org/wiki/index.php/Tftp_timeout…#Ubuntu[/url]
[*]Have you had a network switch replaced lately? [url]http://fogproject.org/wiki/index.php/Tftp_timeout…#Check_Network_Switch_settings[/url]
[/LIST]
…and what Tom said! -
When did the problem start? This AM all of my FOG servers stopped working. The only change was a critical MySQL update that was preformed overnight. When I log into the FOG management window (browser) it want to run the database schema intaller/updater like it is a new install. Running it fails with an error. Trying to run it from the command line also result in an error.
Specifically if run from root: cd ~;mysqldump --allow-keywords -x -v fog > fogbackup.sqld: command not found
– Connecting to localhost…
mysqldump: Got error: 2002: Can’t connect to local MySQL server through socket ’
/var/run/mysqld/mysqld.sock’ (2) when trying to connectI am running Ubuntu 14.04LTS Fog 1.2.0
Mark
-
[quote=“Mark Cheavens, post: 40949, member: 28207”]When did the problem start? This AM all of my FOG servers stopped working. The only change was a critical MySQL update that was preformed overnight. When I log into the FOG management window (browser) it want to run the database schema intaller/updater like it is a new install. Running it fails with an error. Trying to run it from the command line also result in an error.
Specifically if run from root: cd ~;mysqldump --allow-keywords -x -v fog > fogbackup.sqld: command not found
– Connecting to localhost…
mysqldump: Got error: 2002: Can’t connect to local MySQL server through socket ’
/var/run/mysqld/mysqld.sock’ (2) when trying to connectI am running Ubuntu 14.04LTS Fog 1.2.0
Mark[/quote]
Make sure the mysql server is actually running![code]service mysql restart[/code]
This problem isn’t something I did, or fog is doing and you’re particular case has told you EXACTLY the problem was in the update. This doesn’t mean anything is actually wrong, but from what I can tell, the update stopped the mysql service but failed to restart it.
-
It look as though copying the files from trunk fixed the problem.
Can you tell me why?
-
I already did. The files in trunk are setup better to implicitly state what file and protocol to use
-
Thanks Tom.
OK, so I assume that the previous files were dynamic?
-
I’m going to say yes? It’s actually supposed to use the last protocol, but for whatever reason it seems to forget what the last protocol used was, which should always be tftp as that’s how it gets the undionly file to begin with.
-
Thanks again.
I have another question. I can’t seem successfully schedule a delayed task. The task never starts.
Should I open that in a new thread?
-
Restarting mysql did solve my issue. Sorry to have hijacked this thread, but since the other was generic stating that pxe was not working and was posted on the same date I thought it might be of relevance. All of my FOG servers are running again.
Sincerely,
Mark -
No,
Check your server timezones?
/etc/php5/apache/php.ini (date.timezone=America/New_York)
/etc/php5/cli/php.ini (date.timezone=America/New_York)
Change your America/New_York to match your particular timezone.
Then you’ll have to restart the apache server:
[code]sudo service apache2 restart[/code]
And restart the FOG Services that use the scheduler and such:
[code]sudo service FOGMulticastManager restart
sudo service FOGImageReplicator restart
sudo service FOGScheduler restart[/code] -
In /etc/php5/cli/php.ini the date.timezone field was commented out and no time zone was specified.
I’ll test it in a bit.
Does the America/New_York part have to be in quotes? It is in quotes in the other file.
-
It does not need to be in quotes, though it doesn’t hurt it either.
-
Thanks for your quick replies.
-
I just tried a manual upload. I have been busy with something else and I wasn’t monitoring the progress. I thought it would have been done some time ago and the FOG server showed 99.85% complete. I looked at the client and it was displaying FOGFTP: login failed with user “fog” and incorrect password every few seconds.
I did not recognize the password it was attempting to use.
Where do I edit that password? Could it have something to do with the files I copied from trunk?
-
It would not have anything to do with the files you downloaded from trunk.
To fix, I would recommend changing the Unix user fog with:
[code]sudo passwd fog[/code] Specify your new password and confirm it as required.Then go to Storage Management Page->List All Nodes->Your relevant node->Management Password and change this password to what you changed in the above step.
Then, go to FOG Configuration Page->FOG Settings->TFTP Server->FOG_TFTP_FTP_PASSWORD. Set the password to the same you set above, then all should be back to operational.
Hopefully this helps.
-
OK. I have changed the password in all locations and a manual upload works fine. I can create an instant task, the client restarts and the upload completes successfully.
I still cannot run a delayed upload. The client is showing the Ctl-Alt-Del screen. The client machine does not restart.
How do I best troubleshoot this.
I don’t think this is related, it pertains to WOL. If I search for wol.php I find it in two locations.
/var/www/fog/wol
/home/pmusfog/desktop/fog_1.2.0/packages/web/wolThe path in FOG Configuration->FOG Settings->General Settings->FOG_WOL_PATH = /fog/wol/wol.php.
-
Is this before or after the delayed task has started?
-
The delayed task never shows that it has started. Actually, I’m not sure what I should see in Task Management. If I look at Scheduled Tasks I see the Upload task I just created. Under Active/Type I see Yes/Delayed. The task never appears in the Active Tasks window. It is now 10 minutes after the scheduled start time.
-
my guess is the time is off then.
Have you ensured the date.timezone setting of both the /etc/php5/apache/php.ini and /etc/php5/cli/php.ini were set, and that the FOG Services were all restarted after the apache service was restarted?
