win 10 deployment / disk size auto-adjusting / recovery mode

[Baessens]

Hi everyone

New FOG user here…

Scenario:

I have a Hyper-v environment. I made two VM’s to deploy to our workstations.
They are both 64 bit windows 10 Pro’s, Generation 1.
installed language: Dutch.

I did not do any sysprepping.

I imaged them both to my FOG server (Version 1.5.4)

One uses a Multiple Partition Image - Single Disk (Not Resizable), which deploys just fine. Only problem i have is that it does not adjust the partition of the drive automatically. So i would have to manually expand it…

On the second image i chose Single Disk - Resizable thinking this would auto adjust the partition. But when i try to deploy this one of our pc’s, it just boots into recovery mode…Giving me error 0x0000225.

Now, i’m not sure if this is a windows problem or something in FOG.

(edit ->)
tried this after suggestion from comments:

wget https://fogproject.org/kernels/bzImage -O /var/www/html/fog/service/ipxe/bzImage
wget https://fogproject.org/kernels/bzImage32 -O /var/www/html/fog/service/ipxe/bzImage32
wget https://fogproject.org/inits/init.xz -O /var/www/html/fog/service/ipxe/init.xz
wget https://fogproject.org/inits/init_32.xz -O /var/www/html/fog/service/ipxe/init_32.xz

This did help increase the speed of deployment, but the device still booted to the recovery screen…

Any help would be appreciated.

[Quazz]

What language do you install Windows 10 in?

Any OEM specific partitions?

[Baessens]

@Quazz Thank you for the quick reply. The language installed is Dutch.
I tried deploying to two different devices both from HP. There is an Recovery OEM partition.

[Quazz]

@Baessens Please run the following commands to update the kernels and inits to the latest version which should provide better results for Dutch installations

wget https://fogproject.org/kernels/bzImage -O /var/www/html/fog/service/ipxe/bzImage
wget https://fogproject.org/kernels/bzImage32 -O /var/www/html/fog/service/ipxe/bzImage32
wget https://fogproject.org/inits/init.xz -O /var/www/html/fog/service/ipxe/init.xz
wget https://fogproject.org/inits/init_32.xz -O /var/www/html/fog/service/ipxe/init_32.xz

You will have to recapture the image after this so the information is correctly captured for deployment.

[Baessens]

@Quazz I ran the commands; The deploy seemed succesfull, but the device still rebooted to the error recovery screen…

[Quazz]

@Baessens Did you capture the image anew prior to deployment?

[Baessens]

@Quazz Yes i recaptured the image. It does deploy quite a bit faster now. The part where it erases MBT/GPT tables goes a lot faster now. Thanks for that. But for some reason the device still reboots onto the error recovery screen with the same error.

[Sebastian Roth]

@Baessens Please post the contents of d1.fixed_size_partitions, d1.partitions and d1.minimum.partitions (all those you find as text files in the image directory - /images/<IMAGENAME>/). I am fairly sure we’ll find some kind of special partition layout causing us trouble here.

As well please boot windows on the original machine and take a picture of disk managment and post here.

[Baessens]

@Sebastian-Roth Thanks for the reply.
d1.fixed_size_partitions:
This is an empty file.

d1.partitions:

d1.minimum.partitions:

Disk management of the machine i captured;

[Sebastian Roth]

@Baessens Ok, Quazz was definitely on the right track with this. Your partition layout does not seem to be the issue but the Dutch labels are. As of now we still use thise partition labels to discover special Windows partitions like Boot or Recovery partition. In your case our scripts fail.

Although I wonder about this causing real trouble because the starting point of the partitions are untouched. Nevermind, we’ll try the fix anyway.

@Quazz Would you find the time to add Door systeem gereserveerd (hope there is no typo!) to the scripts? Not sure from the top of my head but I think there were at least two places. I can push changes and auto-build new init’s then.

[Quazz]

@Sebastian-Roth Well, the strange thing, to me, is that the current regex should match the label. It’s the default Dutch label for that partition and it works fine on my images with that exact same label!!!

Very mysterious…

Door systeem ge**reserve**erd

Part between ** should match and in my tests (as well as image captures) it does, so I’m kind of surprised it’s not working for Baessens

Relevant commit: https://github.com/FOGProject/fos/commit/e6431418022911bef122394c57726f4a879421cf

All this being said. I don’t recall this ever breaking my windows installs prior to the fix. I’m going to assume there is something else going on.

@Baessens do you use an unattend.xml file? driver installs/packs? (nothing to do with the resize issue, but might have something to do with the recovery issue)

[Baessens]

@Quazz
I do not use any unattend.xml file.
All I do is install from a win 10 pro 64 bit iso, on my hyper-v which is Windows server 2016.

Version: Windows 10 Professional, version 1803 (june 2018) - Dutch

I manually go through the installation process, install office and some other small things (with Ninite); and capture the machine with FOG.
I do add a legacy network card to be able to boot from network on hyperv. and i use generation 1 as my VM type.

If i do not chose for the resizable disk, it deploys just fine.

Thanks for all of the help already!

[Quazz]

@Baessens @Sebastian-Roth Some googling indicates 0x0000225 has to do with the BCD.

Given that the start positions of the partitions seem to be correct, I don’t think the resize process is directly responsible for the error.

Is it possible you’re deploying an MBR (legacy/old BIOS) (assuming, based on your partitions) to a system that’s trying to boot in GPT (new/UEFI) mode?

Does d1.mbr exist in your image folder?

[Sebastian Roth]

@Quazz You are right, it should match. Seems strange as fixed_size_partition is empty and sda1 is definitily been shrunk… But you are right, it shouldn’t cause the recovery boot. Maybe this is some Win10 fast boot foo?!

@Baessens Make sure you disable fast boot and shutdown the machine using shutdown -s -t 0 -f in Windows command line.

[Baessens]

@Sebastian-Roth @Quazz

Make sure you disable fast boot and shutdown the machine using shutdown -s -t 0 -f in Windows command line.
I used the shutdown command. I’ll try disabling fast boot and reimaging.

Is it possible you’re deploying an MBR (legacy/old BIOS) (assuming, based on your partitions) to a system that’s trying to boot in GPT (new/UEFI) mode?
It’s possible the VM i made uses MBR. But i’ve enabled Legacy boot on the BIOS and disabled secure boot. Also with the other image(not resizable) i made i have no problems deploying.

Does d1.mbr exist in your image folder?
Yes, it does.

The thing i don’t understand is how i don’t have any problems deploying the other image i made. Which is Not Resizable. I’m deploying on the exact same machine.

I do have the option legacy boot enabled in the BIOS, and secure boot disabled. I’ve tried using uefi boot but that doesn’t work at all.

Maybe i have to add some kind of option or parameter in the host options on the FOG UI?

[Baessens]

@Sebastian-Roth @Quazz

I captured a new image of one of the physical machines (not VM). This is a resizable image.
I CAN deploy this image to the other machines without the recovery screen error…

This machine has been setup by one of my colleagues using windows media creation tool.
It’s also a Win 10 pro 64 bit.
The Disk management looks a little different tho; (name of OEM partition)

Seems like something must be wrong with the VM i set up ?

Thanks

[Sebastian Roth]

@Baessens From the pictures it looks like the hardware client is installed as UEFI (EFI boot partition and probably GPT partition layout) while the VM as legacy BIOS. Usually FOG is able to handle both and I am still at a loss with this.

Please do me a favour, deploy that image you took from the VM to a machine. Now don’t let it boot to Windows but shut it down and schedule another task for it again. But this time tick the checkbox for debug. Boot the machine and it should bring you to a shell. Run the following command, take a picture and post here: sfdisk -d /dev/sda

[Sebastian Roth]

@Baessens Ahhh, I just had one more idea. Please run fdisk -l /dev/sda and post a picture as well. Possibly this is a sector size issue.