Wrong Image Size indicated in the image manager.

[processor]

OK, you are certainly both right. But this not help. As I did not made the bases I don’t know what happened.
Now :

• is there any way for this image to be compliant with FOG? (any way to recreate the system partition without breaking everything)

• list item there any way make FOG not detect them as reserved?

• list item Or the only option is to rebuild the source images?

By the way many thanks for the interest you put in this subject

[george1421]

@processor said in Wrong Image Size indicated in the image manager.:

list item there any way make FOG not detect them as reserved?

Lets start by removing this one from the list. The word “reserved” is a special word. If you look at the drive with windows running in the computer management applet. Does that partition say “Reserved”. If it label say OS or something else then we can remove the “reserved” line from your issue. Then its down to FOG treating the first partition as unsizable.

is there any way for this image to be compliant with FOG?

Its just not the matter of making it compliant with FOG, it’s not Microsoft best practices compliant. We probably can make fog do what we want, but you will have issues in the future with Microsoft upgrades. So the question is do you make it right now or latter. It really isn’t a fog question.

@Developers if its the first partition thing, can we just mark the image as resizable in the image config files?

[Junkhacker]

@george1421 said in Wrong Image Size indicated in the image manager.:

@Developers if its the first partition thing, can we just mark the image as resizable in the image config files?

yeah, that should work.

[processor]

Great, how to do it? Is it something that I can do or is it something that can only be done by the devs?

[george1421]

@processor Its something you can do, but I don’t remember the exact file to change. Its a simple change, but if you make the wrong one its not good. That is why I sent a note to the devs.

[processor]

@george1421 ok looking forward the info.

[Junkhacker]

ok, in the directory for that image, there should be a file named “d1.fixed_size_partitions”. the contents of that file would be “:1” telling it that partition one should not be resized. delete that line.

[Sebastian Roth]

@george1421 We skip some of the checks for single partition setups. See here for example: https://github.com/FOGProject/fos/blob/master/Buildroot/board/FOG/FOS/rootfs_overlay/bin/fog.upload#L108

@processor Beside what I posted about the mentioned d1.fixed_size_partitions will still be created on upload/capture and seems like we don’t skip the tests for single partition setups on deploy. Therefore it won’t do the resizing on deploy for you. Quick fix as suggested by @Junkhacker, delete that file from your /images/… directory and it should expand.

Many thanks for George who kept asking the right questions to nail this down. I’ll see if it makes sense to add the check skipping for single partition setups on deployment as well.

[processor]

@Sebastian-Roth

Hi, unfortunatelly, it did not worked, still saying a 500GB hd is too small whereas there is only 80GB of data. I try to remove :1 or to delete d1.fixed_size_partitions and result is the same. May be there is some info info stored in d1.mbr or img that can’t be changed.

When I get the error message regarding the size, there is an info inside telling that I can use -C parameter to avoid size checkin. I guess this is a partclone message. Do you know if it’s possible to apply this parameter?

[edit]

In debug mode I ran

partclone.ntfs -r -C -s /images/testimage/d1p1.img -o /dev/sda1

and it keeps telling me I have not enough space

[Sebastian Roth]

@processor said in Wrong Image Size indicated in the image manager.:

still saying a 500GB hd is too small whereas there is only 80GB of data

Maybe I have missed that in the earlier discussion. Has it always been this exact error?? Can you please post a picture of that error on screen??

[processor]

@Sebastian-Roth Here it is :
!

[Sebastian Roth]

@processor Please post the contents of the text files d1.partitions and d1.minimum.partitions from that image.

[processor]

@Sebastian-Roth

d1.minimum.partitions :

label: dos
label-id: 0xd1ff252a
device: /dev/sda
unit: sectors

/dev/sda1 : start=        2048, size=  1875380224, type=7, bootable

d1.partitions :

label: dos
label-id: 0xd1ff252a
device: /dev/sda
unit: sectors

/dev/sda1 : start=        2048, size=  1875380224, type=7, bootable

[Sebastian Roth]

@processor Can you please schedule another upload/capture task but tick the checkbox for debug. Boot up the client and when you get to the shell run blkid -po udev /dev/sda1 and take a picture of the output.

Then run command fog to start the upload and step through the whole process. Please take pictures of the screen. What I am most interested in is the output of the lines where it says ... Partition count of ...

[processor]

@Sebastian-Roth

Hi this is what you asked for :

Then the capture process start.

[Sebastian Roth]

@processor Please download the latest init files (32 bit and 64 bit) and put those in /var/www/html/fog/service/ipxe/ (rename the originals for the time being).

[processor]

@Sebastian-Roth
It’s resizing with this init files.
is it related with what I just saw in the 1.5.6 change log :
"Change detection of fixed partitions from labels to partition flags. "

I wait the end of the dump and will deploy, to check that everything is OK.

Proc.

[processor]

@Sebastian-Roth

So the resizing worked, but I had a major issue at the end of the dump :

This prevent the task to end.

I’ll put back the right ini file and check that’s not a local issue.

[processor]

@Sebastian-Roth

I can confirm that the fogftp error is related to the ini file uploaded as putting back the old file solved this problem.

[Sebastian Roth]

@processor Which version of the init file are we talking about here? Sure the new one is from 1.5.6 but what version is the older one from that you tested?

From the error message we see in the picture I still can’t imagine that a change of the init file (this being the only change) can cause this error. That ftp code is running on the FOG server and only invoked by the client through URL calls. Those URL calls have not changed in a long time as far as I know.

Are you absolutely sure that simply changing the init file (/var/www/html/fog/service/ipxe/init.xz) from a new version to an older one (which version?) triggers fixes this error? How did you move to the older init version? Simply by copying the file or re-running an older installer?