Posts made by jbsclm

Please see attached for 2 files which resolve ( I hope ), the problems with capone.
they are
/fog/management/plugins/run.php
and
/fog/service/capone.php

[url=“/_imported_xf_attachments/0/517_run.zip?:”]run.zip[/url]

I can see what is going wrong in the capone code, I’ve got the management plugin working correctly, and am looking at the service code, but I’m missing something obvious at the moment.
I’ll post the amended versions when I sort it out.

Hi Tom, sorry for the delay, the attached is access.log, error.log and screenshot.
I restarted apache2 just before booting the client so these are the complete logs.

[url=“/_imported_xf_attachments/0/511_error.zip?:”]error.zip[/url]

Sorry, my typo, r1126, just downloaded this evening

Sorry Tom, just testing capone, it hangs at “looking for images”
There is the following in the apache error log.

[client 192.168.3.10] PHP Warning: vsprintf(): Too few arguments in /var/www/fog/lib/db/MySQL.class.php on line 105

I am running r1026 on Ubuntu LTS 12.04

[url=“/_imported_xf_attachments/0/510_boottest.png?:”]boottest.png[/url]

Aha, I understand the issue around the double equals sign now.
This is on Ubuntu 12.04 LTS, I haven’t tried on Fedora 20.
If I call “sh installfog.sh” it uses dash, which doesn’t support the “==” operator, and flags an error.
If I call ./installfog.sh it uses bash which does support “==”.

Thanks for the capone stuff, will check it out over the next day or so.
Have just noticed a typo in installfog.sh, double equals on line 176.
I’ve changed our 0.32 install to include capone deployment in the “imaging over last 30 days” graph by:

1. change the source of this graph from tasks to imagingLog.
2. change capone.php to insert an entry in the imaginglog
   Any chance of doing something similar at 0.33?
   as a further thought
   3 add a field to imagingLog, to store the pc id criteria, ie for capone “system-serial-number=12345”, or a normal task “mac=<mac address>”
   This would keep an imaging history for each device. (multicast may be an issue)

Fedora 20 and Ubuntu 12.04
Fedora 20 does not install cleanly, but works with a bit of tweaking.

I completely understand, your work is much appreciated. I’m happy to help where I can.
John

Tried a clean install of 1101 on Ubuntu LTS 12.04 , still getting “FOG DEBUG: FOGPageManager: Class: TaskManagementPage, Method: deploy_post, Error: Method not found in class, defaulting to index()” when attempting to upload or deploy tasks. Group deploy seems Ok, but managed once to start an upload task, I must have done something differently(?), but getting the error all the time on task upload/download/advanced now.
Is anyone else seeing this?
Have changed the capone code to reflect the fact that osid is now in the images table, and sorted a couple of other issues in the capone code, see attached.

[url=“/_imported_xf_attachments/0/489_capone.zip?:”]capone.zip[/url]

running 1095 on Fedora 20
when trying to set up deploy task.
“FOG DEBUG: FOGPageManager: Class: TaskManagementPage, Method: deploy, Error: Method not found in class, defaulting to index()” at top of screen.
and
Constant WEB_ROOT already defined in /var/www/html/fog/commons/config.php on line 92, referer: [url]http://localhost/fog/management/index.php?node=tasks&sub=deploy-post&type=2&id=3[/url]
in the apache error log
The task doesn’t get set up
Both errors also seen at 1089, I’ve been installing the new svn over the top of the old, if that makes any difference
I have seen references in the forums to the WEB_ROOT message.

Any ideas?

Capone problem solved, you had a missing quote in your fog.capone, corrected one attached.
Don’t forget to chmod 755 it once you’ve copied into /bin

Now to work on some of the other capone stuff!

[url=“/_imported_xf_attachments/0/479_fog.capone.zip?:”]fog.capone.zip[/url]

Testing capone on 1089, not working, dies early on. Other things work, strange thing is it fails the same if I replace fog.capone with the one I posted earlier. Will investigate further tomorrow.

Thanks for the details on how to rebuild init.gz, that has worked for me, and I now have capone working.
There were 2 changes needed to get it working, remove -l option from base64, which busybox doesn’t seem to like, and replace 3 calls to cut with awk, this is an old bug which has been fixed several, but the fixed code never made it to the svn
Any chance you can put the new fog.capone into the init.gz in the next release.
We do all our imaging via capone on the serial number, I’ve got some other changes on our current 0.32 setup, which I’ll migrate to 0.33, and submit for your assessment.

Rgds

[url=“/_imported_xf_attachments/0/477_fog.capone.zip?:”]fog.capone.zip[/url]

Following on from my earlier post, I’ve upgraded to 1083, and am still getting the base 64 error as per the previous screenshot.
I get get the error having made no changes from the downloaded svn
I’ve modified init.gz in the past to resolve problems and want to do the same at .33, however when I uncompress init.gz and recompress it, [COLOR=#ff0000]having made no changes[/COLOR], it doesn’t work. I’m using a similar process as to what I have done at 0.32, except changing gzip for xz, namely

rename init.gz to init.xz
xz -d init.xz
xz -z -9 init
rename init.xz to init.gz

Any thoughts

Many thanks for all the good work.
I’m testing capone on 0.33b, on Fedora 20 and getting the attached error.
I suspect the busybox version of base64 doesn’t support the same options as the gnu one, and am trying to rebuild init.gz once I’ve edited it, however it fails after starting the kernel.
I’ve tried uncompressing and re compressing init.gz without any changes and that also fails.

what I’ve tried is
rename init.gz to init.xz
xz -d init.xz
xz -z -9 init
rename init.xz to init.gz
The file size before is 8022184, afterwards 8022188, and it doesn’t work
I’m on a recent release,
What am I doing wrong?

[url=“/_imported_xf_attachments/0/474_boottest.png?:”]boottest.png[/url]

A word of warning, we tried gpxelinux and http in our live environment, but found that performance was much worse that pxelinux and tftp.
Looking at the wireshark traces showed lost of retransmissions, whci is well documented on the web, mainly in a vmware environment. From what I could see on the web there is no solution, so we have reverted back to pxelinux and tftp.

I’ve not tried it, but the boot file that gets generated has the http path rather than the file path.
It must use

FOG_TFTP_PXE_KERNEL
FOG_PXE_BOOT_IMAGE

for its kernel and init.gz.

We use capone ( with a couple of tweaks ) tied to the system serial rather than multicast.
The tweaks we have mean that we get an image history for each PC, so we know if it has a history of rebuild.

I just missed one step I think.
When you create a task, it puts in the default values for kernel and boot image, you need to go into fog settings and set the following
FOG_TFTP_PXE_KERNEL
FOG_PXE_BOOT_IMAGE
to
[url]http://192.168.1.104/fogboot/kernel/bzImage[/url]
and
[url]http://192.168.1.104/fogboot/images/init.gz[/url]

substituting your own Ip address

If you don’t change these then it will use tftp.

BTW my screen looks normal, I’m using virtual box

I’ve managed to get it to work in a test environment, see the attached zipped word document.
We don’t use multicast, and get slow loading when imaging PCs, this may well improve things for us.

Let me know how you go on.

[url=“/_imported_xf_attachments/0/234_gpxelinux.zip?:”]gpxelinux.zip[/url]