Latest Development FOG
-
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]
-
Hi, not sure if this is good place, but I was just looking at the new FOG and found this - shouldn’t there be “?>” at the end of service/FOGImageReplicator/FOGImageReplicator (as the other files in the service dir have it)?
-
It’s not needed.
The “trailing” ?> is not a necessary element.
-
Quite a few rev’s have gone by, but if you’re running you all know it.
SVN 1905 is out.
With this comes many fixes and some testing/implementation for an Access Control system.
Hopefully you all enjoy.
While I’m aware it’s not fully functional right now, the intent is to have an access control system that is, for all purposes, as simple as a plugin. You can enable/disable as needed. When enabled, you have control over different restrictive actions. It’s just in proof of concept and building ideas, but hopefully we’ll see more on this in the near future.
Thank you,
-
Access Control system. Wooooohooooo
-
gone will be the days of temps/trainees uploading images when they should be downloading images…
… that was a nice day to come in to… “what’s happened to all the images???” -
[quote=“Timelord83, post: 30968, member: 10119”] 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?[/quote]This may be a little late but if you prefer a method that doesn’t involve manually extending partitions on each computer I recommend using a script and running diskpart with the /s switch to call a text file containing the following:
select disk 0
select partition ([I]Partitionnumber)[/I]
extendJust replace [I]partitionnumber[/I] with the correct number and run this on each and you should be all set.
-
SVN 1973 released.
With this comes functional postdownloadscripts within /images directory.
What this file does:
Just for documentative purposes.
It is a sh script with means it must start with:
[code]#!/bin/sh[/code]You place all the scripts you need to run after imaging is complete.
The way you call these scripts is by “sourcing” to them so they run in the current shell. So if you installed in earlier revisions the documentation may be out of date.
The Calls to the file would work in:
[code]. ${postdownpath}scriptname[/code]Notice the period and space before the ${postdownpath} is called.
${postdownpath} is the literal name, don’t replace with your path unless you know exactly what you’re doing.
If you have folders within the ${postdownpath} (which is set to /images/postdownloadscripts) you simply start the scriptname with the folder and forward slashes as needed. For example:
. ${postdownpath}mycustomfolder/mycustomscriptnameThat should do it.
-
SVN 1991 released.
Many more changes. Namely for Image and ImageManagementPage.
Installer fixes where if you’re on a server but use a different sql server, you can store the server IP in the .fogsettings file under snmysqlhost as is done with nodes.
Upgrades from SVN will no longer request if you’ve set the password at install as it should be stored in the .fogsettings file as well. As it now works properly, you don’t need to verify every single time, just on the initial install. It will still ask you to check for schema update.
Image ON SERVER is now received by FTP. So if the image exists and you know it does, it will not fail out of the page or report ls errors in the error log. It will just not display the proper size. This can also serve as a means to let you know if the username and password are correct for the ftp side of things. I’ve also fixed it so it will display the page even if the node is not correct or not within a group.
-
SVN 1993 fixes the broken hwinfo information.
SVN 1992 just hopes for better session handling.
-
1999 released.
Adds the hfsp parameter to the init. So if you format a disk in hfsp it can now image this. I don’t know if it will actually work, but it’s there just in case.
Fixes FOG Client page if you’re not logged in.
-
SVN 2021 released.
With this comes more additions to hopeful resizing of linux partitions. I’ve not fixed the partition table’s yet, but the resizable parts themselves are resized and properly set. They’re also restored and expanded properly. Again this is only on resizable partitions (ext[234]). The extended location is still at it’s original location, so for that I’m sorry. It’s still, very much, a work in progress.
-
Have you had any reports of looping boots after tasks? I’ve seen this a couple of times on new PCs we’ve switched to our new fog server today.
I will try to update to the latest and try again but got a ton of other things to do since it’s nearly the end of the school year.
-
[quote=“VincentJ, post: 32482, member: 8935”]Have you had any reports of looping boots after tasks? I’ve seen this a couple of times on new PCs we’ve switched to our new fog server today.
I will try to update to the latest and try again but got a ton of other things to do since it’s nearly the end of the school year.[/quote]
Going on a limb here, you’re testing via VM or physical systems?
-
I have seen it on virtualbox VMs, but today it was on new i5 systems. Same model system works perfectly on other PCs but some seem to boot loop.
I wasn’t doing the new PC installs, but the guy who was wouldn’t know how to muck things up too much so for the moment we’ve switched back while I troubleshoot.
-
SVN 2033 released.
This is a huge change in Linux/Windows Resizable Imaging techniques all thanks to Fractal13 of the forums. If you can give him many likes as I couldn’t have done what has now been accomplished.
First I’d like to note (and feel free to add if needed fractal), UUID’s of the swap partition are now stored and reset properly with this. Resizable imaging works in the truest form that it “resizes” all partitions including extended partitions. Uploads no longer store the swap partition on linux disks either, just the UUID is stored. This should help minimize the Code needed. There are some fixed size partitions, but that shouldn’t be a worry as I highly doubt anyone’s still got 8 GB hard drives in any of their systems anymore.
Second I’m in the process of testing the Windows Only systems. However Fractal has tested this with Multiboot systems as well. So Multiboot systems are also able to be resized as well. These have not been tested or even known to work with GPT disks. So please be cognizant of that as GPT Resizable Multiboot or plain-jane Linux systems is probably not going to work.
