Windows 10 resizable image system partition issue

[grungeman]

Server

• FOG Version: 1.4.2
• OS: Ubuntu 16.04

Client

• Service Version: 1703
• OS: Windows 10 Pro

Description

At first almost every Windows 10 image captured failed when deploying them back to another computer with another disk. The cloning itself was succesfully completed but windows would always stop at startup with an error message. However changing the fd1.fixed_size_patitions from :3 to 1:3 we can now succesfully deploy windows 10 on diffrent sized hard drives.
So far so good, but now i noticed that the system partition seems a bit corrupt, the partition size say 1000MB as it should , but it also say 30mb in use 1mb free.
See attached picture.
I tried change the d1:minimum_partitions as well but still same.
The computer seem to run ok but it doesn’t feel right to leave it like that. Anyone got any ideas how to fix this?

/Peter
All shared files should be here now
https://drive.google.com/open?id=0B4jg25N5LsOTUUViOUNwdGVReXM

[Sebastian Roth]

@grungeman said in Windows 10 resizable image system partition issue:

the partition size say 1000MB as it should , but it also say 30mb in use 1mb free.

I don’t see this in the picture! Could you please explain again using the exact numbers.

[Quazz]

I’m not sure, but it’s possible this is due to the Bitlocker encryption. IIRC it stores information in the system partition.

[grungeman]

Sorry for the swedish in the screenshot. The new link below should include Source_PC Disk management screenshot, the way it should look and the destintation_PC disk management screenshot after the deployment.
I also included some of the partition config files, not sure if its usefull.
New hopfully working link

https://drive.google.com/drive/folders/0B4jg25N5LsOTUUViOUNwdGVReXM

[Quazz]

@grungeman Can you assign a letter to the system partition and then run a chkdsk on it?

Interesting to see if it will pick up any errors!

I couldn’t open the zip file, by the way.

[grungeman]

@Quazz
Added two chkdsk screens, one from Source PC before capture and one from destination PC after deployment. No errors as far as I can see.
https://drive.google.com/open?id=0B4jg25N5LsOTUUViOUNwdGVReXM

[Quazz]

@grungeman Thank you, something certainly changed as you can see there’s a difference in counts there.

Not sure, but it could potentially be something similarish to what happened https://forums.fogproject.org/topic/10236/w7-image-disk-read-error-after-imaging here.

[Sebastian Roth]

@grungeman This really looks a little odd. In the destination_PC picture we see System partition 30MB capacity in the list but the graphical view at the bottom says “1000MB NTFS”. In first sight to me this looks as if the partition is 1000MB but the NTFS filesystem in that System partition was not properly resized to fit that partition.

As you said that you changed d1.fixed_size_partitions my guess would be that this messed things up a bit.

You want to have your first partition being recognized as fixed when uploading the image. FOG does recognize partitions labeled as ...Recovery... or ...Reserved... as fixed ones. Usually Windows names it System Reserved. So if you change the label to that it should be properly recognized as fixed. Does the problem go away if you do that on your master and recapture the image before deploying it again?

[grungeman]

Well with a lot of testing the last few days, changing the d1.fixed_size_partitions to 1:3 is the only way to create a resizable working image of a none syspreped Windows 10. But again if there is no solution for the usable space on the system partition I think it is not usable.
Our goal is to be able to create a clone of working windows 10 without the need of using sysprep before its captured. Seems to work better with non resizable images, but that has its own issues. Like the need or resize partition post installation.

One question a side from the main subject, is it normal that i create a new fog image choosing Partimage, but when the capture is done and i view the image it now say Partclone Gzip?

[Quazz]

@grungeman Based on what Sebastian said, it sounds like partition is being resized when it shouldn’t because its label is not the one it should be. This occurs on capture, hence why you need to make alterations to the label and then recapture.

One question a side from the main subject, is it normal that i create a new fog image choosing Partimage, but when the capture is done and i view the image it now say Partclone Gzip?

Yes, PartImage is no longer used for capture, it defaults to Partclone Gzip. It is there for legacy purposes (to deploy old partimage images)

[grungeman]

@Sebastian-Roth Thanks , this looks very promissing, just tested it on one computer and it looks just right. Fog now recongnized the system partition as a fixed partition and set the The d1.fixed_size_partition :1:3 .
I will need to do some more testing to evaluate this, but looks good atm. This could in other words just be a OS language “bug” , I think swedish windows 10 version by default name the “System Reserved” partition just “System” Which would make fog miss the fixed partition and cause me all the trouble.

It is however very doable to manuallt rename a partition prior capturing it.

thanks for the good advices, I hope this turn out to be great.

[grungeman]

@Sebastian-Roth Would it be possible for me to change which labels FOG looks for when setting fixed partitions?

[Sebastian Roth]

@grungeman said:

Would it be possible for me to change which labels FOG looks for when setting fixed partitions?

Sure you can modify the initrd files to do just this. But be aware that you have to do this every time you get some new initrds like when upgrading.

sudo -i
cd /var/www/fog/service/ipxe/
mkdir loop
# backup the original files
cp init.xz init.xz.orig
cp init_32.xz init_32.xz.orig
# extract and loop mount the initrd
xz -d init.xz
mount -o loop init loop/
# then edit the fog.upload and funcs.sh scripts using your favorite editor 
vim loop/bin/fog.upload
...
vim loop/usr/share/fog/lib/funcs.sh
...
umount loop/
# compress initrd
xz -C crc32 -9 init
# DONE for 64 bit, now comes the 32 bit initrd
xz -d init_32.xz
mount -o loop init_32 loop/
...
# follow the steps above

The change you want to make are most likely on line 107 in fog.upload and line 455 in funcs.sh - this is the current dev-branch which is being altered every now and then. Exchange [Rr][Ee][Ss][Ee][Rr][Vv][Ee][Dd] (case insensitive) for [Ss][Yy][Ss][Tt][Ee][Mm] in your case I reckon.

[george1421]

@Sebastian-Roth FWIW: If that text exchange can be turned into a sed command in a bash script, its possible to have FOS patch itself each time FOS boots by using a postinit script. Then there would be no need to unpack, patch, and repack the inits each time there is a FOG upgrade.

EDIT: I’m not a sed expert so there may be a cleaner way to do this than escaping every bracket, but in testing it does work to exchange the text mentioned.

sed -i -e "s#\\[Rr\\]\\[Ee\\]\\[Ss\\]\\[Ee\\]\\[Rr\\]\\[Vv\\]\\[Ee\\]\\[Dd\\]#\\[Ss\\]\\[Yy\\]\\[Ss\\]\\[Tt\\]\\[Ee\\]\\[Mm\\]#gi" /bin/fog.upload

sed -i -e "s#\\[Rr\\]\\[Ee\\]\\[Ss\\]\\[Ee\\]\\[Rr\\]\\[Vv\\]\\[Ee\\]\\[Dd\\]#\\[Ss\\]\\[Yy\\]\\[Ss\\]\\[Tt\\]\\[Ee\\]\\[Mm\\]#gi" /usr/share/fog/lib/funcs.sh

EDIT2: It appears the forum eats the escape characters. Here are the commands in a text file.
[0_1498038914037_sysreserv.txt.bin](Uploading 100%)

EDIT3: WTF I can’t upload a frick’n text file either?
So for manual edits to the sed command, you need to add a back slash (i.e. windows path separator) character in front of each square bracket in the sed command.

EDIT4: Use double backslash…

[george1421]

Update to thread: These sed scripts can/could be called from a fog postinit script to ‘patch’ the fog scripts on each FOS boot. This way you would never need to unpack the inits and would fully support updated scripts in the future.

I did write a tutorial on the postinit scripts here: https://forums.fogproject.org/topic/9463/fog-postinit-scripts-before-the-magic-begins