Wrong Image Size indicated in the image manager.
-
@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.
-
@george1421 ok looking forward the info.
-
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.
-
@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.
-
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
-
@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??
-
@Sebastian-Roth Here it is :
! -
@processor Please post the contents of the text files
d1.partitions
andd1.minimum.partitions
from that image. -
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
-
@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 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). -
@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.
-
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.
-
I can confirm that the fogftp error is related to the ini file uploaded as putting back the old file solved this problem.
-
@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? -
@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.
-
@processor Did you get to test if it’s definitely the changed inits causing/fixing the FTP error?
-
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
-
@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
tofogproject
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.