Latest FOG 0.33b
-
First of all, thank you! You’re doing a great job
I want to ask for UEFI support, when I try to register a PC it throws an “unsupported BIOS version” error and later a Kernel Panic.
There are any news about of that?
Thanks!
Joan
P.D: I was writing this message at the same time as Albatros
-
The issue you’re seeing is the init.gz file you’re using, seems to not have lzma support. So it can’t mount the rootfs which will, of course, cause a kernel panic. You’re sure you’re on revision 1010?
I don’t have any UEFI systems to test with, but could you provide more information about the kernel panic? Ultimately, I don’t care so much about the error. That’s fairly typical as the kernel has many bios options available to it, but not all will be supported.
Thank you,
-
Well, I thought the error was caused by UEFI but it is the same kernel panic that Albastro has posted.
I’m running the r1010 revision.
Thank you!
-
I believe I’ve found out my idiotness of 1010. I gunzipped where I shoulda lzma’d. Right now I’m rebuilding init.gz so it should be fixed shortly, sorry about all of that.
-
r1011 released to address gzip/lzma issue. Also adds resize2fs program with Gilou’s suggestion.
Rsync is also included.
-
r1012 released to fix the FOG script again. FOG Script did not contain the sector 1 fix. Sorry about that.
-
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. -
You don’t have to be sorry for the error. It looks like it didn’t create the partition as required. Probably because it’s not actually resizing the partition in the code base. Rebuilding as we speak.
-
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]