Driver Issues With Dell Latitude 7280 - No Bootable Devices

george1421

@george1421 Well the first test was a complete failure. It appears that the hard drive is not detected by FOS.

Some details for background information.
The systems were delivered on 19-Sept-2017
They should be still the skylake design so they are windows 7 compatible.
The firmware release is 1.5.8
Actions taken: I unboxed the unit, went into the bios and switched to uefi mode, disabled secure boot, enabled uefi network stack. Then pxe booted and attempted to do a quick deploy and was abruptly stopped just after FOS started with hard drive not found.

This was done on my production server that’s running FOG 1.4.4

On to manually registering this device and to boot into debug mode. Wait… I have FOS on a usb flash drive, even easier…

george1421

@george1421 Ugh…

Sata mode == RAID On

Booting again in sata == ahci mode.

george1421

@robtitian16 Well, I have some bad news for you. Once I fixed my head-space issues the system imaged fine.

Now you said that your system imaged just fine, no errors right? But now the hard drive doesn’t show up as a bootable option in the firmware.

My intuition is asking me… Did you deploy a uefi captured image to a uefi target computer? We’ll assume for the moment that FOG imaged the computer correctly. If by chance you pushed a bios based image to the target computer then the uefi firmware won’t see the uefi/gpt boot sectors on the disk. That would cause the conditions you are seeing.

The less likely thing is that when I build our reference images, we preload the Dell WinPE images into the reference images. We do this to ensure the target computer has at least the required drivers to boot the device. We do inject the drivers into the image using a post install script, but in this case I haven’t loaded the 7280 drives yet in fog. So this system booted using the win10 native drivers + the WinPE built in drivers.

RobTitian16

@george1421 Thanks for running those tests, George - interesting conclusions. I found that I was able to boot into the system when I changed into Legacy mode, so perhaps something went wrong when uploading the image in the first place. I’m currently applying the Creator’s update to the image on a VM, after which I shall sysprep and upload it once more to FOG. I should be able to test the deployment again later today.

george1421

@robtitian16 FWIW, the Win10 image I deployed was CBB 1703-EFI. Since it booted in legacy mode, the problem is in your reference image. If you are using vmware as your virtualization technology and creating a vm to install your reference image on, you need to flip the switch and make that a uefi virtual machine before you build your reference image.

In my (our) case we have 2 images of CBB 1703. One is for bios and one is for uefi mode. They are needed to be able to deploy to our fleet of mixed mode computers. Its a bit of a pain keeping which mode is which but its needed until we can get all switched over to uefi mode.

RobTitian16

@george1421 Ah, thanks. I’m building it in hyper-v, so I don’t think there is anything like that I need to change, though I could be wrong (it did work before without any changes to systems running in UEFI mode).

george1421

@robtitian16 I don’t know hyper-v, but I remember something about a type 2 or class 2 vm being uefi? But that is the key, you can only deploy to uefi systems from a uefi reference image and the same for a bios to bios.

Good luck on your rebuild.

I use MDT to build our reference images, so all I needed to do is switch the vm between modes, rebuild and capture.

RobTitian16

@george1421 Thanks very much!
So I’ve just tried this today and I’ve found that something has gone weird with my Unattend.xml file. I suspect it’s something to do with the Windows 10 Creator’s Update, and I need to update some of my settings, but after running sysprep and rebooting the VM, I get the following error message:

“Windows could not parse or process the unattend answer file for pass [specialize]”.
Has anyone else run into this? I can post my Unattend.xml file if that helps.

george1421

@robtitian16 You might want to at least post your specialize section of your unattend.xml. But I can say I’m basically still using my Win7 unattend.xml file even with 1703. I have made a few tweaks here an there, but its basically the same.

I can also give you some hints when having problems.

Place your unattend.xml file in c:\windows\panther directory and call it out from there.
Make sure you don’t have 2 unattend.xml files.
Make sure you are using the proper activation key, or don’t provide an activation key at all in your unattend.xml file.
If you have an error with oobe you can usually find out what happened why OOBE stopped. Schedule a debug capture or deploy and reboot the target computer right after the error screen. Boot into fog debug console. Then key in these commands.

mkdir /mnt
mkdir /mnt/win
mount /dev/sda2 /mnt/win
cd /mnt/win

That will place you in the root of the drive. Now depending on where you unattend.xml file is you can search /Windows/Panther or /Windows/Setup/Sysprep There are error logs in there. I found the answers to why I was having a problem running sysprep and then imaging that way. It took me about 4 attempts to get the unattend.xml file right when I started with a generic unattend.xml file from http://windowsafg.no-ip.org/

RobTitian16

@george1421 Thanks, George.
The Specialize section is as follows:

    <settings pass="specialize">
        <component name="Microsoft-Windows-Security-SPP-UX" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
            <SkipAutoActivation>true</SkipAutoActivation>
        </component>
        <component name="Microsoft-Windows-SQMApi" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
            <CEIPEnabled>0</CEIPEnabled>
        </component>
        <component name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
            <WindowsFeatures>
                <ShowMediaCenter>false</ShowMediaCenter>
                <ShowWindowsMail>false</ShowWindowsMail>
            </WindowsFeatures>
            <ShowWindowsLive>false</ShowWindowsLive>
            <DoNotCleanTaskBar>true</DoNotCleanTaskBar>
            <BluetoothTaskbarIconEnabled>true</BluetoothTaskbarIconEnabled>
            <ComputerName>RENAME </ComputerName>
            <CopyProfile>true</CopyProfile>
        </component>

I can’t see anything immediately obvious… unless there’s an issue with the copy profile being set to true.

george1421

@robtitian16 I don’t see anything either. I think you are going to have to go the debug route and see what the winsetup application is having a problem with.

RobTitian16

@george1421 It turned out there was a space in my Unattend.xml file where I was setting the computer name to: RENAME.
I’ll have to create a generation 2 Hyper-V VM to see if I can get it to upload to UEFI.

RobTitian16

@george1421 It all uploaded perfectly fine the other day - thanks

Driver Issues With Dell Latitude 7280 - No Bootable Devices

220

11.7k

17.2k

154.7k