Error after PXE Boot on Dell Latitude 5491



  • I’ve just started using FOG last week and am new to Linux as well. I setup an Ubuntu 16.04 LTS server and FOG 1.5.4. The setup was pretty painless following the various forums and in a few days I had a Windows 10 1803 image built, sysprepped with an unattend.xml file and deployed successfully to 30 Dell OptiPlex 3060 workstations. I even setup the driver injection and it worked flawlessly. I decided to attempt to image 5 Dell Latitude 5491 laptops and ran into my first issue. I was able to PXE boot and get the PXE menu. I selected the image option to image the laptop and got the errors that are in the attached image. I’ve googled the various errors and found nothing relevant to FOG. I tried using various kernels (I had downgraded to 4.15.2 x64 because it was taking 15 minutes to wipe GPT/MBR) from 4.15.2 all the way up to 4.18.3; the error messages changed, but the behavior was the same. The system would not boot past the errors shown in the attached image. I’m not sure where to go from here. Any assistance would be greatly appreciated!

    0_1538597476115_20181003_160047_resized.jpg



  • @Tom-Elliott and @george1421

    That did it. All drivers have installed successfully. Have a good day, all!



  • @Tom-Elliott and @george1421

    SUCCESS!!! Thank you both so very much! Drivers are pulling now. Hopefully, I have everything else right. I’ll let you know if I have any further issues.


  • Moderator

    @greichelt said in Error after PXE Boot on Dell Latitude 5491:

    Hopefully changing Win10 to win10 does it for me.

    Oh yeah, that caught me a few times too. Always ensure that winxx directory is lower case. Dell will sometimes mix it up when it creates its cab files.



  • @Tom-Elliott

    LoL, thanks! I’m hoping that is what my issue is. I extracted the Dell .cab file and left the directory structure in place. Hopefully changing Win10 to win10 does it for me.


  • Senior Developer

    @greichelt Linux is case sensitive. Always.



  • @george1421

    I updated the code snippet as you suggested and get the same error in the screenshot below. The one thing I did notice is that the capitalization of the W in the screenshot error is different than the W in the path in the file system. Being new to Linux, I am not sure if that matters when calling a network path, so I changed the path from “/images/drivers/Latitude 5491/Win10” to “/images/drivers/Latitude 5491/win10” and am testing again.

    0_1538664625087_Drivers-not-found.jpg


  • Moderator

    @greichelt At lot depends on which scripts you are using to install the drivers. In my (internal) scripts that are not published I do a test to see if the source file path (drivers) exists. If it does exist then it copies the files over, if not I have it place guidance text in a file on the target computer. I do this for debugging new models.

    This is my code:

    # Check to ensure the reqiured driver folder exists
    if [ -d "/tmp/mydrivers" ]
    then
        dots "Copying $machine ($setarch) Drivers";
        cp -r /tmp/mydrivers/* "${targetDriverPath}";
        echo "Done";
    else
        # If the driver folder does not exist then update the machines file
        echo "\n Unable to locate drivers in the folder [/images/drivers/${machine}/${setarch}]. " >> "${targetDriverPath}/machine.txt"
    fi
    

    If you are using the code from one of my tutorials, then you might integrate it like this:

    You will need to modify this section of code

    dots "Preparing Drivers"
    clientdriverpath="/ntfs/Drivers"
    remotedriverpath="/images/drivers/$machine/$osn/$arch"
    
    debugPause
    
    if [[ ! -d "${remotedriverpath}" ]]; then
        echo "failed";
        echo " ! Driver package not found for ${machine}/$osn/$arch ! ";
        echo "\n Unable to locate drivers in the folder [/images/drivers/${machine}/$osn/$arch]. " >> "${remotedriverpath}/machine.txt"
    
        debugPause;
        return;
    fi
    echo "Ready";
    
    debugPause
    
    [[ ! -d $clientdriverpath ]] && mkdir -p "$clientdriverpath" >/dev/null 2>&1
    echo -n "In Progress"
    
    rsync -aqz "$remotedriverpath" "$clientdriverpath" >/dev/null 2>&1
    

    to look like this

    dots "Preparing Drivers"
    clientdriverpath="/ntfs/Drivers"
    remotedriverpath="/images/drivers/$machine/$osn/$arch"
    
    debugPause
    [[ ! -d $clientdriverpath ]] && mkdir -p "$clientdriverpath" >/dev/null 2>&1
    
    debugPause
    if [[ ! -d "${remotedriverpath}" ]]; then
        echo "failed";
        echo " ! Driver package not found for ${machine}/$osn/$arch ! ";
        debugPause;
        return;
    fi
    echo "Ready";
    
    debugPause
    
    echo -n "In Progress"
    
    rsync -aqz "$remotedriverpath" "$clientdriverpath" >/dev/null 2>&1
    

    Understand that I have not tested this code for bugs only scrambled things in my head.



  • @george1421

    Thank you this will save me some time today. In my previous post I had mentioned that my driver injection was working flawlessly. I hadn’t realized it at the time, but I had followed your post to get the driver injection working on my OptiPlex 3060 (https://forums.fogproject.org/topic/11126/using-fog-postinstall-scripts-for-windows-driver-injection-2017-ed). I just finished imaging my Latitude 5491 and found that no drivers were installed despite adding them to the /images/drivers folder. The path I have is /images/drivers/Latitude 5491. I left the space in because I didn’t quite understand what this part of your post meant, “note that the space has been removed for “Optiplex 7040” to this Optiplex7040. There is a clean up line above that removes spaces in the product name.” Does the clean up line mean I should leave the space in the path (/images/drivers/Latitude 5491) or remove it (/images/drivers/Latitude5491)?

    0_1538661029435_Drivers-not-found.jpg


  • Moderator

    @greichelt said in Error after PXE Boot on Dell Latitude 5491:

    , I will upgrade to Kernel 4.18.11 x64, use the acpi=off arg and see if the GPT/MBR issue is resolved for me.

    I just setup a test bench with a OpltPlex 7040 and the latest FOG kernels and development inits and the problem is still there. I’m going to look into the disk wipe issue a bit later today.



  • @Sebastian-Roth and @george1421

    Thank you both for your replies. Sebastian, I tried the variable acpi=off using Kernel 4.15.2 x64 and it worked flawlessly. I did get an error that the HDD was not found, but a change in the BIOS from RAID to AHCI resolved the issue; after the next PXE boot, imaging kicked right off.

    George1421, if I get time today, I will upgrade to Kernel 4.18.11 x64, use the acpi=off arg and see if the GPT/MBR issue is resolved for me.

    This post can be marked as resolved!


  • Moderator

    @greichelt said in Error after PXE Boot on Dell Latitude 5491:

    I had downgraded to 4.15.2 x64 because it was taking 15 minutes to wipe GPT/MBR)

    We are looking into this issue next. While its not related to your ACPI errors this is a problem. The latest linux kernels may address this issue, but I can’t be sure. A firmware update on the target computer may also address this error.

    Test what Sebastian said by placing the kernel parameters to disable acpi into the host definition for this target computer. FWIW ACPI is not needed for imaging since FOG doesn’t use it at all.


  • Developer

    @greichelt Try turning off ACPI as described here: https://forums.fogproject.org/topic/11002/problem-acpi-error (Note there are two different kernel parameters mentioned, see which one is helping)


 

496
Online

41.9k
Users

12.4k
Topics

116.7k
Posts