Wrong Image Size indicated in the image manager.

[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?

[processor]

@Sebastian-Roth
Hi Sebastien,

I’m using FOG 1.5.5 with init files included with it.
As suggested in a previous post (https://forums.fogproject.org/post/123192), I backed up init files stored in /var/www/html/fog/service/ipxe/ and put instead the last ini files.

I had the behavior described : shrinking OK but FTP error then. I put back the 1.5.5 ini files and then everything worked back. It’s may be just a coincidence I can try again.

[Sebastian Roth]

@processor Did you get to test if it’s definitely the changed inits causing/fixing the FTP error?

[processor]

@Sebastian-Roth

Hi Sebastien, I just did the test again and put the new ini files create the FTP error and put back the original 1.5.5 ini file correct it.

So you confirm the 1.5.6 include the fix? then I should just upgrade from 1.5.5 to 1.5.6, no?

Proc

[Sebastian Roth]

@processor said:

Hi Sebastien, I just did the test again and put the new ini files create the FTP error and put back the original 1.5.5 ini file correct it.

So are you saying that using the 1.5.6 inits is causing the FTP issue but using the 1.5.5 inits you don’t get the FTP error but the UUID issue?!??!

Well we changed the FTP username from fog to fogproject from 1.5.5 to 1.5.6 but that is not hardcoded in the inits and shouldn’t cause this issue I think. You might still try updating to 1.5.6 to see if that fixes the problem.