FOG resizes all partitions even System Reserved!

[Quazz]

@Sebastian-Roth https://github.com/FOGProject/fos/pull/22

[Sebastian Roth]

Merged the changes, should be building new inits now. @maxcarpone Will let you know as soon as they are available for download.

[maxcarpone]

@Sebastian-Roth Ok, I’ll be happy to try those new inits

[Sebastian Roth]

@maxcarpone Unfortunately our build server seems to play up. Has not started building yet and I am not sure why…

[Sebastian Roth]

@maxcarpone Sorry for the long deply again. Build server is fixed now and here you got the fresh new inits - on your FOG server run:

sudo -i
cd /var/www/html/fog/service/ipxe
mkdir initbackup
mv init.xz init_32.xz initbackup/
wget -O init.xz https://fogproject.org/inits/init.xz
wget -O init_32.xz https://fogproject.org/inits/init_32.xz

Now recapture the image and see if it’s any better.

[maxcarpone]

Hey guys!

It looks like it works so far. I tested with 2 fresh installations of W10 1803, one in MBR and the other one in UEFI and each capture has its own d1.fixed_size_partitions populated.

Content of these files :

• MBR => :1
  which is the partition labeled : Réservé au système

• UEFI => :2:3:1
  Which are Recover, System, MSR

I will do more experiments soon but I like what I saw ^^

Thanks for the good work

[imt_fog]

@Sebastian-Roth does it make sense to test these init files also with 1.5.5 stable? If yes, I’d be willing to test as I ran into the “resizing” issue just a few days ago having “System-Reserviert” as partition label on some of our Win10 Edu German master images. It took me days to find out that the boot loop indeed was not an IDE/AHCI ang buggy BIOS issue, which we had before on some point as well…

[Sebastian Roth]

@imt_fog Yeah, definitely give those a try. The ones you have in place with a 1.5.5 install are still using the label based detection which can cause issues on Windows installs with language other than English.

[imt_fog]

@Sebastian-Roth I am using the new inits, and right now, it seems there is no resizing at all.

If I redeploy an image of a MBR based system, it has exactly the same size as on the captured one. On the other hand, there is no “fixed partition” message on the screen, but also no resizing message.

Content of d1.fixed_size_partitions

:1:2

Content of d1.original.fstypes

/dev/sda2 ntfs

I’ll switch back to the original inits, but if there is anything I could provide to help debugging, please let me know! Or could there also be an issue because of our local naming policy naming “System”, thus being confused with the UEFI “System” partition of GPT based systems? I didn’t check the sources yet

[Sebastian Roth]

@imt_fog With the new inits we don’t check the labels anymore. But if you messed with the flags that could be an issue.

Did you capture and deploy using the new inits??

[imt_fog]

@Sebastian-Roth yep, both with the new ones.

I’ll do a debug run next week and check the messages, and I will check the flags as done in https://github.com/FOGProject/fos/blob/master/Buildroot/board/FOG/FOS/rootfs_overlay/bin/fog.upload#L109 - I did not “play” with the flags manually, but I will compare to a brand new Win10 MBR installation if the flags got mixed up.

Other question: could I just change the d1.fixed_size_partitions to

:1

as long as my source file system was “small enough”? I actually prepare the images on a virtual machine having the VHD slightly smaller than the smallest target system SSDs we have in use.

Normally, I prepare in the VM, deploy once to each target platforms, check the drivers and then capture each platform. Right now, we have 4 different models in our department (~30 to ~90 per model)

[Sebastian Roth]

@imt_fog said in FOG resizes all partitions even System Reserved!:

Other question: could I just change the d1.fixed_size_partitions to

:1

Yes! Then on deploy it would expand the second partition for you.

I can actually imagine the second partition to be marked as bootable and therefore being recognized as non-resizable

[Quazz]

@imt_fog If you boot the machine in question in debug mode, you should be able to run parted -l manually and check the flags.

I don’t think this is caused by such, however, but interested in seeing the results.

Worth noting that partitions that go through the checks but fail to resize get marked as fixed size as well (to prevent issues during deploy)