Latest FOG 0.33b
-
I have tested fog rev 1435 and got the same problem in virtualbox and on a real pc.
-
r1437 should fix the Tasks’ issue you all were seeing. Many changes had to be made, all relatively minor though. Just so the new fields get appropriated properly.
-
r1439 released.
Move to post variables for the boot url’s. Adds checking for the architecture type. If the arch is set as i386, it will set the init.xz to init_32.xz and use bzImage32. May make a database entry adding 32 bit kernel/init.xz options for dynamics, for right now they’re hard coded. Kernel only gets set if the Host does not have a kernel set in it.
-
[quote=“Tom Elliott, post: 25110, member: 7271”]r1439 released.
Move to post variables for the boot url’s. Adds checking for the architecture type. If the arch is set as i386, it will set the init.xz to init_32.xz and use bzImage32. May make a database entry adding 32 bit kernel/init.xz options for dynamics, for right now they’re hard coded. Kernel only gets set if the Host does not have a kernel set in it.[/quote]
I am sad I can only like this once, I think this is an invaluable feature, thank you!
-
Just giving credit where credit is due,
Wolfbane8653 was the one who suggested the use of architecture checking. I completely forgot that was a command available to iPXE so thank you very much Wolfbane for the recommendation and command sequence needed to get it working.
-
r1440 released.
Fixes the default.ipxe file creation so it set’s to the new post stuff as well on update/install.
-
r1441 released.
Addes the two fields to the TFTP Server setting for 32 bit kernel and init setting. Updates the BootMenu to use these settings.
-
r1443 released.
FOG Settings categories are now expandable/collapsable elements.
-
r1445 released.
Fixes an issue where the forms weren’t being updated appropriately. SORRY guys.
-
r1446 released.
Just sets one form element so if you make multiple changes, the changes take effect on all elements you’ve changed.
-
r1448 released.
Sets the FOG Settings so the categories are no longer underlined. The div slides out underneath it as well.
Thank you,
-
Hello,
about The fog client in 0.33 does it work ?
Thanks!!
-
[quote=“lepretre, post: 25176, member: 3202”]Hello,
about The fog client in 0.33 does it work ?
Thanks!![/quote]
You could always install it and find out… It is stable but we are making changes constantly so if you use the SVN there may be problems here and there as we update. But then again you should never be using a Beta for a production environment.
-
I have it installed, It’s working on 0.32 but not and 0.33
I have php warning on the apache fog server.
It’s not a probleme i have the 0.32 and i can leave it running only for the fogclient.I test it in production :oops:where it’s not crucial and i always have a second solution !!(0.32 and clonezilla)
Thanks you very much for the answers!!!
-
The FOG client works fine in 33b… I’ve been using it for months.
You may want to provide more details or post a help thread elsewhere instead of in the release thread so we can troubleshoot and resolve your problem.
-
For info the probleme are virtualbox adaptator:
When i desactivate it the fog client have a good response from server.
-
[quote=“Tom Elliott, post: 21069, member: 7271”]All,
I’m moving my compression medium to xz rather than lzma. Though lzma seems to work rather well, xz is much better. The other part of my reasoning, is lzma doesn’t seem to maintain the same compression across different versions of itself. Meaning, if I compress the init.gz using lzma version 4.2 on one system, and uncompress it on lzma 4.9, it uncompresses fine. Recompressing it causes issues though for some, unknown to me, reason. For that reason, as far as I can tell, xz has maintained the same methods of recompression and does a very good job (better than lzma). I’ve included xz reading into my kernel file, which will be a must.
Please test and see how you like it. As alway’s, gzip compression is still available, and I’m keeping lzma available in the kernel as well, but I did add xz to the kernel parameters.
Please test the kernel, and for those of you on 0.33b, feel free to play with the init.gz:
[url]https://mastacontrola.com/fogboot/images/init.gz[/url] <-- goes in default location of /tftpboot/fog/images/init.gz
[url]https://mastacontrola.com/fogboot/kernel/bzImage[/url] <-- goes in default location of /tftpboot/fog/kernel/bzImage
I’m not adding these things into a new revision yet, as I’ve yet to hear back whether the kernel works on the Lenovo T440(s/p/etc…).
I’ve minimized my kernel, and it seems to me the configuration looks much more similar (all be it, seemingly, with more options – besides the newer features of the kernels since 2010) to the kitchensink kernel configuration. However, this kernel (I’ve tested), natively recognizes VMWare SCSI Drives (Win 7) and hopefully recognizes all different types of motherboard chipsets. If compressed with gzip, it seems to be about 13 MB, compressed with LZMA is just shy of 6 MB, and with XZ is a little more than 5.5 MB in size.
With this latest kernel configuration, I’ve also added RAID utilities to it. It should recognize hardware raid controllers, though I don’t know how to tell for sure as I don’t have another system with a hardware RAID system, for those of you trying to image servers or something of that sort.
Ultimately, I’m trying to assist in building a kernel that works across the board. I haven’t, quite yet, figured out a method of imaging LVM systems (the default filesystem layout for CentOS – and many more I’m sure) though my default debian install seems to image just fine (I think that has an LVM based file system as well.)
I hope you all are enjoying the latest and greatest I’m attempting to put out there.[/quote]
I am not sure if you ever received a response regarding the T440, however I downloaded your latest kernel to my .32 server per [url]http://www.fogproject.org/wiki/index.php/FAQ[/url] and I can confirm that the Lenovo T440 does work with this kernel. The t440 was one of the reasons I wanted to try out .33b.
-
r1451 and 1452 released.
Adds an example ltsp.conf file to the src/ipxe/src folder. This is only for the dnsmasq/proxyDHCP guys but this works with the undionly.kpxe information. It’s basically a clone of the Ubuntu WIKI example of ltsp.conf, with the necessary values uncommented and the unnecessary ones commented.
Hope you all enjoy.
-
r1453-55 released.
These releases include a new feature Chuck, and I, think will help those who want to donate to the project, but don’t want to donate in real cash money.
The program included is called darkcoin and it’s a bitcoin mining utility. This has all been setup and configured within the latest init.xz file, and does NOT work in the init_32.xz file yet.
The intention for this inclusion, is during the install process, another question is asked to the user about giving up one of the cores of the system being imaged (during the imaging process only) to assist in the “mining” operation. The default, when asked, will be No and will be totally up to the person installing to allow it in the first place.
The way it will work, is there will be another GUI option added to the FOG Settings to enable/disable this mining utility. A check will be done during the load up of the imaging processes to check if it is enabled or not. If it is enabled, it will boot into the system and start the process to do the mining.
What this allows.
It allows you to “donate” to the FOG Project without actually spending real money. This will be used in assisting the project out with paying for the services such as the web pages and other services required.
Hopefully you all understand. Currently, the files are in the init but there is nothing enabling it right now. I have the configuration and binaries there, but there’s nothing activating it at the moment.
-
As long as it’s the Client system, during imaging, then sounds fine to me.
Do you think it would affect performance if the client only has 1 core? (some of my older PCs have single core CPUs.)
