Topics created by george1421

@xutianhong I’m glad you have it working. Tom and I are very skilled with FOG. Since fog is built using many other linux parts we know those parts too. iPXE is a great tool if you want to use it.

FOG also has a great pxe boot menu tool built in. I know some people install FOG just for pxe booting and don’t use FOG for computer imaging purposes.

You may ask a question here, we will help if possible.

@Wayne-Workman the reason our installer shouldn’t support it is because it becomes yet another thing we are “expected” to manage and support. We’ve seen the issues just trying to keep up with Ubuntu. We’ve seen the issues with keeping up with the red hat variants. Mind you this is for the more common architectures of systems.now add in another form of os AND a new set of architecture to try to manage and it becomes even more difficult.

What I will say, people can ask questions and we will try to give as helpful an answer and the best support we can to them for nearly any situation. No I don’t think we should add this device or OS in our core support installation though.

George helped me figure out what I was doing wrong. But what you posted Tom is very valuable.

Great work @george1421!

Thank you, I will look over them; now I need to get some more work done, or my boss will chew me out for chatting 🙂

Best regards,
M. M.

@Tom-Elliott Thank you for your input. I realize that i have made a mistake in the code. I am new to bash and fog in general.

The idea is to have a while loop running until an image has been assigned. Or a sort of pause before it continues. The reason being that this is being done remotely and I would be assigning the correct image to the host. I am not psychically in front of the computer. The hosts users would only select that they want an image to be deployed and not select an image to deploy.

Hope that makes sense.

So what I guess I was looking for and I do realize that this is n the wrong thread is a way inside a while loop to see if an image has been assigned before continuing on with the deployment. BTW I have modified the fog.man.reg to go straight to the fog.download and the end of the registration.

@sudburr To do some of this you will need to become versed in grub menu design. Some can be done in grub. The deploy image function in grub is not so easy, that requires the integration of iPXE menus (which we avoided by creating a usb based tool). You can get pretty close but with static grub menus (as apposed to dynamic iPXE menus when you pxe boot).

Deleting and reinstalling the location plugin resolved this issue. Its possible that I had something wrong with the location settings ( I was testing the windows storage node in this environment before ) or something was wrong with the location plugin and was reset when I reinstalled it.

Marking this solved.

On a side note. The hostinfo.php query page called from inside the FOS client returned the needed kernel parameters. So I think the concept of usb booting info FOS imaging is looking brighter.

@Tom-Elliott Just thinking about the next steps here…

I have to work on a few extra projects for my real job right now, but I’m thinking ahead a little.

In funcs.sh, can we move the code to pickup the kernel parameters and to call hostinfo.php into its own sub function? That we can reuse and call at different points in both the init scripts and via the post install scripts? That way I can reuse that code and have a consistent way of getting the parameters.

I could imagine a sub called getKernelParams() that could be called, and in that sub function if the ( boottype=usb ) then it would call a second function getHostInfo() to pick up the host info (that way too we can call getHostInfo() by its self to pick up the host details from the post install script(s) too (at this time I personally don’t care about the kernel parameters in the post install script, but if I did I could just call the getKernelParams instead). Then of course the /bin/fog script would need to take advantage of these new functions.

a pull request via git.

So, make a github account, fork the fog project, download your fork to your local work space, Make your changes. Commit your changes, push your changes. Then do a pull request with the main repo. The devs will look it over and either merge or not, often with comments when they don’t.

Just a follow up, task scheduling and image capture work as expected. Issue is solved.

Part 1 MDT setup

For this process we use MDT and the lite touch method to create our reference image. As I noted above, I’m not going to discuss any parts of setting MDT up for the lite touch. But I will say that it took me about 3 days to go from never touching MDT to capturing my first reference image with FOG. So its not that hard to learn. I do have to say that our reference image is built on a vSphere virtual machine. We used this method since the vm virtual machine doesn’t require any hardware specific drivers to make the system deploy. All of the MS native drivers work for this host system. Using a virtual machine is the recommended method when creating a clean reference (golden, mother) image or what ever you want to call it. You can create your reference image on real hardware no problem, but its a bit slower. Also using a virtual machine you can create snapshots of your reference system as you develop your golden image. It saves time having to rebuild the image for each tweak in the task sequence. In the beginning I was taking a vm snapshot prior to sysprepping as I was working on the unattend.xml file. It saved a bunch of time.

For Dell hardware this web site will save you a bunch of hunting around for model specific drivers. I recommend you bookmark it since you will use it a few times.
http://en.community.dell.com/techcenter/enterprise-client/w/wiki/2065.dell-command-deploy-driver-packs-for-enterprise-client-os-deployment

Back to MDT. From the website above you will want to download the WinPE 3.x driver cab.
I also recommend that you install winzip or 7-zip on your workstation since we will use one of those to extract the cab file. Its much faster to use 7-zip than the extract command on the cab files, believe me

What you want to do is install the Dell WinPE 3.x driver cab into MDT Out of Box Drivers section. This will install all of Dell boot time drivers so that your reference can boot on any Dell target hardware. This step is not specifically required for building a reference image on a VM. What it does do is preload Dell’s common drivers into your reference image build in case you don’t get your fog post install scripts just right during development your target computer will have at the minimum disk and network access. As I said this part may not be necessary. I loaded them from the beginning of developing the process and it worked. I never did try to remove them to see if the process broke. I found a path that worked reliably and stuck with it.

Now one of the keys to this universal image process is we need to tell our reference image where to look for drivers when new hardware is detected. So one of the last task sequences in the MDT build process updates the following registry key “HKLM\Software\Microsoft\Windows\CurrentVersion\DevicePath” to include a folder path of my choosing. In this example I’m going to place my target specific files in C:\Drivers. Originally I just appended C:\Drivers to the device path until I ran across trying to deploy to a Dell 780. The Optiplex 780 has a sound card that is supported by the native windows driver except for one specific thing. The native windows driver (found in the c:\windows\inf folder) doesn’t support the use of internal speaker. Everything else worked great as long as you connected an external speaker to the 780. But if you use the Dell sound driver the internal speaker worked as it should. So to avoid this type of issue I have windows search the c:\driver folder first then the c:\windows\inf folder. With all 15 models in my fleet, all of them work perfectly searching for drivers in this order.

So back to MDT, that task sequence uses the windows REG.EXE function to update the above mentioned key with this value. “C:\Drivers;%SystemRoot%\inf;” and we force that registry key to be set even if it previously exists. Note: for Win10 this registry key is no longer used. You will need to insert a section into your unattend.xml file that will instruct the installer do the same thing as this registry key

At the end of the MDT build process I have a batch file that runs the sysprep command with the required parameters. The sysprep command might look similar to this: sysprep.exe /quiet /generalize /oobe /shutdown /unattend:C:\Windows\panther\Unattend.xml

So from there once sysprep process completes the virtual machine will shutdown. I then pxe boot the vm into fog and capture the image as you would normally.

You can do Part 1 without using MDT. You will just put windows into audit mode as you install it from DVD. You will have to manually update the registry and install the Dell WinPE 3.0 driver cab, but it is possible to get the results without MDT. We use MDT to automate this entire process so we get the same exact results every time we build the golden image. We go this route so we don’t have to deal with the reseal count or any of that mess. The other part I didn’t add above is that MDT will install all of the windows updates during the reference image build process. So our reference image will have all of the update at the time of image capture. Since its all automated from the image deployment, windows updates, and applications install you just start the build process and walk away. When you come back the image will be ready for sysprep and image capture.

@george1421

For clarity the command Tom provided didn’t return any value, but it did set me on the right path (so to speak).

Well its not as clean as I hoped, but this command will return what I want.
find /ntfs -type d -iname "sysprep"|grep ystem32

For what ever reason sysprep exists in System32 and SysWOW64. Either way the above command will return the proper case regardless of the target OS.

[edit] And this command will find the proper unattend.xml regardless of the case.
find /ntfs -type f -iname "unattend.xml"|grep ystem32
[/edit]

OK my error. There was a timeout value in the fog settings for the graphs and it was defaulted to 1. I updated the value to 60 and that corrected the graph refresh time.

I guess I need to cruse through the fog settings every once and a while to see what’s new. 😩

solving this thread.

@Tom-Elliott I’m currently spinning up a new FOG 1.4.0 server to test multicasting across subnets (and usb FOS booting it now appears). I’ll divert that setup to test FOG with a windows 2012 server setup as a storage node. I don’t have a centos template on this dev box so its going to take me some time to get up to speed. I do have a windows 2012 template so that one shouldn’t take too long.

I would still expect it to take until this evening before I can get to testing with my day job and everything…

@Wayne-Workman the group idea is currently, the host name that matches that of a group name will apply that matching host settings to any host that gets added.

The last group a host is inserted into (the latest group you added a host to) would define the host to have that new groups settings.

It’s basically your addition. Currently it only does this adding when and if a hostname matches the group name.

Btw, when clicking on the “Home” icon (dashboard link), I see the new hosts that needs to approve in a popup small java banner with a hyperlink “here” that directs to the hosts-waiting-for-approval webpage.

I can’t recall what git version I’m running though, will update tommorow.

@george1421

Thanks for the clarification. We’ve been caught with storage problems frequently enough that we know to use a separate disk volume for /images. For Snapins, we defined our processes when Snaps were much less capable than they are now. We use DFS on separate windows servers and leverage Samba as links under DFS on FOG storage Nodes for smaller sites. Our approach allows for easier tweaks to any Snapin by just editing the contents of some folders. No re-uploading to FOG and re-replicating a big ball of a Snapin. The only thing that replicates are the smaller changed files via DFS.

I get the old linux ‘mandate’ to separate everything into it’s own volume, though the guys I’ve worked with didn’t do that at the disk level, but at the partition level (since most had to deal with a storage team and getting one large chunk of disk and partitioning it was easier than explaining things to the storage team). I’m good with the concept, but don’t follow it dogmatically. Instead I consider the use of the server. If the server is an appliance - does one thing for you, as FOG does - then a FOG server than boots Linux but doesn’t do FOG is of no value to the business. In this case, I don’t split volumes for everything. This goes for Windows and Linux.

I haven’t had the problem you describe were the OS won’t boot, plus with VMs, it’s exceptionally easy to mount the VHD and free up space. I find that placing any hard limit on a specific folder (volume, disk, whatever) is an act of fortune-telling that will end up shutting down the app sooner than allowing all folders supporting an app use the space that’s allocated. I monitor everything with XYMON so I get alerts on disk consumption, but even without that, the run-time for the app is longer w/o partitions.

I only partition where there can be rapid growth that necessitates expanding a volume - and the /images folder in FOG is the best example, when uploading is required (server hundred GB in one client possible).

I know my thinking is contrary to what some feel are best practices in Linux, but I’ve been happy with the results… I don’t tend to lose the service the app/service provided because I miss-guessed the space log files need by 100MB.

Just my opinion…

Thanks
Jim

@george1421 said:

I still don’t have a good name for the operating system that runs on the target computer which does the actual work of imaging the target. For this document it will be known as FOS

FOS it shall be named.

@Sebastian-Roth Interesting on the boot stuff for OSX. I think any error would confuse the user beyond the need to use the debug kernel. I’m not saying its a bad thing but if we can avoid the error, the less questions we will have to answer.

It would be interesting to know if the MBR image I created would work on OSX. I think I remember reading somewhere that the disk needs to be GPT.

I can’t remember right now if I tried the grub-mkrescue image on my T43 (32 bit crusty old laptop). I’ll recreate the flash drive based on the your file and see.

As for the dynamic size, I could do that. Good point on predownloading the boot kernel files. I was just being lazy and picked 128MB knowing that was about twice the size I needed of 60MB.