Driver Issues With Dell Latitude 7280 - No Bootable Devices



  • Hey all,

    Is anyone having issues imaging Dell Latitude 7280 laptops?
    I downloaded the CAB drivers from: http://en.community.dell.com/techcenter/enterprise-client/w/wiki/2065.dell-command-deploy-driver-packs-for-enterprise-client-os-deployment
    Neither the 7280 nor the Win10PE drivers seem to work at all. I know my process for injecting the drivers works as we resolved that in another thread, and I have been using it since with other systems. (It’s a post-download script that copies the contents of the appropriate driver folder to the C: drive).
    Any help with this would be appreciated :)



  • @george1421 Still no joy, even after updating again and running through the steps previously linked. I’ll try and boot from the CD and go from there.



  • @george1421 Yep, that’s what I thought but wanted to check I wasn’t going insane.
    I’ll take a snapshot of my FOG server and try the above mentioned fix in the article you linked.


  • Moderator

    @RobTitian16 said in Driver Issues With Dell Latitude 7280 - No Bootable Devices:

    Or am I chasing a red herring and the hard drive shouldn’t appear in the UEFI one-time boot menu?

    It should show in the boot menu when/if a valid uefi boot partition is created. The uefi firmware looks at the disk and will only display a uefi boot option if it finds uefi boot media. To test this put a windows OEM dvd in the dvd drive and boot into the boot options menu. It should show the dvd rom.


  • Moderator



  • @george1421 Thanks, George. I’m just reviewing this now, and I’ve created a test image with all of the drivers (Dell 7280 and Win10PE) installed. I haven’t sysprepped it either (though I don’t expect that to make much of a difference).
    After the system has been imaged, it still says there are no boot devices. Interestingly, when I press F12 to go into the one-time boot menu, the hard drive isn’t even listed! I just have IPV4, IPV6 and the DVD USB drive with the Windows 10 disc (in preparation for your aforementioned steps).
    It’s using UEFI mode to boot and I can see the drive is enabled in the BIOS (though it also doesn’t appear when choosing the boot sequence). I’ve set the SATA Operation to AHCI mode (it was on RAID on before). Is there anything else I could check? Or am I chasing a red herring and the hard drive shouldn’t appear in the UEFI one-time boot menu?


  • Moderator

    @RobTitian16 OK we are focusing on the original issue.

    well, lets assume the drives are loaded and the image was laid down to the best of FOGs ability. The question in my mind now, can the target computer be fixed (or made right for debugging purposes)?

    What I would do is boot off the windows 10 cd and try to get into recovery mode with a command prompt.

    I would check:

    1. can I see the hard drive and its contents?
    2. Do the contents look said?
    3. Can I rebuild the mbr/boot sector?
    4. Can I rebuild the boot.ini or what ever win10 uses with fixboot command?

    Can you get it to boot. That will tell is a bit more. Right now without having one in my hands I can’t really dig into did FOG do something wrong, or we just don’t have the right drives installed (i.e you need to have the WinPE 10 drivers injected too into the golden image). The no boot device error is given on the very startup of win10 where winpe could be in command of the system.



  • @george1421 Sorry, clearly I wasn’t with it this morning.

    So, for the 7280, even after injecting the drivers into the golden image, it still isn’t working. I still receive ‘no bootable devices found’, and I am also using the updated Windows 10 Unattend.xml file. Do you know of any standard Dell drivers I can try? At this point I’m only interested in getting the hard drive recognised post-download.


  • Moderator

    @RobTitian16 said in Driver Issues With Dell Latitude 7280 - No Bootable Devices:

    I’ll now have to inject the drivers into the reference image from now on (thereby having multiple images for different types of systems)?

    What am I missing here?? As I see it…

    Win7 == update registry location to search for drivers in c:\drivers (or where ever) and use sysprep
    Win10 == Create entry in unattend.xml in golden image to search in c:\drivers or use postinstall script to copy in updated unattend.xml and use sysprep

    Its just a different method to achieve the same goal no change in overall process.



  • @george1421 No, I meant the driver store, as in C:\Windows\System32\DriverStore\FileRepository, but after looking at it, I can see that’s where the .inf files are after they’ve been installed.
    So, moving forward with this, I’ll now have to inject the drivers into the reference image from now on (thereby having multiple images for different types of systems)?


  • Moderator

    @RobTitian16 said in Driver Issues With Dell Latitude 7280 - No Bootable Devices:

    heoretically, couldn’t I edit the script to put the drivers in the driver store?

    That’s precisely what were were doing with Win7. From your code:

    # Add the driver location on the PC to devicepath in Registry: 
    regfile="/ntfs/Windows/System32/config/SOFTWARE"
    key="\Microsoft\Windows\CurrentVersion\DevicePath"
    devpath="%SystemRoot%\inf;%SystemRoot%\DRV";
    reged -e "$regfile" &>/dev/null <<EOFREG
    ed $key
    

    That path is the same one that is referenced in the document you linked. But that doesn’t work with Win10 (at least in my experience).

    But Tom is right with the disk detection. Remember you have 2 issues here and not to get them confused.


  • Senior Developer

    @RobTitian16 That only works if Windows detects the disk in the first place.



  • @george1421 Me too! I’m not sure how… maybe they were using some kind of driver picked up as I was building the image in Hyper-V, though I haven’t seen anything of the such in the golden image.
    Theoretically, couldn’t I edit the script to put the drivers in the driver store? According to the below link, that’s where Windows 8 and later first searches for drivers and installs them onto the device.
    https://docs.microsoft.com/en-us/windows-hardware/drivers/install/where-setup-searches-for-drivers


  • Moderator

    @george1421 ref: https://forums.fogproject.org/topic/8889/fog-post-install-script-for-win-driver-injection/4

    For WIN10 you must update the unattend.xml file to include this section. This is an example for the amd64 arch.

        <settings pass="offlineServicing">
            <component name="Microsoft-Windows-PnpCustomizationsNonWinPE" 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">
                <DriverPaths>
                    <PathAndCredentials wcm:action="add" wcm:keyValue="1">
                        <Path>C:\Windows\DRV</Path>
                    </PathAndCredentials>
                </DriverPaths>
            </component>
        </settings>
    

  • Moderator

    @RobTitian16 said in Driver Issues With Dell Latitude 7280 - No Bootable Devices:

    I just need to edit the unattend.xml to point to C:\Windows\DRV for the drivers, instead of relying on the registry change?

    Correct. I’m a bit surprised that your other win10 images actually worked??

    Either way that’s not your issue with the 7280. For the 7280 you need to inject the driver into the reference (golden) image before capture.



  • @george1421 said in Driver Issues With Dell Latitude 7280 - No Bootable Devices:

    And just for clarity your post install script is for win7 not win10. Win10 will only look for drivers defined in the unattend.xml. It does not reference the registry entry that is being set in your post install script. It doesn’t hurt to set it, the registry key just won’t be used.

    Bah, when did that happen? I could never get the unattend.xml driver injection to work for whatever reason. I guess I’ll go back to including the drivers in the reference image and test it out.

    Edit: I must have misread your comment. I just need to edit the unattend.xml to point to C:\Windows\DRV for the drivers, instead of relying on the registry change?


  • Moderator

    I haven’t touched a 7280 just yet (will order my lot in July). But two things come to mind.

    1. These are the first kaby lake models. The first since Win10 was released. Win10 may not have the necessary drivers for the disk controller ‘on-board’.
    2. You may need to inject the driver into your reference image instead of into your target image. (we had to do something similar with nvme disks were introduced with Win7).

    The disk is a boot time device. So I look at it this way, if no disk at boot time, the system will not boot to load any drivers off the C: drive.

    And just for clarity your post install script is for win7 not win10. Win10 will only look for drivers defined in the unattend.xml. It does not reference the registry entry that is being set in your post install script. It doesn’t hurt to set it, the registry key just won’t be used.



  • @Tom-Elliott I haven’t had any issues with Windows 10 so far on the different systems (also Latitude E6 something or other - there are a few of them). This is the post-download script I mentioned previously:

    # Script here to mount the drive...
    
    ceol=`tput el`;
    machine=`dmidecode -s system-product-name`; #Gets machine model
    machine="${machine%"${machine##*[![:space:]]}"}" #Removes trailing space
    system64="/ntfs/Windows/SysWOW64/regedit.exe"; #Determine if it's 64 bit or not
    
    dots "Creating driver folder on local system" # < This is fine on a new line. 
    
    # Check if the DRV folder exists on the local PC. If not, create it:
    	if [ ! -d "ntfs/Windows/DRV" ]
    	then 
    		mkdir /ntfs/Windows/DRV &>/dev/null;
    		echo -n "Done"
    	fi
      
    
    # Check if the drivers exist on the FOG server. 
    # If not, copy them across to the local PC (they must be extracted first on the FOG server):
    
    
    dots "Checking for Drivers on FOG Server" # < This bunches with the previous dots command. 
    
    	if [ -d "/images/Drivers/${machine}" ]
    	then
    		echo -n "Drivers found"
    		dots "Copying Drivers to local system" # < This also bunches with the previous dots command. 
    		cp -r  "/images/Drivers/${machine}/." "/ntfs/Windows/DRV"
    				
    	else
    		echo -n "No drivers were found"
    		# Give the reader a chance to see what the error was. 
    		sleep 10; 
    		# Terminate the post driver script. 
    		exit 1;
    	fi   
    
    # Add the driver location on the PC to devicepath in Registry: 
    regfile="/ntfs/Windows/System32/config/SOFTWARE"
    key="\Microsoft\Windows\CurrentVersion\DevicePath"
    devpath="%SystemRoot%\inf;%SystemRoot%\DRV";
    reged -e "$regfile" &>/dev/null <<EOFREG
    ed $key
    $devpath
    q
    y
    EOFREG
    # Remove the "In Progress" and replace it with: "Done"
    echo -e "\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b${ceol}Done";
    esac ```

  • Senior Developer

    @RobTitian16 Then possibly Windows 10 is told to look at this or that driver store differently from windows 7?



  • @Tom-Elliott I’m not sure - I haven’t mounted the drive and checked in during a debugging phase. The script does say that the files have been successfully transferred however, and this does always work. If they aren’t transferred then the script fails.


Log in to reply
 

501
Online

38924
Users

10691
Topics

101425
Posts

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