Latest FOG 0.33b
-
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.)
-
I’m probably going to add checking for the number of cores available. As long as there’s more than one, it will work, otherwise leave it alone as one core could potentially cause performance issues.
-
r1457 released.
Fixes a bug in the fog settings and the capone plugin specifically. May need to delete the plugin and readd it, but the plugin stuff will work properly now.
-
r1458 released.
Adds information statement to UserManagementPage about the checkbox. Fixes an issue in the mkdir function of FOGFTP. Updates the bzImage files to 3.14.1.
-
r1459 and 1460 released.
Fixes an issue of multiple MACs sent for the services, if the second mac didn’t exist it was returning as if there were multiple hosts. This is now corrected for. 1460 just sent an invalid host if it wasn’t found in the first place so things still work properly. -
r1461 released.
Fixes an issue of groups being sent.
Also adds the Group tags if List view is defaulted view.
-
r1462 released.
Fixes the search to render properly as well.
-
I re-installed fog today, but I have run into an issue. I had exported the host before uninstalling and when I try to import them back it gives me an error that a Host with this MAC Address already exists. I checked the database and it was empty. I performed a full registration on one of the host that was in the list and it was successful. I tried the import again thinking it might need one in before but it still didn’t work.
-
I believe I found and fixed the issue.
r1467 released should correct this for you.
-
r1468 released.
Fixes the Mobile page host tab so search is there whether or not search is selected as the default view. Fixes an issue on the Hosts where the Group Processing action-box gets displayed on all of the tabs.
-
r1469 released.
Fix so memtest taskings actually operate. You will have to remember to cancel the tasking from FOG or your system will continuously boot into memtest.
-
[quote=“Tom Elliott, post: 25744, member: 7271”]r1469 released.
Fix so memtest taskings actually operate. You will have to remember to cancel the tasking from FOG or your system will continuously boot into memtest.[/quote]
What causes it to continuously run?
