Any updates on the non-resizable Windows recovery partition issue?

[DBCountMan]

Wondering if there is a way for FOG to detect a Windows recovery partition and have it not try to resize it so that the deployment process can continue.

[Sebastian Roth]

@brakcounty When did you check into this topic last? Which version of FOG do you use? Do you have a system where it doesn’t work as you expect and can you share some more details in this issue?

[DBCountMan]

@sebastian-roth The last thing I remember reading was that modifying the partition file was a fix. I also remember being told that Microsoft made their recovery partitions non-resizable. I’m on 1.5.9 and unless we image a drive that is the same size as the source drive, the process will fail saying one of the partitions could not fit or was too big. I remember in earlier versions of fog that we could always create an image from a 500gb drive and deploy it to a 250gb drive, even with the windows recovery partitions. Acronis can do the same thing. But now we can’t.

[Sebastian Roth]

@brakcounty said in Any updates on the non-resizable Windows recovery partition issue?:

The last thing I remember reading was that modifying the partition file was a fix.

That was before we worked on fixing this.

I also remember being told that Microsoft made their recovery partitions non-resizable.

Not sure who told you this. Defintiely not correct. The problem is Microsoft moved the recovery partitions to the end of the disk which renders the partiton layout as a whole non-resizable if you still use the old FOS inits that come with FOG 1.5.9. Though there is one very important detail: The newer FOS inits will only be able to handle and shrink this newer partition layout if it’s a GPT layout. If you still use MBR partition layout (default for legacy BIOS installs) then we are not able to help you.

I’m on 1.5.9 and unless we image a drive that is the same size as the source drive, the process will fail saying one of the partitions could not fit or was too big.

Download the latest inits from github and put those into /var/www/html/fog/service/ipxe/ on your FOG server. Rename the original files just to make sure you can switch back if needed. Then schedule a new capture of a system with a larger disk, pay attention to the early part of the FOS bootup where you see the FOG ASCII art screen and the Init Version: 20210807 information (make sure it’s the correct number!) and then deploy this same image to a system with smaller size disk.

[DBCountMan]

@sebastian-roth Ah ok thanks for clarifying. So I should only download from github what I already have instead of all of the inits right? Also I don’t know why those two bzimage files are in the group “fogproject” instead of www-data, but other than the resizing issue, my FOG server works fine.

[Sebastian Roth]

@brakcounty said in Any updates on the non-resizable Windows recovery partition issue?:

So I should only download from github what I already have instead of all of the inits right?

You only need init.xz and init_32.xz! Download those two files from github, rename the original ones on your FOG server and put the new ones into place.

Also I don’t know why those two bzimage files are in the group “fogproject” instead of www-data.

That happens when you update the kernel through the web UI. It’s not an issue. Still works just fine.

[Jomaryngs]

I read everything written here and thought about this: If earlier such manipulations were possible, is there a chance that Windows still did not provide for something. Is it possible to hack the system and change the memory size for updating? How is this even possible? I used to contact raid data recovery to recover the data I lost during the system update process and thought that even if they can retear the data, is it impossible to change the amount of memory used by this data?