Problem with the resize (expanding) on a hard drive

[Sebastian Roth]

@loutrage Interesting, the second partition doesn’t have any flags set. This is how it should be and shouldn’t cause it to be seen as non-resizable.

Do you keep an eye on the screen when the image is captured. Possibly the resize test fails with Not resizing filesystem /dev/sda2 (part too small)???

As a dirty quick fix you can edit d1.fixed_size_partitions and make it look like this:

1

Then try deploying again.

I do remember that I made I change to the inits after 1.5.7 was release that is related to detecting which partitions can/cannot be resized. Though I didn’t think this would help in your situation. But still you can update to the latest inits and see if that helps. Login to your FOG server as root and run the following commands:

cd /var/www/html/fog/service/ipxe
mv -i init.xz init.xz.orig
wget https://fogproject.org/inits/init.xz
mv -i init_32.xz init_32.xz.orig
wget https://fogproject.org/inits/init_32.xz
chown www-data:www-data init*

The last command fails if you are on CentOS. Use chown apache:apache init* instead…

[loutrage]

@Sebastian-Roth

I replaced the files init.xz & init_32.xz with the last version then I made a new capture but I had always the same problem.

Then I tried the “dirty fix” by editing the file d1.fixed_size_partitions but I receive this error :

Maybe because the file d1.fixed_size_partitions changed with my new image ?

The content of the file is now :

1:2

I also tried to see a message like this Not resizing filesystem /dev/sda2 (part too small) but it was too fast.

I just saw this

[Sebastian Roth]

@loutrage said in Problem with the resize (expanding) on a hard drive:

I also tried to see a message like this Not resizing filesystem /dev/sda2 (part too small) but it was too fast.

The messages we see in the picture all seem fine up to that point. It detects sda1 as fixed because it has the boot flag set. Probably wait a little bit longer to see what it says when it tries to shrink sda2.

It if’s all going to fast you can just schedule a debug capture task. Just as you would create a normal task bit just before you click the last button there is a checkbox for debug. Boot up the machine and hit ENTER twice to get to a shell. Key in fog as command and fire it up with ENTER. Now you step through the whole process with plenty of time to read and take pictures.

[loutrage]

@Sebastian-Roth
Here is 2 screens about SDA2. Everything seems good I think.

[Quazz]

@loutrage Looks the resize test fails, which automatically marks the partition as fixed size.

Possibly the filesystem or disk is damaged causing the failure.

Try and fix the filesystem by running chkdsk C: /f on the windows client you want to capture. (you’ll then need to confirm to schedule on reboot and then ofc reboot)

[Sebastian Roth]

@loutrage See it says Not shrinking (/dev/sda2) trying fixed size in the pictures. So there is an issue with trying to shrink that filesystem. I’d suggest you do another debug capture task and step all the way to the point where you see that message. Now press Ctrl+c to stop the script and get back to the shell. Now run cat /tmp/tmpoutput.txt to see all the messages the last command (ntfsresize) produced. Take a picture and post here.

[loutrage]

@Quazz
@Sebastian-Roth

Thank you, you found the solution !

Here is the result of the tmpoutput.txt file

Indeed, the problem came from a problem with the filesystem of my “mother” image. After several chkdsk (I had reboot only once the first time), the expand works well.

Thank you guys ! The problem is so solve now.

[x23piracy]

Hi,

i currently have this Problem with (Windows 10 2004) i created a new image thats not expanding after deployment. I am on an older FOG Version 1.5.0 and older Images (1703) expand correctly.

Any idea?

Best Regards X23

[Quazz]

@x23piracy The newest W10 versions seem to create a partition after the Windows partition. This will be what’s blocking it.

There are some ideas on how to resolve such things in the future, but currently you have to manually move the partition before capture.

[x23piracy]

Hi Quazz,

thanks for your quick response after that deployment i could see the recovery partition is behind the system partition, if move this in front of the system partition and capture after that it works?

Btw. i found out howto still use copyprofile with newer Win10 Versions if someone is interested.

I was looking for my post and wondering with the post number has been extended but my post wasnt visible, forum changes to current post on top hehe

Best Regards X23

[Quazz]

@x23piracy Yes, that should work. Hopefully we have a better solution by 1.6.0

[x23piracy]

Hi,

i am currently trying to move partitions but it won’t let me:
https://i.imgur.com/9pKvxqY.png

The marked part is “move partition” it’s greyed out.

Regards X23

[Quazz]

@x23piracy Not sure what program you are using, but perhaps you need to shrink you windows partition first, move it to the right (into the unallocated space), then move the recovery partition in front of it, reallign and expand again.

[x23piracy]

Hi,

i thought the same but i can’t move the recovery partition in front of the system partition even if i shrink the beginning of the system partition…meh:

https://i.imgur.com/ZRjg6Tm.png

Best Regards X23

[Quazz]

@x23piracy It’s safe to delete if you don’t need that partition.

Alternatively, you could manually create the partitions in windows setup I suppose.

[x23piracy]

Hi,

i am not sure if it can simply deleted, It’s used in recovery cases and there are 12,5MB of data in it. I need to find out if Windows 10 is using it for what ever case.

Best Regards X23