Latest Development FOG
-
I really need to get testing… The exit issue is a problem on almost all the new Dell boxes… Hopefully soon!
Way to go Tom, it’s great to see things moving. -
Hopefully I’m not reposting a known issue, but I ran into this yesterday on FOG 1.0.1 (Ubuntu 13.04)
[SIZE=3][FONT=verdana][COLOR=#222222]The name format we use to register hosts (via Full Registration) is beyond the character number limit in some cases. FOG attempts to truncate the name when beyond the permitted length. When this happens, it gives a message something to the effect of ‘unable to append co.txt’ - I can get the exact message next time I’m at work if it helps. I assume the truncating is what’s failing, as the registration then halts completely and doesn’t register keypresses, etc. To do anything, you have to shut the machine down, boot to FOG again, but then registration succeeds the second time around - using the original too-long name. I know the ‘smart’ solution is probably to change to a shorter naming scheme, but I was hoping there would be something else that could be done[/COLOR][/FONT][/SIZE]
-
SVN 1778 released to fix a few issues.
First things first, init.xz and init_32.xz are updated to contain the GRUB2 fix from fractal13.
Next, add’s a “fix” for the xz compression to actually happen when buildroot is built.
Next, fixes an issue (hopefully) in wol information where when it accesses the directory, it was trying to redirect the page to /var/www/{html/fog,fog}/wol/management. If this doesn’t work, it will not hurt anything either so no loss or gain, just trying to neaten up errors logged. And, last but certainly not least, uses the path name of the image to delete the files rather than the image name. Sometimes the path is not the same as the image name due to varying reasons.
-
SVN 1780 released.
Fixes an issue with grub mbr generation if the first element found equates to 0. It would try to set the count to -1, but dd can’t create an mbr for a sector that does not exist in the first place.
Fixes the snapin search to group by the snapin names rather than just returning all the found results.
Fixes snapin task creation so if a host has no snapins associated, it’s not going to try to create a snapin tasking. And it won’t try to create one if the deploy job is specifically told to do a Download without snapins task.
-
SVN 1783 released.
Fixes a few more bugs found. Fixes the GRUB data that seems to “just work” now as well.
-
Also a “no touch” updater would cause everyone to be on the “bleeding edge”. If there is a serious error with the latest build then everyone would have the issue and trigger a mass error report from the public. I don’t know if you know what that feels like but it would force the developers to scramble to fix it. Which would cause the developers not to really touch a working product. At least if you have to install each and every time you know your taking that risk in having possible issues.
-
svn 1788 released.
Includes an installer log file for helping troubleshoot issues. This is located at:
/var/log/foginstall.logIf you have issues during install, please post this file or the contents of the file with your posts.
Thank you!
-
I don’t think forcing everyone to be on the latest and get every bug is a good idea…
Tom is great at pushing out updates, but he’ll probably feel a great deal worse with
“grgrhdaslhasdfhlahf MY NETWORK IS DEAD auihwefiaewkjafds… FIX IT NOW, EVEN IF I HAVE NOT PAID FOR IT I DESERVE IT aiwlhflahflkhawfklhlawhflawdfl;ahflhaewfhflkaewhl”going on all day if there is a code mistake.
The installer uses past responses which is ‘good enough’ for those wanting to be bleeding edge providing they have BTSYNC
-
[quote=“VincentJ, post: 28257, member: 8935”]Possibly also consider getting the first warning to let users know they can enter it later rather than telling them they need to edit a file later
Just installed my test suite on the btsync version. luckily means every fog server becomes a btsync peer.
could we have a quick script that can be run without interaction that does updates?[/quote]
If it’s of any help:
[url]http://fogproject.org/forum/threads/automating-fog-0-33b-svn-updates-in-ubuntu-14-04-with-cron-easily-adapted-to-other-linux-distros.10409/#post-26920[/url]Though the part of the script that “auto confirms” the schema system may not work.
-
SVN 1799 released.
The few other released fixed a couple more issues and should fix the FOG Storage Node queued information to limit the number of active tasks running properly. Also, comes, the Trunk version number to the SVN information so you all should know what SVN Revision you’re running on if you’re using the “latest” and greatest of FOG. Add’s a new file for snapcheck.php. While not fully implemented it will hopefully enable us to copy snapins to the host so they can be run after imaging completes without having to download all the files. It’s not called by anything right now, more just a “proof of concept” element.
-
SVN 1800 released.
Sorry about the invalid OSID earlier. I had or where I should’ve had and. This also should correct the task management page turning up blank if registered and set to image from init. It was because the history logging was looking for a username that wasn’t associated. Again, I’m sorry. Now the PendingMAC’s and AdditionalMAC’s fields are objects of the MACAddress class. This should maintain the __toString() function on TaskManagement to work properly. Not that it was broken before, but If the mac couldn’t be found, it would force an error, now all MAC’s should become an object of MACAddress which should help correct this minor issue.
-
SVN 1806 released.
Should allow for sending of multiple NIC MAC Addresses as seen on some systems (wireless nic being assigned net0, main setting net1). Add’s the xfs filesystem to the fog.upload script thanks to ianabc’s patch. Fixes, hopefully, multicast stuff.
-
Just upgraded my production server. Loving the new version. Thanks to all the FOG Development team. Especially u Tom :rolleyes:.
-
1808 released.
Hopefully fixes Multicast for sure??? Pretty please!
-
SVN 1810 released.
The 1808-1810 had quite a few edits.
1808 had, hopefully, the fix for Multicast Groups. 1809 has the Storage Group setting for Images if there is no master node to assign to. 1810 Should, hopefully, fix UNC paths within the inf field display issues.
For the UNC pathing on the inf file, is there a problem other than display that anybody’s aware of?
-
SVN 1816 released.
[b]TL;DR;[/b] Multicast works, should multicast imaging allow two deployment tasks at the same time with the same image?
[b]Long Read, but Good info[/b]
Hopefully I can now put a kibosh on the whole multicast deployment problem we’ve been seeing for the last few days. While it’s not perfected, quite yet, on back-to-back deployments, there is a workaround for this and I hope to have a more permanent fix for this to happen. By back-to-back I mean two separate groups, using the same image, trying to create two separate multicast deployments.Some of the “checking” in place for right now is if a multicast task is found with the same image as a previous task that is in queued (0) state, it will try to attach the second multicast task to that first one. This isn’t right because the previous udp-sender command as probably already been started containing the actual receiver number for the first task, but it doesn’t get closed or regenerated to contain the new clients trying to come in.
My idea to ‘fix’ this may not be liked by all members but it works like this:
In unicast deployments, you can only schedule one task at a time to a host. You can’t schedule an upload, and while that upload task is still active, schedule it to deploy.
I propose a similar solution to Multicast tasks. Seeing as it doesn’t care about hosts, but rather cares about the image, if You have a multicast task with Image ID 1 already scheduled and in ‘active’ state, you won’t be able to create a second multicast task with the same image. This will allow that first task to complete or be cancelled before being able to create the new task.
Why? I know you’re all asking this question. Well, I think this will help solve the problem of what I’m just going to call “conjoining tasks.”
Multicast imaging is used to mass image hosts, typically. This method allows, theoretically, faster imaging to en masse hosts but allowing one task to transmit a task to many hosts. This reduces, theoretically still, server load (especially now that the hosts are doing the decompression) by only generating one stream of data that all hosts that require it collect and process.
This means, you’re actually causing more harm than good trying to re-establish open transmission of an image that is already being worked on if you try to schedule two tasks containing the same image. This could, potentially, cause problems to the image as you would have two processes at different points of the spectrum trying to transmit the data across the same (server side) link.
I propose that we just stop trying to create two multicast tasks if the same image is already in use.
Hopefully you all follow and understand my thought process.
Thank you,
-
SVN 1817 released.
Current git repo of ipxe updated. Means new undionly/ipxe files. Added more “console” support features into them. Hopefully help with the weird “console not found” reported messages we’ve seen from time to time.
-
SVN 1842 released.
With this release comes a new addition, essentially for the location plugin. If the location has the node specified, an option to make it the “tftp” server for the host becomes available as well. THe initial tftp (undionly/default.ipxe) download still happens as it always has, but when it comes time to download the bzImage and init files, it will use the node location to get the info as well, if tftp is enabled for that node.
Hopefully that all makes sense and works as expected.
-
Hi Tom, I hate to put this here but as the old threads are locked… I have an older version of fog that did seem to be working fine. It is a ubuntu server in a VM. I build a new Windows7 x64 ent image with a 60gb drive, also a vm. Made all my changes pulled the image into fog and then deployed it… for some reason its not expanding properly after the image. if you go into my computer it shows a 23.86 GB hard drive that is almost full but if i don into computer management / disk management it shows that
is a 295 GB partition… i am completely lost and i’ve already imaged 50 machines and am a day behind, how can i fix this issue without re-imaging?Ubuntu 13.10
Fog .33b (Not sure how to pull revision number on an installed fog system) -
[quote=“Timelord83, post: 30968, member: 10119”]Hi Tom, I hate to put this here but as the old threads are locked… I have an older version of fog that did seem to be working fine. It is a ubuntu server in a VM. I build a new Windows7 x64 ent image with a 60gb drive, also a vm. Made all my changes pulled the image into fog and then deployed it… for some reason its not expanding properly after the image. if you go into my computer it shows a 23.86 GB hard drive that is almost full but if i don into computer management / disk management it shows that
is a 295 GB partition… i am completely lost and i’ve already imaged 50 machines and am a day behind, how can i fix this issue without re-imaging?Ubuntu 13.10
Fog .33b (Not sure how to pull revision number on an installed fog system)[/quote]Personally I Sysprep, and I let my unattened.xml extend my OS to the end of the partition.
In your case:
Resize a volume
Sometimes, after you’ve create a volume, you’ll need to change its size. Luckily, once you’ve created a volume, you’re not limited to that size. You can either extend or shrink a volume by taking the following steps:Open the Disk Management MMC snap-in.
Right-click on the volume to be extended. Select Extend Volume.
The Extend Volume wizard appears. Click Next.
The Select Disks screen appears. You can choose to extend the volume on the current disk or extend it to another disk.
Click Next.
Click Finish. The volume is extended and maintains the same file system as the original volume.[url]http://technet.microsoft.com/en-us/magazine/dn451252.aspx[/url]
