Bugs in FOG 0.33
-
Hi Tom, below are messages seen in /var/log/apache2/error.log file
Let me know if you need the whole file, thanks
[Fri Jan 10 17:09:00 2014] [error] [client 10.10.6.31] PHP Notice: Constant WEB_ROOT already defined in /var/www/fog/commons/config.php on line 92, referer: [url]http://10.10.6.97/fog/management/index.php?node=home[/url]
[Fri Jan 10 17:09:10 2014] [error] [client 10.10.6.31] PHP Notice: Constant WEB_ROOT already defined in /var/www/fog/commons/config.php on line 92, referer: [url]http://10.10.6.97/fog/management/index.php?node=home[/url]
[Fri Jan 10 17:09:11 2014] [error] [client 10.10.6.31] PHP Notice: Constant WEB_ROOT already defined in /var/www/fog/commons/config.php on line 92, referer: [url]http://10.10.6.97/fog/management/index.php?node=home[/url]
[Fri Jan 10 17:09:13 2014] [error] [client 10.10.6.31] PHP Notice: Constant WEB_ROOT already defined in /var/www/fog/commons/config.php on line 92, referer: [url]http://10.10.6.97/fog/management/index.php?node=home[/url]
[Fri Jan 10 17:09:15 2014] [error] [client 10.10.6.31] PHP Notice: Constant WEB_ROOT already defined in /var/www/fog/commons/config.php on line 92, referer: [url]http://10.10.6.97/fog/management/index.php?node=home[/url]
[Fri Jan 10 17:09:17 2014] [error] [client 10.10.6.31] PHP Notice: Constant WEB_ROOT already defined in /var/www/fog/commons/config.php on line 92, referer: [url]http://10.10.6.97/fog/management/index.php?node=home[/url]
[Fri Jan 10 17:09:19 2014] [error] [client 10.10.6.31] PHP Notice: Constant WEB_ROOT already defined in /var/www/fog/commons/config.php on line 92, referer: [url]http://10.10.6.97/fog/management/index.php?node=home[/url]
[Fri Jan 10 17:09:21 2014] [error] [client 10.10.6.31] PHP Notice: Constant WEB_ROOT already defined in /var/www/fog/commons/config.php on line 92, referer: [url]http://10.10.6.97/fog/management/index.php?node=home[/url]
[Fri Jan 10 17:09:23 2014] [error] [client 10.10.6.31] PHP Notice: Constant WEB_ROOT already defined in /var/www/fog/commons/config.php on line 92, referer: [url]http://10.10.6.97/fog/management/index.php?node=home[/url]
[Fri Jan 10 17:09:25 2014] [error] [client 10.10.6.31] PHP Notice: Constant WEB_ROOT already defined in /var/www/fog/commons/config.php on line 92, referer: [url]http://10.10.6.97/fog/management/index.php?node=home[/url]
[Fri Jan 10 17:09:27 2014] [error] [client 10.10.6.31] PHP Notice: Constant WEB_ROOT already defined in /var/www/fog/commons/config.php on line 92, referer: [url]http://10.10.6.97/fog/management/index.php?node=home[/url]
[Fri Jan 10 17:09:29 2014] [error] [client 10.10.6.31] PHP Notice: Constant WEB_ROOT already defined in /var/www/fog/commons/config.php on line 92, referer: [url]http://10.10.6.97/fog/management/index.php?node=home[/url]
[Fri Jan 10 17:09:31 2014] [error] [client 10.10.6.31] PHP Notice: Constant WEB_ROOT already defined in /var/www/fog/commons/config.php on line 92, referer: [url]http://10.10.6.97/fog/management/index.php?node=home[/url]
[Fri Jan 10 17:09:33 2014] [error] [client 10.10.6.31] PHP Notice: Constant WEB_ROOT already defined in /var/www/fog/commons/config.php on line 92, referer: [url]http://10.10.6.97/fog/management/index.php?node=home[/url] -
If you update to the latest and greatest of fog, the already defined messages should stop.
Other than that, based on what you’ve provided here, I don’t see anything that’s useful yet.
-
Tom,
Just had a look into to bin/fog and found the section relating to the image type I’m using (mps), the process seems to be failing at some point between these commands when imaging to a blank HDD. I’ve attached the relevant section in a text file for you.
My guess is at lines 32 to 42 in the attached, unless Partprobe cannot read the partition table on line 28 (though ‘Checking hard disks’ returns ‘Done’). It seems to skip everything after line 30 right down to line 89 for ‘Task Complete’.
Can you see anything that would prevent the blank HDD from being partitioned correctly? I’m at a loss currently!
Thanks
LA[url=“/_imported_xf_attachments/0/478_fog_mps.txt?:”]fog_mps.txt[/url]
-
Luke,
What are you trying to image? Linux/Windows? I ask because the lines you seem to be referencing look to be for linux OS’s. If this is the case, then I’d recommend doing a debug mode and actually creating a temporary partitioning scheme for your Hard disk.
What I mean by this, is, though it typically creates the partitions for you, sometimes uninitialized drives are completely uninitialized. This means it’s never had any type of partitioning table and FOG can’t recognize the drive in even it’s simplest of forms.
Typically drives that are initialized with even the most simple of data, (a simple
[code]fdisk /dev/sda >> EOF
m
p
1
+100M
m
p
2+3000M
t
1
7
a
1
w
EOF[/code]While this may look tricky, it really is simple. All it does is create the 100M 1st partition (win 7) and creates a second partion with 3GB. It will be overwritten when FOG starts its imaging process. This also sets the 1st partition as the bootable section as well. Though I doubt we need that fine of adjustments. The fogpartinfo, as far as I can tell, can’t tell what the drive partitions are and fails because of this. It’s simple because the drive can’t give any information appropriately to the program and fails miserably.
Give these steps a shot, and let me know how it works. If it works, I’ll try to add it to the codebase so we don’t have this issue any more.
Will generally do the trick to allow FOG to write to the drive with little issue. I suppose
-
I just noticed, your text file is showing partimage now, is this your method or is this on an older revision of 0.33b?
-
Ok i have created the partitions using fdisk during debug mode, then retried the image process and am getting the same issue. Skips straight to ‘Task Complete’.
Also, the /bin/fog file was using partimage by default, i haven’t changed this. Using revision 1083.
Thanks
LA -
It shouldn’t be using partimage as I changed to partclone a while ago.
Can you try replacing your init.gz with mine located at:
-
Hi Tom,
I have been able to get multitask to work by using a partly manual process,
I ran the following cmd on the fog server-
gunzip -c “/images/win8/d1p1.img” | /usr/local/sbin/udp-sender --min-receivers 24 --portbase 63202 --interface eth1 --max-wait 90 --half-duplex --ttl 32 --nokbd;gunzip -c “/images/win8/d1p2.img” | /usr/local/sbin/udp-sender --min-receivers 24 --portbase 63202 --interface eth1 --max-wait 10 --half-duplex --ttl 32 --nokbd;
this then listens for host connecting ,
I then use the Fog to run a task to deploy to a group of ps using multitask, this the creates the job, in the /tftpboot/pxelinux.cfg/<pc mac address>
the contents of such a file is below,
DEFAULT fog
LABEL fog
KERNEL fog/kernel/bzImage
APPEND initrd=fog/images/init.gz root=/dev/ram0 rw ramdisk_size=127000 ip=dhcp dns= mac=2c:44:fd:10:20:63 ftp=197.168.1.7 storage=197.168.1.7:/images/ storageip=197.168.1.7 web=197.168.1.7/fog/ osid=6 loglevel=4 consoleblank=0 irqpoll chkdsk=0 img=win8 imgType=mps imgid=4 PIGZ_COMP=-9 hostname=dc8300 port=666 type=down mc=yes
Notice the PORT number is 666, I manually changed this on each is the files above to port 63202, when I ran the gunzip cmd using port 666 the multi tak did not seem to work and pc stayed waiting on the partclone screen.
Would you be able to help or point me in the right direction,
Which bit sets multitask to use port 666?, what mechanism caused the above gunzip cmd to run.
Thanks Tom,
Denis -
I can fix the port problem relatively easily. It’s in Host.class.php from {fogwebdir}/lib/fog/Host.class.php line 641. GIve me a few minutes and I’ll see where the port is specified (if so) from the FOG GUI. Right now it’s manually set to 666 which, as far as I can tell, it should be pulling the information from somewhere.
-
Hi Tom, Thanks for that information and for r1094 update. I have applied the update and this now uses the value on fog settings>FOG_UDPCAST_STARTINGPORT, however just to make you aware there is a minor typo in the {fogwebdir}/lib/fog/Host.class.php , line 641, there is space that needs to be removed to make is work.
Any idea where the udp-sender cmd is being sent from, as in order for multicast to work this cmd currently still needs to be send manually.
Thanks again -
I believe the udp-sender is performed by the FOGMulticastManager service found in /opt/fog/service/FOGMulticastManager and started with the command:
[code]sudo service FOGMulticastManager restart[/code] -
Hi Tom, thanks , the service FOGMulticastManager is running…,
from checking the file, it looks like the multicast cmd comes from /var/www/fog/lib/MulticastTask.class.php
not sure from where and how the file and cmd gets run… -
The file is actually in:
/opt/fog/service/common/lib/MulticastTask.class.phpI’m taking a look right now.
-
Hi Tom, Apologies - not sure where I got that file path from.
Thanks very much for looking into this further… -
I have found that you cannot delete an Image from the GUI because the images are being created as root:root instead of fog:root
after changing the permissions of the files I am able to delete the images from the GUI> -
The images directory should be set as:
[code]chmod 777 -r /images[/code]This should allow you to delete the files. The Ownership shouldn’t matter.
-
The latest fog should have Multicast Tasks working appropriately now. r1106 should allow all of this to work, create, start, cleanup, and what not.
-
All,
Just a heads up on the UDP Port created. I’ve changed it to get the setting from the web GUI, You can set it, but I’ve added another feature to the class files that randomly generates a new port number (even) between 2 and 65534 (port 0 is invalid, port 65535 is invalid) so, while you can manually specify a port number, it also automatically/randomly sets a new port number after a multicast task is created. This way you can create multiple multicast jobs without worry if the port is already in use. That’s not to say it couldn’t recreate the same port, but it’s a fairly wide range so it’s unlikely to create a port that already exists.
-
Hi Tom, great job regarding the multicasting and all the other improvement you’ve made, I will get a chance on Monday to test it.
Thanks again for your effort! -
Denis and all,
You’re very welcome. Just test and let me know of any issues you run into, I’ll try to fix them when I can.
As a side note, I think all should be aware of, besides the whole port randomization thing all of the multicast jobs, and as I find them, other imaging/non-imaging tasks (wake on lan, snapin deployment, etc…) will be performed by the Host.class.php file. I am using this as it’s already designed to handle the deployment of tasks, why not use it to create my tasks as I imagine they were intended.
As I delved into these pretty head strong on the idea, I also am starting to wonder if the reason 0.32 had issues isn’t similar to the cause of the issues I was running into, but able to fix.
