Latest FOG 0.33b
-
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.
-
I am curious what ports you require for the Mining features for those of us with paranoid firewalls. I may take a box that is on its way out and let it spend its last working hours making you money XD .
EDIT: Is there something I can do to force the machine to stay in this mining mode? If not I could always keep it redoing a task lol.
-
If you look in the conf files you can see the login info for their miner.
Then just install your own and use those credentials. -
r1473 released.
Fixes checkboxes on the editing of storage nodes so they’re set based on the value, not always just set.
-
r1474 released.
With this comes two simplistic features. hostLastDeploy column is added to the hosts table to track the last date of deployment. imageLastDeploy column is added to the image table to track the last date of upload. The relevant pages contain information in different formats. On the Host page, the last deployed date shows under the hover title of the Host when hovering over the name to edit. It also displays in the notes field of the actual host when editing a specific host. Image Management has a column that shows the last date of upload. Similarly to Host, it has the last uploaded date in the Title hover of the link to edit an image, and it displays the last uploaded date in the notes of the specific image. Hopefully this will appease people more. They dates will only be updated at the completion of the task. So when Uploading an image, it will change the last deployed date of the image, not the host. When deploying (download task) a host, it will only update the date on the Host field.
I will not be adding an Auto tag, right now, as it requires many changes to how the FOGPage and FOGPageManager classes operate.
