Latest FOG 0.33b
-
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.
-
[quote=“Tom Elliott, post: 25811, member: 7271”]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.[/quote]
Thanks for your work on this, I really appreciate the imageLastDeploy this will help me keep track of WHICH virtual version of my image I have uploaded (instead of having to create separate image stores due to uncertainty). I’m sure I will enjoy the hostLastDeploy so I can tell when I updated the image on the machine last too
-
r1475 released.
Fixes the image size information so it should work properly now especially on multi partition images. Adds the image size and the on server file sizes to the list view. Thanks.
-
r1477 released last night.
Sorry about not updating.
Basically, just some minor changes. There’s now Date checking involved for the deployed/uploaded dates in the image and host pages. If it’s not a valid date (e.g. 0000-00-00 00:00:00) it will report as no data. Cleaned up the columns in the ImageManagementPage so things display a little bit nicer. Hopefully this works for everybody.
-
r1478 released.
Add’s the FOG Client/Prep link to the footer of the page so it’s always accessible.
-
r1479 released.
Add’s deploy date column to Host page.
-
Tom, I just got my v0.33beta FOG server vm back up and updated. I see the new columns we spoke about for the images (image size etc) Thanks!
I am having an problem getting an imaging task to start.
The issue I am seeing is that when I submit the imaging task, no file gets created in the /tftpboot/pxelinux.cfg directory specific to this host, so it just keeps rebooting due to the imaging task never actually starting, but the task being active in the db.
I checked permissions on the /tftpboot dir and the /tftpboot/pxelinux.cfg dir and both are 755 fog:root
Apache server runs as apache, so I changed the ownership to the apache user and re-tested. Still, no file is created for the host in pxelinux.cfg directory.
-
I’m going to guess that you updated from 0.32 to 0.33?
Did you adjust the options 66/67 so that it points at the undionly.kpxe file?
The /tftpboot/pxelinux.cfg folder is not used in 0.33 anymore. Tasks are generated/checked directly from the database.
I’ll find the post with the changes needed to the FOG settings page so things will work properly for you.
EDIT: Link for what FOG Settings need updating if upgrading from 0.32 to 0.33:
[url]http://fogproject.org/forum/threads/fog-wont-load-past-kernal_thread_helper-0x6-0x10.10319/#post-25466[/url]Did you clear the original tasks table so as not to cause issues with DEBUG Messages?
From mysql command in the fog database:
[code]truncate table tasks;[/code] -
[quote=“Tom Elliott, post: 25885, member: 7271”]I’m going to guess that you updated from 0.32 to 0.33?
Did you adjust the options 66/67 so that it points at the undionly.kpxe file?
The /tftpboot/pxelinux.cfg folder is not used in 0.33 anymore. Tasks are generated/checked directly from the database.
I’ll find the post with the changes needed to the FOG settings page so things will work properly for you.
Did you clear the original tasks table so as not to cause issues with DEBUG Messages?
From mysql command in the fog database:
[code]truncate table tasks;[/code][/quote]<facepalm>
Of course I didn’t follow any of the on-screen instructions when I ran the install.
I saw the dhcp options message and thought to myself “yeah, I already set up my dhcp server next-server option… I’m all set…”
Sorry for the static!
Making modifications now.
-
Ok… I am new to iPXE and my first interaction does not appear to be a positive one.
My virtual test machine gets the undionly.kpxe from the tftp server, file prints out a few lines, and then hangs.
See image:
[ATTACH=full]672[/ATTACH]
If it matters/helps, my virtual machine is on a proxmox 3.1 server - so the VM is a qemu VM with a virtualized Intel e1000 NIC
[url=“/_imported_xf_attachments/0/672_FOG-iPXE-20140423.png?:”]FOG-iPXE-20140423.png[/url]
-
OK, I have determined that this does appear to be some type of incompatibility with a Proxmox qemu VM.
My laptop successfully iPXE booted into the new FOG menu with a 400 second countdown to HD boot. Which it then wanted to boot from SAN (which does not exist)
I see in : [url]http://192.168.254.9/fog/service/ipxe/boot.php##params[/url]
that the (default) local boot is defined as:
:fog.local
sanboot --no-describe --drive 0x80 || goto MENUI alse see (in the web admin interface) where to set the default timeout, but I do not see where to change the sanboot to /dev/sda1 (or whatever that option would need to be)
I would be happy to offer any additional information on my proxmox VM system to help in that regard.
Also, I tried the virtuo and realteck NICs in the VM with no changes to iPXE hanging. Any thoughts on the VM being 64bit vs 32 bit?
Thanks!
