Fog resize Hard drive (C partition) after compression...

[Matthieu Jacquart]

Hi ,

Sorry for my english but I’m french and I encounter a strange problem, difficult to explain…
I use Fog for years on numerous computers and everything is ok, except for notebook Toshiba Satellite pro C660 with SSD 60Gb (running Windows 7 pro SP1, just one partition of 60Gb)

If I don’t compress SSD (C partition), everything is ok. But it began to be full (thanks MS for update and winsxs folder…) so I decided to compress it. Until I made a sysprep and upload the image, everyhting is fine, I can reboot the computer without any problem.
But when I sysprep the computer and update the image, after completion C partition is reduced from 60Gb to 27Gb and is totally full ! I tried several way to resize the disk (windows disk management, gparted…) but nothing work.

I don’t know if it’ a sysprep or fog problem (v1.2.0), but I’ve got another kind of computer with same SSD 60Gb, and for them I can compress SSD and upload image, everything is fine… But not on my satellite pro C660 !

Thanks for help, because the only solution I have is to revert to my previous image without compressing hard drive…

Matthieu

[Wayne Workman]

What version of FOG are you using? What revision?

[A Former User]

Nice to see I’m not the only one with the issue personnaly with partimage on Fog 1.20

Resize2fs resize the source machine’s drive, but never expand it again corrupting both the source and the image (= you can restore the image on a 200GB drive but it shows your C:\ with 20GB only)

It seems it happens on computer you didn’t run chkdsk /F before starting fog but I can’t confirm

I have a computer to fix tomorrow morning so I’ll write the process to “repair” the damaged machine here once I’ve tested my procedure.

[Tom Elliott]

The “repair” is actually much simpler I think.

It doesn’t use resize2fs for ntfs, it uses ntfsresize (hopefully a bit more helpful).

partimage images from 0.32 (maybe earlier as well?) assume a start sector of 63s, while most systems actually have a start sector at 2048s. It’s this difference that you’re seeing a problem. Basically, even though Win 7 may start initially with loading the sector at 2048 during it’s install process, FOG copies all data after sector 63s. Because of this the MBR is adjusted to start at 63s which doesn’t exist in a pure 2048 setup.

FOG 1.2.0 “forgot” about this and always aligns disks at optimal values which most will automatically adjust to 2048s. Because of this, the MBR can’t locate the now adjusted 63 vs 2048. I know this seems like gibberish but should give insight.

I’ve actually fixed this in the development version so I’d say start there if you could.

[Matthieu Jacquart]

Hi

I need to update my post, because issue happens again on another model.
I prepare my image on dell computer with SSD 120Gb, I compress C partition, I upload image, everything seems to be fine.

But few days after, I try to download image on 2 different model, and each lost all free sapcee : Fog just keep 25Gb on C for system…

I don’t find any solution except don’t compress c partition, but my SSD 60Gb are quickly full if I don’t compress…

Thanks for your help !
Matthieu

[ch3i]

@Matthieu-Jacquart Hi, are you using SVN version ?

[Matthieu Jacquart]

No, I use 1.2 to create and deploy image.

[ch3i]

@Matthieu-Jacquart That bug is fixed in SVN.

@Tom-Elliott said:

The “repair” is actually much simpler I think.
[…]
I’ve actually fixed this in the development version so I’d say start there if you could.

[Matthieu Jacquart]

Oh, my fault, read to fast…
I’ll try this today, thanks