Posts made by george1421

@Tom-Elliott Well you either fixed the issue or really broke it.

Actually watching top I see the http process pop up in the list but never over 0.4% of the CPU. And it is only a single process that is showing up. So unless something else is impacted by this change, it looks like you nailed it.

My intent wasn’t to have you change the official image. I was looking to test to see if it was a positive move or not. This would avoid mucking of something that is working.

But in the back of my head, even for dynamic bandwidth management a 10 second refresh is more that adequate. While its “nice to know” information, a 1 second update cycle is very fast. And what will the tech do with that information if bandwidth was to spike to 100MB/s for 3 seconds. Understand this is just my distorted view, but since this is only FYI info, lets not tax the system too much where it could dedicate those CPU resources to actually pushing the image or managing the client.

This is only pure speculation here. But looking in the http access log, as I posted below this page is being requested every 1 second.

POST /fog/management/index.php?node=home

What would happen if it takes longer than 1 second to render the page, before the next post request comes in? Would increasing this page refresh to 10 seconds have any negative impact? I tried looking for a meta refresh tag in the page but it looks like the page is being refreshed with javascript. I got lost tracing the source of the page refresh. Tom. without digging to deep in your memory, do you know where this page refresh request is coming from so I can change the refresh to 10 seconds to see if that has any negative impacct?

Method #2

This second method involves taking the LiteTouchPE_x86.wim and LiteTouchPE_x64.wim created in the MDT environment and combining them with elements of the WAIK to create a directly bootable MDT litetouch image that can be launch via FOG’s ipxe menu.

1. On your MDT server select your Deployment Share->Update Deployment Share. This will update your litetouch boot image files with the latest settings from your MDT configuration. When the update process completes change to the DeploymentShare\boot folder. There are 2 files we will use for this method of integration. These files are LiteTouchPE_x86.On your MDT server select your Deployment Share->Update Deployment Share. This will update your litetouch boot image files with the latest settings from your MDT configuration. When the update process completes change to the DeploymentShare\boot folder. There are 2 files we will use for this method of integration. These files are LiteTouchPE_x86.wim and LiteTouchPE_x64.wim.
2. Download the Windows Automated Installation Kit (WAIK) for Windows 7 from the following link: http://www.microsoft.com/en-us/download/details.aspx?id=5753
3. Install WAIK on a development system (workstation). You will only need WAIK installed long enough to extract the boot images.
4. Once WAIK is installed Follow this path Start menu->All Programs->Microsoft Windows AIK->Deployment Tools->Command Prompt. Selecting this menu should open a cmd shell. This next step we will create both the 32-bit and the 64-bit versions of the WinPE boot environments. In the command shell key in the following:
   mkdir %temp%\fog\mdtboot
   copype x86 %temp%\fog\mdtboot\x86
   copype amd64 %temp%\fog\mdtboot\x64
5. Download wimboot from this link: http://git.ipxe.org/releases/wimboot/wimboot-latest.zip
6. Extract the wimboot file from the zip file and save the (wimboot) file only in the follow folder: %temp%\winpe\fog
7. Copy LiteTouchPE_x86.wim and LiteTouchPE_x64.wim from the MDT deployment share to the %temp%\fog\mdtboot folder
8. Using 7-zip or similar tool create a zip file of %temp%\fog*.* as mdtfog.zip
9. Move the mdtfog.zip file to the FOG web server’s base directory (either /var/www/html or /var/www depending on the linux distrobution).
10. On the FOG server navigate to the FOG web server’s base directory as indicated in step 7
11. Use the linux unzip program to extract the mdtfog.zip archive to the web server’s base directory using this command: unzip mdtfog.zip (warning if unzip is not installed for your linux distrobution you will need to install it using the following command [rhel based] yum install unzip -y [deb based] sudo apt-get install unzip )
12. From the FOG management GUI select the following Fog Configuration->iPXE New Menu Entry
13. Fill in the following details:
    Menu Item: winpe.BootMDT
    Description: Boot MDT LiteTouch
    Parameters:
    cpuid --ext 29 && set arch x64 || set arch x86
    kernel http://${fog-ip}/wimboot
    initrd http://${fog-ip}/mdtboot/${arch}/ISO/boot/bcd BCD
    initrd http://${fog-ip}/mdtboot/${arch}/ISO/boot/boot.sdi boot.sdi
    initrd -n boot.wim http://${fog-ip}/mdtboot/LiteTouchPE_${arch}.wim boot.wim
    boot
    Menu show with: All Hosts
14. Your configuration should now be set to boot MDT via the wim images from within the FOG PXE menu.

(reserved space)

(reserved space)

(reserved space)

Method #2

(Will fill in details in a bit)

Method #1

The first method involves creating the boot CDROM image in MDT, moving that image to a directory on the FOG server and then creating a customer PXE boot menu in FOG. I’m not going to cover any of the MDT image creation process in this post. At this point of you need to integrate FOG and MDT you should already know how to setup and use MDT.

1. On your MDT server select your Deployment Share->Update Deployment Share. This will update your litetouch boot image files with the latest settings from your MDT configuration. When the update process completes change to the DeploymentShare\boot folder. There are 2 files we will use for this method of integration. These files are LiteTouchPE_x86.iso and LiteTouchPE_x64.iso.
2. We need to prepare the FOG server by creating a location to save these ISO image so they are accessible by the FOG web server. Depending on the version of linux you are using we will need to create a directory in /var/www/html (or if the /var/www/html directory does not exist then we will use /var/www). This path is to the FOG web server’s root or base directory. We will create a folder called isoimg (ISO Images) for this method. Use the following command md /var/www/html/isoimg or md /var/www/isoimg depending on your linux distribution.
3. Move the ISO files we identified in step 1 to /var/www/html/isoimg or /var/www/isoimg depending on your linux distribution (for the rest of this post I’ll use /var/www/html as the web server’s root directory)
4. Change to the web servers root directory with cd /var/www/html
5. Change the owner of the isoimg to user fog and group fog with this command chown -R fog.fog isoimg
6. Ensure that both iso images are in the isoimg folder and are owned by the fog user.
7. From the FOG management GUI select the following Fog Configuration->iPXE New Menu Entry
8. Fill in the following details:
   Menu Item: mdtlti.x86
   Description: MDT LiteTouch x86 Boot
   Parameters:
   initrd http://${fog-ip}/isoimg/LiteTouchPE_x86.iso
   chain memdisk iso raw
   Menu show with: All Hosts
9. From the FOG management GUI select the following Fog Configuration->iPXE New Menu Entry
10. Fill in the following details:
    Menu Item: mdtlti.x64
    Description: MDT LiteTouch x64 Boot
    Parameters:
    initrd http://${fog-ip}/isoimg/LiteTouchPE_x64.iso
    chain memdisk iso raw
    Menu show with: All Hosts
11. Your configuration should now be set to boot the MDT ISO images from within the FOG PXE menu.

Be aware with this method you will get the MDT CDROM prompt To Boot press any key (as you would if you booted via a real cdrom)

There is no real difference. There are 3 threads running 8% cpu ea. But now I see one thread spike to 11% ever few seconds. Strange indeed.

@jonathanh Excellent. Glad to help!

Marking this issue resolved (or not, no option to…)

@FlowLive Hey that’s great to hear that someone can repeat my madness…

@Wayne-Workman Le me see if I can clean it up a bit. I need to see if I can integrate what @Sebastian-Roth noted in this thread about using a logical to represent the fog server IP. I think I can make it work.

@Wayne-Workman I agree. I would expect to see the developers put a feature hold in place soon until 1.3.0 is finalized. There is already many new features in this build to mention.

Just be aware that because the hard drive has data on it today, doesn’t imply it doesn’t have a broken (soft) sector. Since all but for systems imaged OK, it probably safe to say that your image is in good shape. Then you have to ask what is different with these 4 systems. It is either bios version, bios settings or something physical. Since the systems are 4 years old, I’m suspecting the hard drive, but that is only a guess.

Since you are using bios and not uefi the 1.2.0 stable version will and does work fine. If you were using uefi, I would have recommended that you upgrade to a pre1.3.0 release. But you should be good with 1.2.0.

@jonathanh Lets start with the basics.

What version of fog are you using? (1.2.0 or a SVN trunk pre 1.3.0 release)
Are you trying to restore to a UEFI system or is this a bios system?
The 990s are 4 years old (guess) have you tried replacing the hard drive with a known good drive? (I have seen a hard drive with a bad sector stop the download early)

@FlareImp Just be aware, it is more than just sourceforge.net. (If I wasn’t clear in my previous posts. You need access to a bunch of sites for your OS, so it would be easier to white list the fog server IP address instead of the remote sites)

@FlowLive I know it works when you call the boot.wim boot.wim. In theory it should work that way too, because you are using a logical name (boot.wim) to the physical name mapping.

Just be aware there are a bunch of other files in that ISO directory structure you need. That is why I created the tar file. I’m sorry I didn’t think about it being blocked across the pond. But if you have WAIK then you have everything I have.

Let us know how it goes (good or bad [I expect good things only]).

@FlowLive Sorry I got tied up in meetings this AM.

You want to copy that tar file to where your web root is. That is either /var/www or /var/www/html depending on your distribution. In the case of this tar file it creates an upper case folder called ISO when you run the tar -zxf command to extract the file.

When you get done, there should be wimboot in the http servers root directory and a folder called ISO. The LiteTouchPE_x86.wim comes from MDT and it needs to be copied into the ISO folder as boot.wim. That file does not go into the boot folder it self just into the /ISO folder as I defined in the option settings.

Unfortunately this option is not available yet. I had a similar request a while ago with a bit of a twist.

I requested to have different transfer rates based on time of day. That way we could throttle the bandwidth used during busy times and then increase the bandwidth used for replication when the network was quiet.

What we ended up doing (which fits with your request) was to setup a cron job to start the replicator service at 6pm local time and then a second cron job stop it at 6am local time. You just have to be aware that newly captured images and snapins won’t appear on the remote FOG nodes until the next day using this process.

It would be nice if it was integrated into the GUI, and it might be in a future release. But for now the cron method does work.

@bacelo said:

Ok , Yes the DHCP is not controlled by the fog server it is the network configuration it my be a router I am not sure. I do know that the DHCP server that hey are using in as it is in the Wiki fog page as it is for the cisco setup. Know sould I tell them to change the 10.1.8.254 to 10.1.8.1 will this help??

No what they have is fine, as long as you can set the options 66 and 67 for your 10.1.8.x scope to point to your FOG server and the boot file undionly.kxpe on that dhcp server. That is what’s missing here. That is why we are trying to figure out what 10.1.8.254 is.