Latest FOG 0.33b
-
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?
-
memtest doesn’t really run in an OS layer, so there’s no way to tell the FOG GUI that it is running, or that it’s finished running. So, unless you manually cancel the task, even if you intend for it to reboot into OS, it will just keep telling that system there’s a memtest task to be performed.
-
r1470 released.
Mining is now enabled within the scripts. It will only start the mining operation under three very specific conditions.
- ) Mining is enabled on the GUI.
- ) The system has more than one core.
- ) The system is an x86_64 bit system.
Hopefully people won’t mind enabling this feature.
-
r1471 released.
With this comes the ability to send a tasking and it will perform the tasking to any registered NIC that tries to PXE Boot. Fixes the Additional MACs so they are actually stored.
-
r1472 released.
Fix the hardware display (link from dashboard) so the information display’s properly. The CPU Speed line was showing the microcode and the cache line was showing the CPU Speed. This has been corrected.
