Driver Issues With Dell Latitude 7280 - No Bootable Devices

RobTitian16

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

george1421

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

RobTitian16

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

george1421

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

can I see the hard drive and its contents?
Do the contents look said?
Can I rebuild the mbr/boot sector?
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.

RobTitian16

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

george1421

@Sebastian-Roth Do you feel Rob’s issue is related to this one? ref: https://forums.fogproject.org/topic/10236/w7-image-disk-read-error-after-imaging/30

george1421

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

RobTitian16

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

RobTitian16

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

RobTitian16

@george1421 Sorry to resurrect this thread - unfortunately, this is still an issue.
To update everyone, I’m currently running: Ubuntu 14.04 server hosting FOG.
The FOG version is 1.5.0-RC-8.
The SVN Revision is: 6080.

There seems to be something wrong on the BIOS level after applying the image: it no longer detects the UEFI hard drive. It detects it perfectly fine before the image in UEFI mode, but then I only see two options: “Onboard NIC (IPV4)”, and “Onboard NIC (IPV6)”. If I plug in the Windows 10 USB that came with the laptop, I see a third also: “UEFI: Dell Recovery USB 1100, Parititon1”.
So, what can I check/test or run to prevent this from happening in the future? Why does the hard drive disappear after applying the image? Are there any logs I can get to help determine the cause of this issue.
As always, any help with this would be greatly appreciated.

george1421

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

o, what can I check/test or run to prevent this from happening in the future? Why does the hard drive disappear after applying the image? Are there any logs I can get to help determine the cause of this issue.

The hard drive will disappear if UEFI detects there is no bootable partition on the drive. You will get the same response if you insert a usb drive or cdrom that is only formatted as a bios (DOS) boot disk.

I did just happen to get in some 7280s earlier this week that are just itching to spring to life. Let me crank one up and deploy an image to it.

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/

Driver Issues With Dell Latitude 7280 - No Bootable Devices

213

11.7k

17.2k

154.7k