Latest FOG 0.33b
-
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]
-
I’ve made the changes you suggested, and made all cut -d"|" -f{field number} to awk -F"|" ‘{print $<FIELD>}’ where appropriate. Once built, I’ll update the init.gz on svn.
Thanks and hope you’ll enjoy the updates.
-
r1089 released.
Contains the fixes suggested and includes the, now, redirect elements of partclone for the 64 bit binaries.
Updates to Service.class.php to work out UserCleanup service based on class file created.
-
Going to pull down and test. Ur the man Tom ;):)
-
Hi Tom and thank you again
I can confirm that the logical partitions are backed, the problem is in the restore.
When I made a backup of my disk, the backup folder contained:
-rwxrwxrwx 1 root root 32256 ene 10 13:51 d1.mbr*
-rwxrwxrwx 1 root root 20 ene 10 13:51 d1p1.img*
-rwxrwxrwx 1 root root 1208926132 ene 10 13:54 d1p2.img*
-rwxrwxrwx 1 root root 20 ene 10 13:54 d1p3.img*
-rwxrwxrwx 1 root root 20 ene 10 13:55 d1p5.img*
-rwxrwxrwx 1 root root 7934933 ene 10 13:55 d1p6.img*So the partitions 5 and 6 (both logical) were present (5 is swap and 6 is the /home) but when I restored the backup, only partitions 1, 2 and 3 were restored (3 is the extended).
Is there any way to give you more information?
