I doesn’t see it fixed in the repo.
So here is the quickfix if you need to deploy some images right now (i was in this case after upgrading to trunk…)

In fogproject/packages/web/lib/fog/StorageGroup.class.php
On line 46 :

'typeID'=>explode(',',$this->getSetting('FOG_USED_TASKS')),

Should be :

'typeID'=>explode(',',$this->FOGCore->getSetting('FOG_USED_TASKS')),

Hi Tom,

the OP showed both d1.minimum.partitions and d1.original.partitions but not the output of the real partitions size created by the scripts, as it could be shown with a fdisk, that’s why i asked him to post the output, to compare theory VS reality, to be sure it’s the same problem.
As we can see the first partition is a dell Utility partition (type de) like in my case. Maybe this is a particular dell behavior…

Hi, you’re right it’s not litterally a “bug”. It’s more a strange behavior (that’s why i posted in General section).

Sorry ! it’s right i didn’t checked the last commit because i’m working with fog only in a special environment and i was on others things last days.

It can’t be the ip directly because when you’re hosting the fog webservice in a VirtualEnv environment, you must pass the complete subdomain/domain for your webserver to redirect accordingly. So the client as to send his POST/GET commands to the hostname not the ip !
Hosting services in VirtualEnv is common.
Sure, it’ll work if your fog virtualenv is configured as the default one (pointing to the ip will redirect the webserver to the default virtualenv and it’ll will works), but if you host several webservices on the same webhost (or webhost farm) AND fog is not the default one, you must pass the domain name and not the IP. If you don’t do this, the webserver will answer back with your default virtualenv which can be anything but fog.

BTW, in my opinion, resolving a hostname is a client behavior.

Thanks for your time !

Is it the same problem as i described here ?
https://forums.fogproject.org/topic/5165/partition-size-too-little-with-a-single-disk-resizable-image-svn-3537

Can you compare your d1.minimum.partitions with the output of a

fdisk /dev/sda -lu

Hi any news on this ?
Was it a user request to let the server resolve the hostname ? It’s a so strange behavior…it breaks all client network intelligence. I don’t find any usefull behavior with a server-side name resolution.

Hi Tom,

i continue to hit the same problem even with upload/download made on the latest revision. My sda1 always lack 4/5MB and thus the cloning for this paritition fail.
I can go through the code to see if i find something which can resolve the issue for me. Can you just guide me to where the partitions creation take place in the case of a resizable image download task ?

Thanks for all your work and reactivity !

Guillaume

Ok i understand.
You let the server resolves the hostname for the client because they may not know how to resolve by themselves.
But which are the condition where the client does not know how to resolve ?
If i put an ipadress in the FOG_WEB_HOST it’s not necessary to resolve -> i want to force this particular ip for all clients, so it’s ok to not resolve on the server
If i put a domain in FOG_WEB_HOST and server and clients are binded to the same dns and both will resolve to the same ip, , so it’s ok to not resolve on the server
If i put a domain in FOG_WEB_HOST and server will resolve to an ip X and clients to an IP X or Y or Z depending of their dns configuration. If i have those kind of configurations, that’s mean that i divided my network and want everybody to get informations from their relative DNS, so the client has to resolve, not the server.

I don’t see any case where the server should resolve for the client. If my client hosts gets different DNS, it’s for a reason isn’t it ? Maybe i didn’t see a special case.
The only special case i see is that my clients doesn’t have any DNS server set at all and can’t resolve by themselves. Is it possible to send the DNS server set for the eth card to the php script with the POST/GET vars ? If not set, server resolve for the client, if set, it let the client resolve ?

It’s what i thought but it’s not working like that apparently.
My FOG_WEB_HOST is correctly set (since ages) yith the domain name, but if i echo the $web var in the shell or in the fog.checkin script it’s always the ipaddress which echo.

I found the bug here
in BootMenu.class.php line 17

$webserver = $this->FOGCore->resolveHostname($this->FOGCore->getSetting('FOG_WEB_HOST'));

has to be changed to

$webserver = $this->FOGCore->getSetting('FOG_WEB_HOST');

The $this->FOGCore->resolveHostname() replace the hostname with the ipaddress

Hi,

my fog server is running in a virtual domain.
Until then it was working fine.
I just recently updated to latest rev and the /bin/fog.checkin script seems to use a $web var everywhere to execute the .php scripts…
This var is set to my webserver IP adress, but i want it to be set to the subdomain name for which the webserver bind to the correct virtual domain.
I didn’t find the source of this var. Where can i change this var ?

Thanks,
Guillaume

Hi Tom,

i deleted all files in my image directory for this particular image.
I reuploaded from the “good” computer a brand new image (so it’s an upload with the svn 3537 rev).
I’m hitting the same problem when downloading the resizable image to another computer (which is exactly the same model : a Dell3020).

partition sda1 is not created with the correct size even if the d1.minimum.partitions is correct.

Thanks,
Guillaume