Driver Issues With Dell Latitude 7280 - No Bootable Devices
-
@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.
-
@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.
-
@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).
-
@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.
-
@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. -
@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/ -
@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.
-
@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.
-
@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. -
@george1421 It all uploaded perfectly fine the other day - thanks