Latest FOG 0.33b
-
r1431 released.
YOU ALL CAN LEAVE ME ALONE NOW!
GroupManagementPage now has Service checking. The checkboxes get checked if all hosts have the same services enabled, or if they’re all disabled by default. They are also unchecked if hosts have different services checked from one another within the group.
Hopefully this makes everyone happy!
-
Remember people that if you want the latest, get on the BTsync
You could have changes within 20-30 seconds of them being made.Read only Secret: BAU3NUY3XTKVMHHEZO6C7OH55AN2PCGJV
Have there been any more developments on UEFI?
-
I’ll admit I am drooling a bit for some UEFI love as well. I have started to accept having to strike UEFI support from our department’s three year plan though. FOG alone will solve so many issues for us, that UEFI would be a willing sacrifice.
-
r1433 released.
Moves many database calls to class calls within the files.
HostManagementPage uses many settings from the Host class rather than calling the respective class. It set’s the additional fields properly now.
-
r1434 released.
Just add’s a task additional field that stores a current task.
-
Potential issue found: On the Host Management page, deleting a host does not work. You are firstly taken to a confirmation page, once confirming the deletion you are sent to a blank page. Having navigated back to the hosts list still shows the host.
Using r1434. Downloaded via tarball.
-
r1435 released.
Fixes the host deletion issue described here. Also modifies code a little bit to remove items a little nicer.
-
Thanks Tom. I have tested this functionality and it works as expected. This also fixes an issue in the pxe menu whereby you could not delete a host.
Another potential issue for you, this one has a suitable work around though. If I Register a host through the pxe menu, allow the machine to reboot and load straight back into the pxe screen where it is configuring, I get a sequential list of errors and cannot boot. This only happens when I have allowed the kernel to reboot the system, if I do it manually it is fine. The work around is to just reboot manually.
It may be of note that this is only tested through VM’s in VirtualBox, I have not tried this setup on real hardware as of yet.
I will keep implementing and let you know if I have any more issues
[url=“/_imported_xf_attachments/0/643_Error.png?:”]Error.png[/url]
-
I’ve seen this issue as well, and it only happens on VM’s not on barebox machines from my testing. This seems an issue with the reset/reboot of the NIC. On mine, it seems that the restart doesn’t actually release the DHCP properly. I’m trying to see if this is a VirtualBox bug as I don’t see the same issue on VMWare. I know of the issue, i just don’t know of the fix. Real hardware seems to work perfectly and, from what I can tell, VMWare works fine. VirtualBox seems to be the culprit.
-
Hi Tom,
I have this problem in the inventory of my new computer (Intel NUC) :
[CODE]i8042 not found…[/CODE]
[CODE]
System Manufacturer # SMBIOS implementations newer than version 2.7 are not # fully supported by this version of dmidecode.
System Product # SMBIOS implementations newer than version 2.7 are not # fully supported by this version of dmidecode.
System Version # SMBIOS implementations newer than version 2.7 are not # fully supported by this version of dmidecode.
System Serial Number # SMBIOS implementations newer than version 2.7 are not # fully supported by this version of dmidecode.
System Type Type: Desktop
BIOS Vendor # SMBIOS implementations newer than version 2.7 are not # fully supported by this version of dmidecode. Intel Corp.
BIOS Version # SMBIOS implementations newer than version 2.7 are not # fully supported by this version of dmidecode. WYLPT10H.86A.0025.2014.0303.1008
BIOS Date # SMBIOS implementations newer than version 2.7 are not # fully supported by this version of dmidecode. 03/03/2014
Motherboard Manufacturer # SMBIOS implementations newer than version 2.7 are not # fully supported by this version of dmidecode. Intel Corporation
Motherboard Product Name # SMBIOS implementations newer than version 2.7 are not # fully supported by this version of dmidecode. D54250WYK
Motherboard Version # SMBIOS implementations newer than version 2.7 are not # fully supported by this version of dmidecode. H13922-303
Motherboard Serial Number # SMBIOS implementations newer than version 2.7 are not # fully supported by this version of dmidecode. GEWY40300HP7
Motherboard Asset Tag # SMBIOS implementations newer than version 2.7 are not # fully supported by this version of dmidecode.
CPU Manufacturer # SMBIOS implementations newer than version 2.7 are not fully supported by this of dmidecode. Intel
Corp.
CPU Version # SMBIOS implementations newer than version 2.7 are not fully supported by this of dmidecode. Intel Core
i5-4250U CPU @ 1.30GHz
CPU Normal Speed Current Speed: 1300 MHz
CPU Max Speed ${cpu_mspeed}
Memory 7.73 GB
Hard Disk Model
Hard Disk Firmware
Hard Disk Serial Number
Chassis Manufacturer # SMBIOS implementations newer than version 2.7 are not # fully supported by this version of dmidecode.
Chassis Version
Chassis Serial # SMBIOS implementations newer than version 2.7 are not # fully supported by this version of dmidecode.
Chassis Asset # SMBIOS implementations newer than version 2.7 are not # fully supported by this version of dmidecode.
[/CODE] -
Okay.
What does this mean?
-
I’m already running the latest version of dmidecode in the init files so there’s nothing I can really do at the moment.
I’m sorry.
-
Warp,
If you want you can update to r1436.
I’ve changed the version relationship, though I don’t know how far it will actually work. It’s just a theory.
All,
r1436 released. Just addes a patch for the dmidecode file to change the versioning needs.
-
I concur, it does appear to be a problem in VirtualBox only. The adapter is being kept by the VirtualBox Manager process, which, if you leave running for long enough, will crash and reset. Thank you for looking at this.
I do have another potential issue for you. This one is to do with uploading an image. I have created a new Image on the server, given it a name and OS type (Linux). I then created a task for my Host so that an Image would be taken from the Host (a Debian VM) and uploaded to the server. On PXE boot the task begins, an image is taken, but it is never uploaded to the server (I get the attached error on the host).
[ATTACH=full]644[/ATTACH][ATTACH=full]645[/ATTACH][ATTACH]644[/ATTACH][ATTACH]645[/ATTACH]
[url=“/_imported_xf_attachments/0/644_Error.png?:”]Error.png[/url][url=“/_imported_xf_attachments/0/645_Error.png?:”]Error.png[/url]
-
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.
