PXE Boot stopped working



  • I need help troubleshooting why PXE boot is no longer working from client computers.

    I installed FOG version 1.2.0 a few months ago. The OS is [FONT=Arial][COLOR=#333333]Ubuntu 10.04.[/COLOR][/FONT] I was seeing the PXE boot menu on machines with network boot as first priority. I successfully uploaded a number of images.

    Something has changed since than and I no longer see the PXE boot menu when I start a client machine. I have installed all the suggested updates to Ubuntu.

    Now at the end of the PXE boot sequence I get a message “/default.ipxe…no such file or directory”. The machine proceeds to start Windows.

    On the FOG server I see that /tftpboot/default.ipxe exists.

    Also, /etc/default/tftpd-hpa contains the line TFTP_DIRECTORY = “/tftpboot”

    Can anyone offer ideas about how to diagnose the problem?



  • If a user is logged on to a client machine the only way I can schedule a FOG upload is to send a shutdown/restart command to the client machine via the Linux scheduler.



  • 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?


  • Senior Developer

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



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



  • 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]



  • Thanks for the clarification


  • Developer

    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. So the /var/www part is implied?


  • Developer

    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.



  • 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/wol

    The path in FOG Configuration->FOG Settings->General Settings->FOG_WOL_PATH = /fog/wol/wol.php.

    Tom said that it was correct though.


  • Developer

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



  • When I schedule an upload task does FOG automatically send the packet or do I have to enable that somewhere?


  • Senior Developer

    Yes, to use WakeOnLan it generates it as needed.



  • Does FOG use a Magic Packet?



  • 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>


  • Senior Developer

    Wake System from S5 <Disabled>

    Can you enable?



  • 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


  • Developer

    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.



  • 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


Log in to reply
 

400
Online

39.4k
Users

11.1k
Topics

105.5k
Posts

Looks like your connection to FOG Project was lost, please wait while we try to reconnect.