Latest FOG 0.33b
-
While I won’t be using this adjustment, I think I see what the problem is.
When you have multiple storagenodes, it only set’s one of the ip’s to rename, but it tries to copy to the latest one, which it can’t do because the username and password are set prior.
If I bring the tasks that perform the ftp moves into the loop we should be good to go.
If you don’t mind test one more time. I’m updating as we speak.
-
More insight as to why I’m choosing this method over yours is in Host.class.php the ftp that gets sent back to the Post_Stage2.php file is always:
‘ftp=’ . $this->FOGCore->resolveHostname($this->FOGCore->getSetting(‘FOG_TFTP_HOST’))
This mean’s it’s always using the TFTP IP Address rather than the Actual Storage node. This, by itself, isn’t necessarily bad, but your method is essentially stopping the actual storage node from receiving the data.
If I bring the tasks to actually FTP the data into the Loop, it will loop the tasks by themselves and should automatically send the data to both storage nodes.
-
r1078 should correct this, but again I have no ability to test.
This new methodology should push the data to the proper node.
Basically, what was happening before all this, was it would loop through all the nodes but it wouldn’t set the ip, path, or user for each of the nodes, it only did the last node in the loop. The new method should ftp the data to each of the nodes relevant to the host.
-
Oh,
One more reason why I didn’t want to use strcmp is it requires both strings to be the same. So let’s say you set your Storage IP as fog.something.com while the TFTP information is 10.0.7.1, it would always return with a negative/positive (depending on order you check) which would basically stop any task from happening.
-
r1080 released,
More service file updates. Hopefully more streamlined approaches to things.
-
Thanks for all of your work Tom, I know we keep telling you, but I feel if we don’t take rounds you will stop updating
Speaking of update, I’m going to go update my 0.33b server
-
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]
-
It looks like you don’t have base64 installed on your version of init.gz. I haven’t run into these issues on mine. Is there specific method you’re trying to add for the options? It looks like you’ve removed the base64 from busybox and I don’t see base64 as a target package under buildroot’s menuconfig.
What issues are you having with the busybox version specifically?
-
Hey tom I have a question I am trying to build a VM using hyper v and I am running into two distanct issues one being that none of the vm’s are finishing the host
inventory it stops at the sending to inventoey . so it does add it to fog so I just restart the machine then it picks up the image task and images the VM when lt finishes it does not boot to the os it boots back into the fog tftp and says no active task found for hostname any ideas on how to fix this -
What revision are you on? I had a typo, and am working on correcting another one I found.
r1081 is the latest, and in about 2 minutes we’ll be on r1082.
-
I am on R1080 I downloaded it last night. EST time like 10:00
-
r1083 released.
Updated TomElliott.config file for 3.12.7
sdb is the normal first harddrive detected as the Rootfs is now booted on it’s own partition table. May update this later on to correct that, but for now everything seems to be working fine.
-
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, namelyrename init.gz to init.xz
xz -d init.xz
xz -z -9 init
rename init.xz to init.gzAny thoughts
-
I think you need a security descriptor with xz, give me a moment and I’ll try to post the exact command line for xz, though you could very well just recompress as gzip if you really want a good test.
That being said, there are many things that rely on base64 during the sending, so it being missing strikes me as very odd.
Decrompression should be very easy with just:
[code]xz -d -c init.gz > init[/code]Back with the xz compression command should be:
[code]xz -9 -C crc32 -c init > init.gz[/code]
Or you can do your method of:
[code]xz -9 -C crc32 -z init
mv init.xz init.gz[/code]Then test again and see if all is working. I’ll perform a few tests on my end as well just to clarify some more.
-
r1084 released. Though progress not working, init.gz is updated. Partclone binaries for 32 bit are updated to allow writing to our log file (/tmp/status.fog) and redirects still allow display of the information, though I don’t know if it actually writes that data there. Basically I made partclone display to stdout rather than stderr.
-
r1085 released.
Progress information is back. This is only good, so far, for partclone as the order of writing to the /tmp/status.fog file is different. Theoretically, this will work for non ncurses mode as well. We have client display progress and gui progress. This should work for all types of download/upload task imaging as well. Hopefully you all enjoy. Please test and let me know.
Thank you,
-
r1086 released.
Adjusts the TomElliott.config to work better. Back with /dev/sda.
-
R1087 released. Fixes error thrown for service configuration page.
-
r1088 released. More service pretty ups.
-
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]
