Error after PXE Boot on Dell Latitude 5491

[Sebastian Roth]

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

[george1421]

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

[greichelt]

@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!

[george1421]

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

[greichelt]

@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)?

[george1421]

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

[greichelt]

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

[Tom Elliott]

@greichelt Linux is case sensitive. Always.

[greichelt]

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

[george1421]

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

[greichelt]

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

[greichelt]

@Tom-Elliott and @george1421

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