Sysprep - Winload.efi is Corrupt or Missing
-
Server
- FOG Version: 1.3.5-RC-9
- OS: Ubuntu 14.04
Description
Hi all,
I uploaded a sysprepped image to the FOG server on Tuesday and have just tried deploying it to a laptop this morning. However, I’ve run into an issue where I receive a recovery screen, saying:“The application or operating system couldn’t be loaded because a required file is missing or contains errors.
File: \windows\system32\winload.efi
Error code: 0xc0000225
You’ll need to use the recovery tools on your installation media. If you don’t have any installation media (like a disc or USB device), contact your system administrator or PC manufacturer.”I’ve checked the forum posts here and ensured secure boot was disabled before uploading the image. There is no secure boot option on the laptop I’m deploying to (a Dell Latitude E6410). The laptop I used to upload the image completed sysprep without any issues, so it seems to be a FOG/deployment to different hardware issue.
Has anyone else come across this before? Any help would be greatly appreciated as I need to get this image working for our production systems.
-
The image you captured, was that from a uefi based system?
I was questioning if the 6410 supported uefi, but it does (I just checked). That was one of the first systems to support uefi, but not pxe booting AFAIK.
BTW: What client OS are you deploying? It sounds like FOG is working correctly, it (the windows boot loader) can’t find either the
drive, or the winload.efi boot file. -
@george1421 Yep, the image was also from a UEFI-based system (a Dell E7270).
Oddly enough I just tested deploying this same image to a computer (a Dell OptiPlex 390) and that claims it has no hard drive (it can’t see it at all whilst in UEFI mode). So, with that in mind, could it be something I’m not doing correctly when building the image?
The steps I take are:
Set the system to upload the image to boot from the network and disable secure boot.
Build the image from the ground up with necessary software, etc.
Copy the unattend file (I can post this if necessary) to C:\Windows\Panther and, using an elevated command prompt, type: sysprep.exe /oobe /unattend:C:\Windows\Panther\Unattend.xml /shutdown
I then schedule the upload through the FOG gui, watch with popcorn until it finishes, and then watch sysprep work its magic on the system I used to upload the image. (Note: this works absolutely fine.)The 6410 does indeed support UEFI as well as pxe booting (I have it checked in the BIOS). The only thing it doesn’t support is secure boot - there’s no option for it at all in the BIOS. The client OS is Windows 10 Professional 64-bit.
-
@RobTitian16 As a suggestion, on the e6410, change the hard disk mode from raid-on to achi. This is just a guess, but I might think that your image doesn’t have the proper drivers for the 6410 in uefi mode.
-
@george1421 The laptop now displays “no bootable devices” - the same message as the Dell OptiPlex 390 now.
Your guess is probably correct - I had forgot to set-up the drivers on the FOG server (doh!). I suppose I simply follow your instructions here? https://forums.fogproject.org/topic/7391/deploying-a-single-golden-image-to-different-hardware-with-fog/2 -
@RobTitian16 Yes that is the idea.
BUT, I would start with a golden image created on a VM, that way you won’t have intrinsic drivers already in the image. In our case we always load the Dell WinPE driver cab into the reference image via MDT. This gives the WinPE environment the base drivers it needs for the OOBE startup.
-
@george1421 Great stuff - thanks once again, George. I’ll give this a go this afternoon/tomorrow and test it out.
Unfortunately I can’t use a VM to create the image. For some reason whenever I do it’s not uploaded as a UEFI system and I run into countless errors with Bitlocker when the image is deployed. The only way I’ve been able to get around it is to use a physical system. I haven’t really had time to find out why this is the case, unfortunately. -
@RobTitian16 Bitlocker???
Hint, don’t turn it on until after the image is on the target system. Save your self some pain. The VM doesn’t have a TPM chip probably.
Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG!
-
@george1421 Sorry, I meant when deploying the image and trying to turn it on. For some reason when using a Hyper-V VM to upload an image to the FOG server, it will not be pushed out as a UEFI image (and thus Bitlocker cannot be enabled).
-
@george1421 Hi George,
Just a quick one: my company is using different builds depending on what their job title is (i.e. software developer, tester, IT Support, etc.) and each of these builds has a completely different configuration with software, changes to the registry, etc. Is it possible to simply capture these builds as they are with the necessary software already installed (using a method like dism), add those wim files into MDT along with the Dell cab files and create the image for FOG that way?
It seems your method in the link can only be used for golden images and you install/configure the software afterwards through scripts, etc. Unfortunately for us we can’t do that as there’s a lot of fiddling about with things like Visual Studio (and installing custom scripts, etc.).
-
@RobTitian16 Your golden image can be as setup as you need. My recommendation would be for you to use MDT to build your golden image with all of the windows updates applied, install your applications that can be installed before deployment and exclude applications that cannot be prepackaged because they build an install unique guid (like managed antivirus applications). Then sysprep the image capture then deploy with FOG.
If I did this on my campus I would check into the options for unattended install then setup MDT to install these images automatically during reference image build. If you can get the remaining tweaks done by scripting you can integrate those scripts into the MDT build too. I know it takes time to setup the first time, but then after that you can churn out new reference images by just starting the MDT task sequence.
On our campus we have 2 base images. One is a windows thin image which is windows, .net, vc++ libraries and the fog client. Then we have a fat image that includes the thin image content plus all of our standard office applications (office, java, av, flash, acroreader, etc). We use the lite touch method to create both images every quarter.
Now there is another philosophy you can use. Deploy a thin image and then use either snapins or some other deployment tool (like PDQ Deploy) to push out your standard applications.
Any route you take the key will be to see if you can install the applications using a silent or unattended install command line and then identify the tweaks you need to do to the application and script those during the install. This is all for the reference image build or post imaging deployment.
And one last thing, in your unattended.xml file, if you have the copyto key set any changes made to the administrator account on the reference image will be copied to the default user account when sysprep is run. That way any tweaks make to the administrator account will be reflected in the new profile when users first login.
-
@george1421 Thanks, George.
I’m a little confused with the installation of the applications and MDT. Is this done within MDT itself? What if I’ve already built it on the Dell laptop? How would I then get the image across to MDT to apply the driver cab file and the registry change you mention in the guide?
Were there any guides/resources you used to get acquainted with MDT? -
@RobTitian16 You can’t shake a stick at the internet without finding a guide on how to setup MDT. Google is your friend here.
https://www.404techsupport.com/2016/01/setup-mdt2013u2/
The idea/concept is to setup your golden image on a vm using mdt to build it. Configure that image, then capture and deploy with FOG.
-
@george1421 Hi George,
I’m just taking a look at this now (I became swamped with other things, unfortunately and thus the FOG server was forgotten for a while).
I just have a few questions about your instructions in: https://forums.fogproject.org/topic/7391/deploying-a-single-golden-image-to-different-hardware-with-fog/5?loggedinSpecifically, you say at the end of part 1 that you have a batch file that runs sysprep with the required parameters. Is this set-up as a task in MDT before you capture the reference image using MDT itself? Or, is it separate from everything we’ve done in MDT so far, and is done just to capture the image with FOG?
Also, in part 2 you say to set-up the Windows directory like so:
/images/drivers/{hardware_type}/{os_type}/{arch}/{driver files}However, the CAB file just comes with WinPE x86 and WinPE x64 folders (with network and storage folders containing the drivers in each, respectively). Do we simply create folders like the below, and copy the drivers from the WinPE x64 and WinPE x86 folders into each one?
C:\Drivers\LatitudeE6410\win10\x64\{all driver files from dell cab}If so, couldn’t we just use a single folder for the drivers instead? The CAB file doesn’t seem to specify what systems it can be applied to.
-
Q1 Batch file: This is an independent batch file from MDT. We do a few clean up actions just before sysprep and power off. We do this via a batch file and at the end of the batch file it runs the sysprep command with a consistent syntax. That way we get the same exact action every time we build a master image and then sysprep it. It could be done manually by copy and paste, but its much easier to run the batch file. We do have the sysprepit.cmd file as well as some branding stuff installed as a MDT package. That is how it gets copied over to the reference image as a MDT package.
Q2 CAB file: Understand there are 2 different cab files in play here. We install the winpe cab file in the reference image since that contains the core drivers we need post deployment. The driver path /images/drivers/{hardware_type}/{os_type}/{arch}/{driver files} is the extract of the model specific cab file. If you give me a specific dell model I can point you to the proper cab file.
