Core partition suddenly stopped resizing across all images (Windows 10)
-
We’ve been using FOG 1.5.9 for over a year, we image multiple machines with Windows 10 every day.
Unfortunately, all our images just stopped resizing the core partition.
I’ve checked every image d1.partition/minimum.partitions/fixed_size_partitions and everything is correct (fixed size is 1:2:4, 3 is the core partition, 4 is Windows Recovery which also blocks the main Windows partition from being expanded manually), but these shouldn’t be the issue anyway since the partitions were extending before and now, suddenly, they are not.
We are using a custom kernel and a modified init.xz (just added a few custom scripts, some extra tools and suspend to RAM functionality). I’ve also tried an old init.xz but we get the same issue. The last change I made was to include procps-ng (from buildroot) in the latest init.xz since busybox ps is super limited, I’m concerned that this might have caused the issue but it still didn’t work with the old init.xz so I’m really not sure!
I’m going to keep hammering away at this but any advice would be greatly appreciated.
-
@c4c This is a change that M$ did with 20H2 and later versions of windows. They made that recovery non-movable.
You have 2 options.
- Simply delete that recovery partition from your golden image and recapture with FOG. Then image resizing will work in FOG 1.5.9. One might question the value of a recovery partition when you have an imaging soltuion that can rebuild the system completely in less time than it takes windows to go fix itself.
- Switch your fog install over to the dev-branch to get the fix for the issue that was resolved in FOG 1.5.9.110 and later releases. Normally this would be the preferred approach, but it appears you have customized the initrd file, which the updated version is needed of init.xz to resolve the non-movable recovery partition thus replacing your customizations.
Understand Microsoft is the root cause here not fog.
-
@george1421 Since we are currently building our own init with buildroot (thanks to your advice in https://forums.fogproject.org/topic/16145/unfreeze-drive-from-fog-init-image/8?_=1650556627677), with the latest from https://github.com/FOGProject/fos would that not include the fix? Or is it something server-side that is missing?
-
@c4c Yes if you did copy over the
FOS/board/FOG/FOS/rootfs_overlay/binfile in buildroot. Specifically it looks like the script fog.upload was the item updated 14 months ago to fix the non-movable bits. ref: https://github.com/FOGProject/fos/tree/master/Buildroot/board/FOG/FOS/rootfs_overlay/bin I don’t think there was any server side changes around this update.(Note: for others, unless you built the initrd using buildroot what I just posted is not understandable)
Now looking at this through a different set of understanding:
Unfortunately, all our images just stopped resizing the core partition.
I’ve checked every image d1.partition/minimum.partitions/fixed_size_partitions and everything is correct (fixed size is 1:2:4, 3 is the core partition, 4 is Windows Recovery which also blocks the main Windows partition from being expanded manually), but these shouldn’t be the issue anyway since the partitions were extending before and now, suddenly, they are not.
Did this change happen because of your custom initrd file? Is there anything that might have changed to cause this externally?
-
@george1421 said in Core partition suddenly stopped resizing across all images (Windows 10):
Specifically it looks like the script fog.upload was the item updated 14 months ago to fix the non-movable bits. ref: https://github.com/FOGProject/fos/tree/master/Buildroot/board/FOG/FOS/rootfs_overlay/bin I don’t think there was any server side changes around this update.
I can confirm what George states about having the fix included if you build using the latest (master branch in this case).
-
@george1421 So this gets weirder and weirder.
I just completely deleted our entire buildroot setup and all the fos information, everything. Re-downloaded everything and started again from absolute scratch. Completely fresh, FOG-standard FOS init and it still doesn’t work. BUT, I also found an old init we were using a couple of months ago and that works absolutely fine.
Now, the interesting thing here is that I did a “make clean” before the last init was compiled and it was then that the issue manifested.
This suggests to me that one of the packages that is downloaded during a clean make process has been updated or changed in the last month in such a way as to break things. If this is the case surely I can just manually download a safe version of whatever it is and put it in the buildroot/dl/ directory but first I need to work out what is broken.
Any ideas?
-
@c4c Beside the guide George provided to conpile the FOS init I can suggest you try the
build.shscript we provide within the FOS repo.As well I ask you to pay close attention to the error messages. Make sure it’s always the exact same error or possibly a slightly different one. Just want to prevent you from going mad searching for a change in the inits.
-
@sebastian-roth
Thanks for this, using the build.sh produced a working init. Part of me still wants to understand what broke but there really isn’t any point if this is working fine. -
@c4c The only thing I can think is that the version of the fog.download script from github is somehow older than what the build.sh program has access to. If you still have the manually setup buildroot image can you run a md5sum command on that version vs the fog.download in the structure created by build.sh?
I’m kind of suspecting that the github fos code is still pointing at FOG 1.5.9 where the build.sh might be pulling from a different location. But in the end you have it working and that is what is important.
-
@c4c @george1421 I can assure you that there should be nothing special that build.sh is pulling or doing. While we have different branches like master (latest official) and dev-branch (development) in the fogproject repo this is not the case in the fos repo. I always use fos master to build stuff. If I do really fance new things I create short temporary branches but merge those into master again as soon as things are ready to go.
One thing I just noticed in George’s desciption is using
make -j4to build. The official manual states that “Buildroot does not support top-level parallel build” (reference). Though I can’t really think of this causing the problem described.If you work more on this you should also read this part of the manual: https://buildroot.org/downloads/manual/manual.html#full-rebuild - e.g.:
When a package is removed from the configuration, Buildroot does not do anything special. It does not remove the files installed by this package from the target root filesystem or from the toolchain sysroot. A full rebuild is needed to get rid of this package.
