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
My bad : It was at REV 3443 and it has have been fixed between those two versions ?
As the d1.minimum.partitions was fine (generated by the upload task) i thought that it was only the download task which was buggy and so updating to latest rev would fix the download/create partition scheme part.
Hi,
I’ve changed an image from fixed size to the “Single Disk - Resizable” type and selected “All Partitions”.
I’ve uploaded correctly the image from a correct computer to reflect those changes, everything seems fine.
when i want to deploy i got the error of a “too little partition” for /dev/sda1…
So let’s check what should be done and what is done :
-I delete every partitions on the disk to have a clear partition table.
-I run the fog script (i’m in a download/debug task mode) to get the job done
-I wait for the error to appears
-I run a fdisk /dev/sda and print the partition table (the one just created by fog)
Device Boot Start End Sectors Size Id Type
/dev/sda1 63 79934 79872 39M de Dell Utility
/dev/sda2 * 79935 32933950 32854016 15.7G 7 HPFS/NTFS/exFAT
/dev/sda3 32933951 976772158 943838208 450.1G 7 HPFS/NTFS/exFAT
/dev/sda1 is 39M but i need 42M !
Let’s see what’s inside d1.minimum.partitions (d1.original.partitions is exactly the same) in the image folder
/dev/sda1 : start= 63, size= 80262, type=de
/dev/sda2 : start= 81920, size= 32854016, type=7, bootable
/dev/sda3 : start= 32935936, size= 943835136, type=7
Those values are exactly the same as the real partitions sizes from the original disk.
So the d1.minimum.partitions is not applied correctly while creating the partition scheme during deployment.
The sda1 partition is too small, the sda2 is correct and the sda3 has been correctly expanded with the bytes freed by the bad sized sda1…
Any idea how to fix this ?
Thanks,
Guillaume
SVN trunk rev 3537