Latest FOG 0.33b
-
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?
-
I’ll have to take a look to have it image each part found, rather than limiting the number actually restored. It may take a little bit.
-
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.
-
Hey Tom I have been having nothing but trouble with fog and hyper - V I finally got the machine to regester to the fog data base but now when I go to the Web gui to look at the computer I get this error
FOG DEBUG HOST: Database load failed: ID 0, error: operation field not set: ID
-
Troye,
Have you edited the Host.class.php file? Did you remove or change the line:
[php]‘id’ => ‘hostID’,[/php]It should be line 11 in the file.
-
No I think I figured out why I dropped the database and reinstalled fog. then when I re-added my image on the machine i notice I was using a lower case w and not a Cap W.
