PXE Boot stopped working
-
I’m assuming you’re using updatedb and locate as your ‘finders’?
The one in /home/pmusfog/desktop/fog_1.2.0/ is just the extracted folder info. The correct one is the location in /var/www/fog/ as that’s your web directory.
The /fog/wol/wol.php is correct path unless you changed it somewhere else.
My guess is either S4 didn’t allow wakeup, or wol isn’t enabled on that system. I don’t know all the potential values or changes in your environment either. Maybe that system is on another subnet or vlan which the fog server wouldn’t be able to send the traffic to.
-
As far as I know I did not change the path to /fog/wol/wol.php anywhere.
All workstations are on a single subnet with no vlans in place.
I’ll have to do some more testing with the WOL bit. That is the last thing I need to make the scheduled uploads work.
-
I’m not sure which WOL options to choose to work with FOG.
For example, the Intel 82578DC NICs have there options:
Wake on Magic Packet
Wake on Magic Packet from Off State
Wake on Link
Wake on Pattern Match -
So your saying in your OS your NIC options are those. BUT What are your options in the BIOS. This is where WOL should first be enabled.
-
The BIOS options are:
System Power Options
After Power Failure <Stay Off>
Wake on LAN from S5 <Power On>
ACPI Suspend State <S3 State>
S3 State Indicator <Blink>
S1 State Indicator <On>
Wake System from S5 <Disabled>
PCIe ASPM Support <Disabled>Boot Device Priority
Network is first in list -
Wake System from S5 <Disabled>
Can you enable?
-
I believe this option is to wake at a user specified time.
I think the important option is Wake on LAN from S5 <Power On>
-
Does FOG use a Magic Packet?
-
Yes, to use WakeOnLan it generates it as needed.
-
When I schedule an upload task does FOG automatically send the packet or do I have to enable that somewhere?
-
[quote=“geoffpeters, post: 41155, member: 25329”]When I schedule an upload task does FOG automatically send the packet or do I have to enable that somewhere?[/quote]
I believe it just sends the packet, there is no need to edit a config, or enable a setting.
You can change the Interface, the Host, and the Path in the Fog Settings though.
-
OK.
The only thing I saw that looked different was this:
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.
Tom said that it was correct though.
-
Yes that is correct the other is in the folder on your desktop where you decompressed the tar.gz so you could install FOG.
The path on your desktop is not necessary, it is only installation material.
Your WOL path should be /fog/wol/wol.php On your FOG Settings page under the General Settings.
-
Thanks. So the /var/www part is implied?
-
Yes because when it (apache) serves the entire FOG web GUI system, it does so from your web path which is /var/www
So the entire path to WOL is /var/www/fog/wol/wol.php
The web path is /fog/wol/wol.php
-
Thanks for the clarification
-
I scheduled a few upload tasks overnight. They did not run.
When I look at the fogscheduler.log I see that the last entry was yesterday morning. I did not stop the services.
[COLOR=#008080]Edit: I did check and none of the FOG services was running.[/COLOR]
How do I troubleshoot this?
Also, does the Windows client have to be at the login screen for the task to run? What if a user is logged in or the machine is locked ?
[COLOR=#008080]Edit: I found that the Auto Log Out module was disabled. I’ll test again tonight. Does the global setting override the setting on the client? The clients were installed with Auto Log Out selected.[/COLOR]
-
I still don’t know why the FOG services stopped…
I did find that the Intel driver installed on the clients did not actually support WOL even though there were check boxes to enable it.
I haven’t fully sorted out the Auto Log Out.
-
ALO (Auto Log Out) doesn’t work on the clients, or at least not properly. It works by forcibly restarting the machines as soon as their “time limits” are met. The problem is the time limits the provided factor. It doesn’t care if a user’s been logged in and active for the last 5 minutes. If the “time is up” the system will reboot. I would recommend, for now, not using this feature until the new client comes out.
The FOG Services have issues. I’ve tried with all of my might to fix them but it’s obviously all been in vein. We saw this with Fedora 20+, CentOS/RH/SL 7+, Debian 7.7+, Ubuntu 12+, etc…
It still hasn’t been corrected. Sure it could be something simple that I’m missing, but as most of the problematic systems are specifically related to systemd over sysvinit (of which has never had any problems that I’m aware of), it seems the best course of action is to disable the services from boot parameters and subject them into /etc/rc.local and/or /etc/rc.d/rc.local.
One of the things I can actually program to happen, somewhat, but it would also make the grand assumption that you haven’t modified the related file (which is why I haven’t done this already).
-
Thanks for the information. What “time limits” are you referring to?
The Intel NIC driver bug had me stumped for a bit.
I am very close to having this all work the way I envision.
If only I could get all users to log out at the end of the day.
SO, is there a way to restart a client if a user is logged on from FOG?
