@oz-agoston said in Need help with new FOG server installation and setup (PXE, image creation):

Unfortunately our bosses wouldn’t want us to use the windows DHCP server for the FOG server to avoid possible network problems.

We have solutions you can use where you don’t or can’t update your primary dhcp server. You don’t necessarily need to setup an isolated network. Depending on your deployment your target computers may need access to AD during deployment, where an isolated network might cause a problem.

In cases where you can’t/don’t want to update your primary dhcp server you can install dnsmasq onto your fog server to provide pxe boot information only to the target computers. It takes about 10 minutes to install dnsmasq using this configuration: https://forums.fogproject.org/topic/12796/installing-dnsmasq-on-your-fog-server

Now just be aware that dnsmasq (as well as dhcp) only works on local vlan/subnet because dnsmaq as well as dhcp uses broadcast messaging. So right there dnsmasq pxe boot information will be localized to the current subnet where the fog server is installed. If you want to pxe boot on another subnet where the FOG server is not, you will need to update your network’s router and add the FOG server’s IP address to the list of dhcp servers in the dhcp-helper/dhcp-relay service. This will allow dnsmasq to hear pxe booting from other subnets. One of the many advantages of dnsmasq running on the FOG server is that if the fog server is off-line no pxe boot information will be sent to the network.

I’m not sure what the problem is at the moment (not enough info yet), but this error has nothing to do with the target computer.

“Unable to locate image store” At this point in the deployment, FOS (the customized linux OS that runs on the target system) maps a local directory back to the FOG server. Once it does this then partclone will take over and move the bits from the fog server to the target computer. So where its failing is FOS can’t reach the FOG server or storage node to map the directory.

First thing I would do is look on the fog server console see if in /images/dev there are directory names that look like MAC addresses. If yes then your image uploads are not completing. Then look in /images directory to see if you see directories with names that match the image name you are trying to deploy.

When FOS throws the error unable to locate image store. It will print out a bunch of variables at the end of the error. Those variables are important to debug what went wrong. Take a clear picture of the error with a mobile phone and post it here. Lets match up the variables to what fog thinks its doing.

@mbghost said in Unable to Get IP Address After PXE Menu on Physical PC (FOG Project on ESXi):

ESXi server → Cisco Switch → Client.

So just to be clear pxe boot the vm on esxi works no prob, but physical host does not.

Lets test this, on the target computer, put one of those cheap unmanaged switches (like the $20 monoprice ones) between the pxe booting computer and the building network switch. Now try to pxe boot. If it works then get with your networking group and make sure the switch ports are configured for portfast, because its spanning tree causing you some troubles. Understand this is an educated guess based on what you’ve posted.

Just for some background on this, standard spanning tree takes 27 seconds to start forwarding traffic. FOS Linux boots in under 15 seconds, so its already given up trying to get an IP address by the time spanning tree starts forwarding data.

The reason why I asked about he proxy server is I ran into the same problem, documented here: https://forums.fogproject.org/topic/6062/svn-5221-failing-to-install-on-fog-server-using-proxy-server

The line you added to wgetrc may or may not work [no_proxy=localhost,127.0.0.0/8,192.168.39.243]. I ended up exporting those statements in bashrc. It may not matter where the command is put.

This is what I put at the end of the bashrc file.
export http_proxy=http://192.168.1.110:3128
export https_proxy=http://192.168.1.110:3128
export ftp_proxy=http://192.168.1.110:3128
export no_proxy=“192.168.1.88”

The issue (not really a problem, just the way it works) is the install scripts uses wget to connect back to the IP address of the FOG server to dump the database data. wget gets a little confused and tries to contact the proxy server to contact the FOG server. At least in my environment this fails causing the backup to fail.

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.

@melvinpaz Can I ask you to update to the latest 1.4.0RCx release? There were several disk issues resolved in 1.4.0RC1. The developers are getting ready to release 1.4.0 (stable) very soon. I’m sure they would want to ensure your issue is resolved before the next stable release is made.

Here is an update on this issue for those that may find the same issue.

I added the following lines to the /etc/bashrc profile script at the very bottom.

export http_proxy=http://<proxy_ip>:<proxy_port>
export https_proxy=http://<proxy_ip>:<proxy_port>

saved the file then logged out and back in. After I did that the installer script downloaded the FOGService.msi file without error and the kernel and init.xz files existed when the installer was done.

Just to restate the issue, if you have your FOG server behind a proxy server you must update the bashrc file with your proxy server settings AND wgetrc with the proxy server settings, because both commands are used to download files in FOG.

Looking in the code this is what I see for the replicator. It uses lftp to move the files.

"lftp -e 'set ftp:list-options -a;set net:max-retries 10;set net:timeout 30; ".$limit[$i]." mirror -c -R --ignore-time ".$includeFile[$i]." -vvv --exclude 'dev/' --exclude 'ssl/' --exclude 'CA/' --delete-first ".$myItem[$i].' '.$remItem[$i]."; exit' -u ".$username[$i].','.$password[$i].' '.$ip[$i]."

The proper limit parameter for lftp is this: net:limit-rate 0:512000 where the first number is the download rate and the second number is the upload rate (in Kb/s).

Looking a bit deeper into the code I see this:

if ($limitmain > 0) $limitset = "set net:limit-total-rate 0:$limitmain;";
if ($limitsend > 0) $limitset .= "set net:limit-rate 0:$limitsend;";
$limit[] = $limitset;

I’m questioning the extra period in the second line and the format just seems a bit off.

Why do you need this you may ask?

I can think of two/three situations where you may not be possible to PXE boot computers into the FOG PXE menu.

1. The computer is so old or has a really broken PXE boot loader
2. Some third party manages your DHCP server or the DHCP server you use doesn’t have the ability to set dhcp options 66 and 67
3. Your build in network device (or USB dongle) doesn’t support PXE booting.

The process steps are not hard at all. You will need to acquire these things.

1. A 2GB (min) flash drive
2. A pxe boot image from https://rom-o-matic.eu/
3. Win32 Disk Imager from sourceforge http://sourceforge.net/projects/win32diskimager/

I do have to add this caveat, in that the rom-o-matic servers include the most of the common network drivers. They may not have every possible driver built into this kernel. If you know how to build kernels you may have to download the ipxe source code and build a custom kernel with the specific drivers for your application. In general this method will work for most applications

One time actions for this process

1. Download and install the Win32 Disk Imager.

Image creation Process

1. From a browser access the rom-o-matic web site at https://rom-o-matic.eu/
2. Ensure that “Standard, for most common use” is selected (default)
3. Set the “Choose an output format” to “USB Keychain disk image (.usb)”
4. Set the “Embedded script” to (in the past your script section).
   Be sure to change the ip address of **192.168.1.88** to the actual IP address of your FOG server.

#!ipxe

dhcp
set next-server 192.168.1.88
set filename undionly.kpxe
chain tftp://${next-server}/${filename}

5. Set “Which Revision” to “Master” (default)
6. Press the Proceed button at the bottom of the page. It may take up to 2 minutes to build this kernel depending on how busy the rom-o-matic servers are at the time you submit your request.
7. When your kernel build is done the system should prompt you to download the “ipxe.usb” file. Go ahead and download that file to a known location.

(continued below)

@Warget This should be working!!

You are getting a dhcp address so the network adapter is working, but FOS can’t reach the FOG server. The error message is a bit misleading but I remember this was an issue because of a bad check.

Just as an idea, did you remember to change / update the grub.conf file on the usb flash drive. You needed to give the IP address of the fog server so FOS knows how to find the FOG server. It was in the link I provided before: https://forums.fogproject.org/topic/7727/building-usb-booting-fos-image/4 in the section called: The final steps you MUST complete

Just a contributor here:

We had a similar issue here after a trunk upgrade. The OP needs to check the Apache error log in (at least in the Redhat realm) /var/log/httpd/error_log

The OP can run the <…>/fog/management/ url to generate the blank page then immediately run this command from the linux console.

tail /var/log/httpd/error_log

That should show the OP the error that generated the blank page.

First I’m not a programmer. But I know the dot ( . ) string concatenation and .= may be short hand for “string = string + newstring”. Then that might make the statement accurate.

Right now I can’t think of a way to capture the environment that lftp is running in to see what is actually being set. It may be possible to hack the FOGImageReplicator to insert a few extra log statements to see what is actually being set by logging the variables.

Some systems no longer come with CD/DVD roms, to install Centos 7 on these systems we must transfer the downloaded ISO image to a usb flash (thumb) drive.

1. Download Cento 7 from your favorite mirror
2. Create a bootable Centos 7 image on the USB flash drive. If you are windows centric user, follow the reference link below that uses Win32DiskImager utility. Since I’m using a Zorin (Ubuntu variant) based laptop I’ll just use the dd command.
   ref: http://www.sysadminguide.net/how-to-create-bootable-usb-key-for-centos-7-installation/
3. Insert the flash drive into your linux computer.
   To determine where the flash drive is mounted issue the following command: lsblk
   Your output should look similar to this:

NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0 298.1G  0 disk 
├─sda1   8:1    0 294.3G  0 part /
├─sda2   8:2    0     1K  0 part 
└─sda5   8:5    0   3.8G  0 part [SWAP]
sdb      8:16   1    15G  0 disk 
└─sdb1   8:17   1    15G  0 part /media/johndoe/BEA0-A4EA

4. As you can see from the printout my 16GB flash drive is device sdb and its mounted on /media/johndoe/BEA0-A4EA. Armed with this information, we’ll need to first unmount (not remove from the computer) the flash drive before we use the dd command to transfer the image. To unmount the flash drive issue the following
   umount /media/johndoe/BEA0-A4EA
5. Once the drive has been unmounted I use the dd command to write the iso image to the flash drive. The syntax for dd is dd bs=4M if=CentOS-7-x86_64-DVD-1511.iso of=/dev/sdX where X is the device number of the usb flash drive. Get this right or you could overwrite something you might need later. Using the information from the lsblk command I know my flash drive is /dev/sdb so the proper dd command to write the iso image to my flash drive is: sudo dd bs=4M if=CentOS-7-x86_64-DVD-1511.iso of=/dev/sdb Depending on how fast the flash drive is it may take several minutes to write the iso image to the flash drive. On my laptop this was the output from dd.

1032+1 records in
1032+1 records out
4329570304 bytes (4.3 GB) copied, 521.836 s, 8.3 MB/s

6. Remove and reinsert the flash drive into your computer. Your computer should properly mount this flash drive.
7. Viewing the contents of the flash drive should be successful.
8. Done with the copy, now move the Centos 7 bootable flash drive to the target computer.

I don’t have a clue about Macs, but the error message is a bit misleading. Its parclone that is having an issue and not reporting cleanly to FOG. This generally happens when there is an error in the disk. I know you said you just ran fsck to check the disk. But usually when partclone blows up there is an issue with the disk or its format.

What does top show you? That will tell you what is consuming your clock cycles.

Actually what I think is going on here is that the boot kernel doesn’t have the required driver for the raid card. I’ve seen this in the server realm quite a bit. In this case it would be impossible to include every one off card in the kernel. It would also greatly expand the kernel size to include these random drivers.

If this was more than just a one off situation (thinking the Dell Precision T3400 through the T5600 series with an on motherboard raid card) depending on the number I had to deploy I might build my own kernel (bzImage) that would include the required drivers. But that is a bit beyond the capabilities of most users of FOG. But it would be a real interesting wiki page to go through the process of building a custom kernel.

@ITSolutions I created a new tutorial that requires the reader to create a new ipxe boot kernel to do as you want. It did work in my environment here is a link to the tutorial if you want to give it a try. https://forums.fogproject.org/topic/6400/usb-boot-uefi-client-into-fog-menu-harder-way

You are you usb booting this Mac? You must schedule the job in FOG before you usb boot the target computer.

The error which is a bit cryptic is saying that the target computer has nothing to do so it gives up.

Ok that tells me you only have /Data exported from your FOG server, I understand why the client can’t connect to the /images folder.

For full disclosure this is what I get when I run the following commands.

showmount -e localhost

Export list for localhost:
/images/dev *
/images     *

cat /etc/exports

/images *(ro,sync,no_wdelay,no_subtree_check,insecure_locks,no_root_squash,insecure,fsid=0)
/images/dev *(rw,async,no_wdelay,no_subtree_check,no_root_squash,insecure,fsid=1)

I’m going to recommend that you add the above two lines to your /etc/exports file.

Then run:

exportfs -r

Then run the showmount -e localhost command. This should then show you the exported /images directory.

Once fog is installed it is difficult to change the IP address of the fog server.

I updated the /opt/fog/.fogsettings with the new IP address and then reran the installer script.

The first issue I ran into was the background wouldn’t load for the iPXE menu. This was addressed by updating the fog setting FOG_WEB_HOST to the new IP address.

The second issue I ran into was not being able to connect to the NFS share. This was corrected by updating the default storage node, default member, IP address.

Also I see FOG_TFTP_HOST setting still points to the old IP address

I would be great if the installer script would check these values to see if they were different then update them to reflect the new setting in the .fogsettings file.