Latest FOG 0.33b
-
r1243 released.
If you’re registering a host, and try to do imaging, it will require you to login using a FOG username and password just like quick image requires.
-
r1244 released.
Registration part works properly now (no more three times having to type proper username and password.) Task gets associated with the host that signs in.
-
r1245 released.
User name with quick image is associated with tasking as well now.
Thank you,
-
r1246 released.
Fixes an issue with libstdc++.so.6 reporting it’s not an elf file. This, i believe, was due to adding kexec within the init.gz system. kexec still exists, but this should fix the error and actually work as expected.
Thank you,
-
r1247 released.
User Login reports is the change here. You can now search by hostname or by username. If you try both at the same time, it will fail for now. Trying to implement finding a specific user on a specific host which is why it fails. The elements are sort of there, just not implemented yet. Just be cognizant of that.
Thank you,
-
r1249 released.
Fixes an issue on the showVal for the PIGZ Slider bar. You should now see the values as you slide the bar left or right.
r1248 was released as well. I think that actually fixed the “User” and “Host” name searching so both work. 1247 they worked, but User search didn’t return any results.
-
r1250 released.
Fixes an issue with “all snapins” if you had multiple snapins associated and killed one of the snapins in the task, it would destroy the entire task and remove all snapins. Should fix the service/Post_{Stage{2,3},Wipe}.php files so their not trying to remove a non-existent TFTP File. Should also properly log the tasks so we don’t keep getting erroneous values in the imaging logs complete/start times. Should also fix the issue and close out the task properly so we don’t complete the job and have a screen spitting back at us “No active task found for BLAHBLAHBLAH”
I know it’s a lot, but it’s these smaller bugs/issues that I’m working to stabilize. Thank you,
-
r1251 and r1252 released.
r1251 fixes an issue with the Snapin Deployments of jobs other than specified snapins.
r1252 adds, hopefully, performance tweaks on the nfs stuff. Tried implementing to the server side in r1252, but it doesn’t like it so they’ve all been moved to client side in the init.gz.
Thank you,
-
Hopefully the NFS updates work for everyone
If you have before and after numbers for speed that would be brilliant.
More ideas incoming…
-
[quote=“Tom Elliott, post: 21338, member: 7271”]MAC’s are supported as I’ve added the binaries to the init.gz, though I think this will have to be manual for the time being. I’ll have to add the MAC os to the OS Listing and have it translated to allow for hfs imaging.[/quote]
Tom, just out of curiosity, how far out do you think Mac imaging ability is in the priority list? We’d love to be able to ditch DeployStudio and move entirely to FOG. I know there are other priorities, I’m just curious
-
Would be great if that could be added. Tom has been on IRC for the past few days. Do you have an equivalent for the client to put in the hostname etc for MAC OS?
-
Personally, I’d be happy to just have the basic PXE/iPXE booting and imaging capability for now. For our school’s needs, we could simply use a script for the hostname, etc. The client would still be nice to have though. I tried booting a Mac after the recent move to iPXE, but no luck
-
[quote=“ArchFan, post: 23419, member: 19266”]Tom, just out of curiosity, how far out do you think Mac imaging ability is in the priority list? We’d love to be able to ditch DeployStudio and move entirely to FOG. I know there are other priorities, I’m just curious[/quote]
As I don’t have any Mac’s in my possession, it will likely be a little while, unless you can give what the output of the command: [code]blkid -po udev <partitionnumber>[/code] for each of the partitions on the system (especially a freshly installed system) it’ll probably be a little bit.
While I have made sure to have the partclone.hfsp binary available, and also included the hfs file system support in the kernel, I don’t know what to check for to get the MPS/MPA imaging types to use the proper binary.
-
r1253 released.
Redhat doesn’t like the php-json information so this had to be removed. Sorry about the issue before.
-
Once again Tom, thanks for all your help.
I was testing the snapin issues I was having on the latest version (1252) this morning thought I would share my results.
-
When I deploy an image on a computer it creates the snapin task as well. But when I tried to image the computer and see if everything worked I got the message in iPXE: fog/kernel/bzimage… No such file or directory ([url]http://ipxe.org/2d0c613b[/url])
-
When I tried to register a new computer the menu came up, selected full registration. Then it went to blank screen with blinking cursor.
-
I no longer get an error message when selecting a group to deploy all snapins but they only show in Active task and don’t actually deploy. Screenshots attached.
-
When using group to deploy single snapin I didn’t have a choice on which snapin. It also does not show anything in the snapin task.
-
When deploying all snapins on a single computer it would show in both Active task and Snapin task but I waited about a hour and it didn’t deploy.
-
When deploying all snapins to a second computer it would remove the Snapin task from the first computer. Screenshots attached.
-
When deploying a single snapin to a computer it shows in both Active and Snapin tasks. One deployed right away then tried another it sat there for over a hour with out deploying.
-
When deploying a single snapin to a second computer it states that the Snapin is already setup for tasking. Screenshot included.
Also when trying to created a group from the group management page I got the following errors. It did create the group.
Warning: Invalid argument supplied for foreach() in /var/www/fog/lib/pages/GroupManagementPage.class.php on line 239
Fatal error: Call to a member function get() on a non-object in /var/www/fog/lib/pages/GroupManagementPage.class.php on line 252[url=“/_imported_xf_attachments/0/558_snapins.zip?:”]snapins.zip[/url]
-
-
My guess is some of the problems you’re reporting (not specific to snapins) are related to the fog/images/init.gz fog/kernel/bzImage you’re reporting.
1.) The no such file or directory issue: fog/kernel/bzImage fog/images/init.gz etc… are because I modified the kernel and image stuff to obtain from the GUI which auto sets based on the values in config.php when you FIRST install fog. I fixed the “fresh” install so all should work properly.
If you already had it installed and performed an update it wouldn’t have changed your database values. So to fix, go to FOG Configuration Page->FOG Settings and change the fog/memtest/memtest, fog/kernel/bzImage, and fog/images/init.gz to memtest, bzImage, init.gz respectively and all should work properly for you.
2.) Probably related to Item number one.
3.) Will look into that, I only fixed the Snapin issues on the Host side. While the Host side still creates the “image” package, I probably missed something and will look into that.
4.) Haven’t added that component yet. Just trying to get the “individual” stuff working absolutely before making the rest of the changes. The other issue I foresee with it is that detecting which snapins are equally associated across the group can be painful. So have to try to figure out the stats on that and how to get them working across the board.
5.) Snapins are a fickle little thing. You actually have to log in to the system for the snapin to truly deploy as it requires user rights to install.
6.) Understood, I’ll take a look at that today when I get home.
7.) What do you mean one deployed right away, while the other just sat there? You mean you setup two systems to deploy a single snapin and one deployed right away, while the other just sat there? Was the one that deployed “right away” logged in and the other no user logged in?
8.) Probably the method of checking isn’t verifying the host. Will look into when I get home.
The last item’s I’ll take a look into as well.
Warning: Invalid argument supplied for foreach() in /var/www/fog/lib/pages/GroupManagementPage.class.php on line 239
Fatal error: Call to a member function get() on a non-object in /var/www/fog/lib/pages/GroupManagementPage.class.php on line 252 -
as further info, I’m also getting the same 2 error messages when trying to just about anything to a newly created (empty) group, on r1249.
PHP Warning: Invalid argument supplied for foreach() in /var/www/fog/lib/pages/GroupManagementPage.class.php on line 239, referer: [url]http://localhost/fog/management/index.php?node=group&sub=delete&groupid=1[/url]
PHP Fatal error: Call to a member function get() on a non-object in /var/www/fog/lib/pages/GroupManagementPage.class.php on line 252, referer: [url]http://localhost/fog/management/index.php?node=group&sub=delete&groupid=1[/url]Rgds
-
[quote=“Tom Elliott, post: 23476, member: 7271”]
7.) What do you mean one deployed right away, while the other just sat there? You mean you setup two systems to deploy a single snapin and one deployed right away, while the other just sat there? Was the one that deployed “right away” logged in and the other no user logged in?
[/quote]I see what you are saying about a user being logged in. And yes two separate computers, same plugin, one deployed right away the other didn’t. I believe that there was a user logged in at the time that I tried to deploy the snapin. There was at the beginning of my testing. When I check the log on the computer itself it shows that a user was logged on when I initially set it up. That user logged out about 20 min after that then another user logged in for about a hour.
-
Fixed the deploy issue where it was overwriting another set tasking.
-
Fixed the group, it never had the associations. Haven’t fixed it to find the matching associations on the hosts, but working on it.
