Latest FOG 0.33b
-
r1013 is out. Please try this and let me know.
Thanks,
-
[quote=“Tom Elliott, post: 20740, member: 7271”]r1013 is out. Please try this and let me know.
Thanks,[/quote]
I can not test this now, will test it tomorrow. Thanks for your quick response.
Edit:
I looked into the current revision. You didn’t fixed the syntax error, here:
[CODE]if [ “$partitionStart” == “” || “$partitionStart” == “1” ]; then[/CODE]Is in file src/buildroot/package/fog/scripts/bin/fog on line 837. Please fix.
Ty,
Albatros -
Yes I did fix that, but not quite on the src/buildroot side yet. I just created a couple of patches and updated a few of the FOG components. Once tested and working, I’ll update the src directories with all the proper information.
In the init.gz file, however, this fix is already in place. If it didn’t take I don’t know why not, but the build I’m setting up right now will, for sure, have this in place.
-
r1016 released.
@Albatros
I think, if I hadn’t have had that typo (besides line 837) it was actually a problem with the parted command itself. It was trying to align the first sector of the disk for optimal value, but the sector 63 is not optimal for the drive and parted would just fail miserably. Without the -a opt, it should, essentially, force 63s.Updated all the src packages and even was able to update pigz to the latest revision 2.3.1. Fixed the issue in the download information for pigz so it should download properly. Created a patch for chntpw-source-110511, so it corrects the mistakes that, originally, forced me to create my own chntpw package. Removed the dl directory to save some space. Stripped the partclone binaries so things are slightly smaller.
The init.gz is now compiled using the sed from buildroot, rather than the sed from busybox. This relates to awk as well so hopefully if you are doing debugging, you get more familiar code base rather than, I think, the limited code base from the busybox binary.
I hope this fixes the issues we saw today. Basically, I was idiotic. I thought I gzipped the package, but that would have worked fine. It was my compression (manually) that caused the issue. I was using:
[code]lzma -z -9 -e -c rootfs.ext2 > init.gz[/code]
When I should have only been using:
[code]lzma -9 -e -c rootfs.ext2 > init.gz[/code]Theoretically the -z shouldn’t have mattered, but it did in this case. Sorry about that everybody.
My tarball is updated to the latest revision as well if you want to use that. It doesn’t contain the .svn information which will ultimately get copied to your fog server if you use the svn checkout method.
bzImage is still, in this revision, set as 3.12.2. I’m well aware, and have already compiled (as usual) 3.12.3 and it can be downloaded using [url]https://mastacontrola.com/fogboot/kernel/bzImage[/url] as per usual.
Hopefully this helps everyone, and again, I’m very sorry about all the problems today.
-
Tested new revision, checked start sector from debug mode it shows now 63. Tried to upload image, get the error shown in the image of this [URL=‘http://fogproject.org/forum/threads/latest-fog-0-33b.6476/page-12#post-20738’]post[/URL].
-
[quote=“Albatros, post: 20738, member: 16710”]Ty, Tom.
I tested it and got syntax error on line 837. Had to change
[CODE]if [ “$partitionStart” == “” || “$partitionStart” == “1” ]; then[/CODE]
to
[CODE]if [ “$partitionStart” == “” ] || [ “$partitionStart” == “1” ]; then[/CODE]After I fixed that , I get this error
[IMG]http://i.imgur.com/ifmTWSi.png[/IMG]Sorry that I have now the next error.
Ty very much for your great work, will try to test snapins tomorrw and will will report back.[/quote]Is this the pic you’re referring to.
-
Yes, I have linked to that post in my post.
-
Albatros,
I’m currently downloading a Windows XP iso and going to give this a test after installing it. Hopefully I’ll figure out a fix for your particular issue man.
-
Same thing here. Was finally able to get it to boot to Capone but it gets stuck on Looking Up DMI field. During the initial image I chose a DMI field and put it in the Capone config but still stuck. 0.32
-
You’re using FOG 0.33, or 0.32? I’m not doing any work on 0.32, though I could possibly help if you can get more information.
I’ve tested a few things, and am currently rebuilding the init.gz with a modified version of the current FOG Script in the init.gz file. However, this modification is very slight.
It was, apparently, not resetting the boot flag on the device, which caused the drive to essentially break, causing the particular issues you where seeing. I know it’s not ideal, but I believe you may have to reinstall Windows XP again. Update your FOG server to the latest revision and give this a shot.
The revision will be up in about an hour or so. The revision will be r1018. Revision 1017 has just the updated fog script in src/buildroot/package/fog/scripts/bin and [b]NOT[/b] the init.gz file. r1018 will contain the updated init.gz.
-
Hello Tom.
I tested the new revision and I was able to upload a Windows xp image to the server. I think you still working on downloading a image from the server to the client?
I have tested snapins and had a few errors that I fixed. After this fixes I could install snapins, without any problems.
[CODE]packages\web\lib\fog\ClientServiceManager.class.php
- On line 33, 44, 53 and 61 replaced get(‘id’) with getId(), because there is no method named get(‘value’), but a method named getId() in file packages\web\lib\fog\SnapinTask.class.php
packages\web\service\snapins.file.php
- On line 48 replaced $this->FOGCore with $FOGCore
- Removed the / in all lines containing $FOGCore->getSetting(‘FOG_SNAPINDIR’). ‘/’ .$snapinTask->getSnapin()->get(‘file’)
- On line 53 replaced $snapinTask->getSnapin()->get(‘file’) with $FOGCore->getSetting(‘FOG_SNAPINDIR’). ‘’ .$snapinTask->getSnapin()->get(‘file’)
[/CODE]
-
[quote=“Albatros, post: 20770, member: 16710”]Hello Tom.
I tested the new revision and I was able to upload a Windows xp image to the server. I think you still working on downloading a image from the server to the client?
I have tested snapins and had a few errors that I fixed. After this fixes I could install snapins, without any problems.
[CODE]packages\web\lib\fog\ClientServiceManager.class.php
- On line 33, 44, 53 and 61 replaced get(‘id’) with getId(), because there is no method named get(‘value’), but a method named getId() in file packages\web\lib\fog\SnapinTask.class.php[/code]
[/quote]
Thank you very much for this, I’ll update the files and push the revision. That said, the lines referenced as $snapin->get(‘id’) should work fine as it’s a class which extends the FOGManagerController which uses get(‘<value>’) as the function.
I’ll try with just the $snapintask->get(‘id’) to $snapintask->getId(). If it still doesn’t work after that let me know and I’ll fix the other two lines.
[quote=“Albatros, post: 20770, member: 16710”][code]packages\web\service\snapins.file.php
- On line 48 replaced $this->FOGCore with $FOGCore
- Removed the / in all lines containing $FOGCore->getSetting(‘FOG_SNAPINDIR’). ‘/’ .$snapinTask->getSnapin()->get(‘file’)
- On line 53 replaced $snapinTask->getSnapin()->get(‘file’) with $FOGCore->getSetting(‘FOG_SNAPINDIR’). ‘’ .$snapinTask->getSnapin()->get(‘file’)
[/CODE][/quote]
What errors did you get here? What is the setting for FOG_SNAPINDIR? Or did you just modify so you don’t have a reference as: /opt/fog/snapin//filename.whatever?
That’s too easy a change, but shouldn’t affect the file downloads.
- On line 33, 44, 53 and 61 replaced get(‘id’) with getId(), because there is no method named get(‘value’), but a method named getId() in file packages\web\lib\fog\SnapinTask.class.php[/code]
-
r1019 released to correct issues reported above.
Fixes snapintask->get(‘id’) to snapintask->getId()
Fixes $this->FOGCore to $GLOBALS[‘FOGCore’] and removes ‘/’ references in snapins.file.php
-
For $this I got this error: PHP Fatal error: Using $this when not in object context in /var/www/fog/service/snapins.file.php on line 48
I think this error occurse, because the file snapins.file.php is no class.I had to remove the /, because I had as path /opt/fog/snapins/ in the database, you add there /, then the path is /opt/fog/snapins//<filename>.
For line 53, I got this warning: PHP Warning: filesize(): stat failed for 1.7.0_40_32.sfx.exe in /var/www/fog/service/snapins.file.php on line 53. I changed it to this line, then the could be found
[CODE]header("Content-Length: " . filesize( $FOGCore->getSetting(‘FOG_SNAPINDIR’).‘’.$snapinTask->getSnapin()->get(‘file’)));[/CODE]Edit: Ops was writing a answer to your post before. Will test the new revision.
Edit 2: I tested it, here is a error from the apache log: PHP Fatal error: Call to undefined method SnapinTask::get() in /var/www/fog/lib/fog/ClientServiceManager.class.php on line 61
I don’t see that the class SnapinTask extends from a other class. -
r1020 released with snapin using getId().
Hope this helps.
-
r1021 released. All I did was make the fog.css, more or less, the same is it used to be before my own edits to it were made. Fixed positions are nice, if the display is consistently the same size, but if you minimize the window or make it smaller, the items don’t move which can be problematic.
[quote=“Albatros, post: 20776, member: 16710”]I don’t see that the class SnapinTask extends from a other class.[/quote]
SnapinTask doesn’t have an extension to any other class, however Snapin.class.php does. I made the edits you suggested anyway, but will look into recreating SnapinTask so that it is an extension of another class that uses the get() methods properly. The reason it doesn’t now is beyond my scope of reasoning.
-
Modified ClientServiceManager.class.php back to original settings using get(‘id’) rather than the function getId so things are, hopefully, in line with one another.
Please test it.
r1022 released.
Modified SnapinTask to align more properly with the extending of classes. Added manager class for this class as well.
-
Tested the new revision, get an error from fog service, that the file size is zero.
In file snapins.file.php on line 53 is not given the full path to the file in filesize. After fixing that, the snapin could be downloaded.
Another problem now, the task for the snapin is not get remoed after the installation has finished, means the fog service download/runs the file after it finished again. -
Added the file location to the snapins.file.php file.
Went back to getId() rather than get(‘id’) just as test point. I’m thinking it can’t find the task, therefore can’t remove the task.
r1023.
-
Hi! I’m on revision 1023 and I have two problems when I’m trying to upload an image:
[LIST=1]
[]This is not really important, I have an annoying message that stays for 4-5 minutes with this information. After that the system continues with the image upload. [IMG]https://lh4.googleusercontent.com/-XzXBiI-hhHE/UqjvRCumKuI/AAAAAAAAZIM/X460BXOk748/w929-h697-no/IMG_20131211_183223.jpg[/IMG]
[][S]Sorry, this problem is solved. My fault[/S]
[*]There are still problems with logical partitions and swap?
[/LIST]
Thank you,
Joan
