Part 3 (Final)

Today I went in and registered one of my VMs on the dev fog server. I ran through the full registration and allocated this host to the “winsn” location.

I pxe booted the vm and saw that it initially connected to the dev fog server and then the dev fog server redirected the client to pull the bzImage and init.xz from the Windows storage node (!!getting excited level 20% !!).

The vm downloaded both bzImage and the init from the windows storage node cleanly (excitement level 50%).

I saw the FOS kernel boot and started the initial prep work for imaging (excitement level 80%).

Partclone did its prep work and started downloading the image (excitement level 90%). I quickly checked the windows storage node and ran netstat -an and this was the the line I was searching for

TCP    192.168.1.205:2049     192.168.1.6:747      ESTABLISHED

This told me that the windows storage node was communicating with an external (dhcp) device over the NFS protocol!!

Imaging completed and the workstation started booting windows (time for a smoke and a beer) [full disclosure I don’t smoke so I’ll just take two beers instead].

So it IS possible to setup a FOG / MS Windows Storage node. In the end I’m still not seeing the value in it, but it IS DOABLE.

!!Success!! and the end of this POC project…

@StefanTS Hacking the FOG code is not recommended. Doing so will trouble you for each upgrade that will come. The update cycle is much faster than between 0.32 and 1.20.

With that said, what are you doing here? I read your post two different ways.

1. You want to PXE boot certain clients with a custom boot image via the fog menu. This boot image works when booting from a CDROM.
2. You have an exam application supplied via CDROM ISO image and you want to deploy that to 30-60 computers.

If you have an existing ipxe settings files that information will help. The trunk version of FOG has many new features not available in the 1.2.0 core image. Just a word of warning on the trunk version (pre 1.3.0), this platform still has a few bugs in it, but it is very usable. The bugs are stamped out by the devs as soon as they are reported. If you want to test the 1.2.0 SVN trunk I would do this on a new VM/hardware so you don’t run the risk shutting down your production environment.

Anyway the SVN trunk allows you to add custom pxe menu items from within the FOG GUI.

[Edit] Sorry I just saw your post with the ipxe settings. Let me see if I can do the same thing with my FOG test VM. [/Edit]

@Jbob

Actually I share the same concerns about disabling selinux and the firewall. But this seems to be the standard practice for installing FOG so I didn’t want to push a different agenda. I also consider that FOG appears to be targeting the smaller SMB realm from a security stance and most have FOG installed inside a properly protected network so that does mitigate some of the risks.

Just thinking out loud, if we have a list of all services used for FOG then constructing firwall rules shouldn’t be difficult at all. The application of the rules may be difficult since each linux distro handles the iptables rules a bit differently.

The selinux part will be a bit harder since FOG is writing to files all over the place. We would have to get the selinux tagging just right (we could get there if we used the permissive setting then scanned the log for the required rights. Its been a while since I did that type of activity). But from a security standpoint I like where you are going with this.

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

Part 1

The idea for this solution is to build a usb bootable FOS client that will handle the basics of imaging from target registration, suitability checking, debugging, and image capture and deployment.

This solution is only mean to replace pxe booting where the target can’t pxe boot effectcivly or the network adapter is not supported by the firmware for pxe booting such as with uefi firmware and a usb 2.0 network adapter. The only caveat here is the network adapter MUST be supported by the FOS linux kernel. The usb bootable FOS client also should remove any incompatibilities we’ve seen with the iPXE kernel and and the hardware.

The USB FOS Client creation must be done on a linux computer. The operating system doesn’t matter much. What ever the FOG Server supports these instructions should work on. The only caveat here is that what ever operating system you use, the OS must use GRUB as the boot loader. I can say for both Centos and Ubuntu that grub is already installed and used.

The working solution for this solution is based on the work creating the FOSL (FOS Live) usb boot debugging tutorial https://forums.fogproject.org/topic/6532/usb-boot-target-device-into-fog-os-live-fosl-for-debugging and the support of Tom (senior developer) with his quick updates to the trunk build that tied all of the bits together nicely. That brings up the point that this FOS USB Boot drive will only work on/with trunk builds post r8050. If you have an older trunk build than 8050 you must update to get the supporting environment.

If you are interested in the development process of this product you can review this link: https://forums.fogproject.org/topic/7656/pxe-less-booting-fos-client-os

Now lets get down to business in Part 2

OK, if I understand what you want to do (Add a custom ipxe boot menu item). I have been able (on paper) put together a partial solution for you. This solution assumes you are running a SVN trunk upgrade from the core 1.2.0 release.

If you go into the FOG settings and add a custom IPXE menu item. Add these settings:
Menu Item: Dutch.Exams
Description: Dutch Exams Example

Parameters:
kernel /bootimages/facet/vmlinuz0 rootflags=loop initrd=initrd0.img root=live:/configured-bcld.iso rootfstype=auto ro rd.live.image rd.live.ram rd.luks=0 rd.md=0 rd.dm=0
initrd /bootimages/facet/initrd0.img
boot || goto MENU

Then press save.

You can view the results of this setting by pointing your browser at the following url
http://<fog_server_ip>/fog/service/ipxe/boot.php

This will show you the ipxe menu that will be presented to the ipxe menu application

The file path on the fog server is (on rhel) /var/www/html/fog/service/ipxe/

Now the part I don’t know about. You will notice that in my ipxe menu I have a path for the boot kernel. I don’t know if we can create a symbolic link from the path above to where your files are stored and then include that in the ipxe menu command. Or just go the easy route and dump your exam kernel and initrd files in /var/www/html/fog/service/ipxe I think it would be safer for your files to have a sym link from /var/www/html/fog/service/ipxe/<something > to your file location.

As I said (on paper) this should work without having to dig into the FOG code if you are willing to use the SVN trunk.

I found a wiki that talks about setting up dban under FOG: https://wiki.fogproject.org/wiki/index.php/Include_any_ISO_in_the_FOG_Bootmenu

Actually we would like to see you generate that error message again, then view the apache error log in /var/log/httpd/error_log. The last few lines should indicate the current error. The access_log should only show use details when things go right.

Cross linking threads same issue
https://forums.fogproject.org/topic/7494/7731-image-overview-sql-select-text-is-displayed
https://forums.fogproject.org/topic/7492/host-pxe-boot-issues
https://forums.fogproject.org/topic/7493/7731-sql-error
https://forums.fogproject.org/topic/7496/7731-when-trying-to-pxe-boot-sql-command-not-found

Part 2b

These steps and script works correctly on a Cento 7 system.

1. For Centos 7 you must install the following packages
   yum install dosfstools parted kpartx grub2-install grub2-efi-modules grub2-efi -y
2. Centos 7 is a x64 only OS so if you have a i386 uefi system you MUST USE either Centos 6 or Ubuntu 14.04 LTS to build a usb boot drive that supports i386-efi systems. This is not a big issue because there are not many systems that are both IA32 and efi only.
3. The second thing to note about Centos 7 it uses grub2 instead of grub (version 1). So the script commands have changed a little.
4. For Centos 7 paste the following script into mk.fos-usb

#!/bin/bash

if [ -f /tmp/fogkern.img ]; then
    echo Nuking old FOG Debug image
    rm -f /tmp/fos-usb.img
fi

echo Make a blank 150MB disk image
dd if=/dev/zero of=/tmp/fos-usb.img bs=1M count=150
 
echo Make the partition table, partition and set it bootable.
parted --script /tmp/fos-usb.img mklabel msdos mkpart p fat32 1 128 set 1 boot on
 
echo Map the partitions from the image file
kpartx -a -s /tmp/fos-usb.img
LOOPDEV=$(losetup -a | grep "/tmp/fos-usb.img" | grep -o "loop[0-9]*")
 
echo Make an vfat filesystem on the first partition.
mkfs -t vfat -n GRUB /dev/mapper/${LOOPDEV}p1
 
echo Mount the filesystem via loopback
mount /dev/mapper/${LOOPDEV}p1 /mnt

echo Install GRUB
grub2-install --removable --no-nvram --efi-directory=/mnt --boot-directory=/mnt/boot --target=x86_64-efi
grub2-install --removable --no-floppy --boot-directory=/mnt/boot --target=i386-pc /dev/${LOOPDEV}

echo Download the FOG kernels and inits
wget -P /mnt/boot/ https://github.com/FOGProject/fos/releases/latest/download/bzImage
wget -P /mnt/boot/ https://github.com/FOGProject/fos/releases/latest/download/bzImage32
wget -P /mnt/boot/ https://github.com/FOGProject/fos/releases/latest/download/init.xz
wget -P /mnt/boot/ https://github.com/FOGProject/fos/releases/latest/download/init_32.xz
wget -P /mnt/boot/ https://github.com/FOGProject/fogproject/blob/dev-branch/packages/tftp/ipxe.krn
wget -P /mnt/boot/ https://github.com/FOGProject/fogproject/blob/dev-branch/packages/tftp/ipxe.efi

echo Create the grub configuration file
cat > /mnt/boot/grub2/grub.cfg << 'EOF'

set myfogip=http://192.168.1.100
set myimage=/boot/bzImage
set myinits=/boot/init.xz
set myloglevel=4
set timeout=-1
insmod all_video

menuentry "1. FOG Image Deploy/Capture" {
 echo loading the kernel
 linux  $myimage loglevel=$myloglevel initrd=init.xz root=/dev/ram0 rw ramdisk_size=275000 keymap= web=$myfogip/fog/ boottype=usb consoleblank=0 rootfstype=ext4
 echo loading the virtual hard drive
 initrd $myinits
 echo booting kernel...
}

menuentry "2. Perform Full Host Registration and Inventory" {
 echo loading the kernel
 linux  $myimage loglevel=$myloglevel initrd=init.xz root=/dev/ram0 rw ramdisk_size=275000 keymap= web=$myfogip/fog/ boottype=usb consoleblank=0 rootfstype=ext4 mode=manreg
 echo loading the virtual hard drive
 initrd $myinits
 echo booting kernel...
}

menuentry "3. Quick Registration and Inventory" {
 echo loading the kernel
 linux  $myimage loglevel=$myloglevel initrd=init.xz root=/dev/ram0 rw ramdisk_size=275000 keymap= web=$myfogip/fog/ boottype=usb consoleblank=0 rootfstype=ext4 mode=autoreg
 echo loading the virtual hard drive
 initrd $myinits
 echo booting kernel...
}

menuentry "4. Client System Information (Compatibility)" {
 echo loading the kernel
 linux  $myimage loglevel=$myloglevel initrd=init.xz root=/dev/ram0 rw ramdisk_size=275000 keymap= web=$myfogip/fog/ boottype=usb consoleblank=0 rootfstype=ext4 mode=sysinfo
 echo loading the virtual hard drive
 initrd $myinits
 echo booting kernel...
}

menuentry "5. Run Memtest86+" {
 linux /boot/memdisk iso raw
 initrd /boot/memtest.bin
}

menuentry "6. FOG Debug Kernel" {
 echo loading the kernel
 linux  $myimage loglevel=7 init=/sbin/init root=/dev/ram0 rw ramdisk_size=275000 keymap= boottype=usb consoleblank=0 rootfstype=ext4 isdebug=yes
 echo loading the virtual hard drive
 initrd $myinits
 echo booting kernel...
}

menuentry "7. FOG iPXE Jumpstart BIOS" {
 echo loading the kernel
 linux16  /boot/ipxe.krn
 echo booting iPXE...
}

menuentry "8. FOG iPXE Jumpstart EFI" {
 echo chain loading the kernel
 insmod chain 
 chainloader /boot/ipxe.efi
 echo booting iPXE-efi...
}

EOF
 
echo Unmount the loopback
umount /mnt
 
echo Unmap the image
kpartx -d /tmp/fos-usb.img
 
# Write the file to flash drive
# sudo dd bs=1M if=/tmp/fos-usb.img of=/dev/sdX

For the rest of the build follow the Part 2a build.

I don’t know if they have released an official go-live date with a stable release. The developers have issued a new feature hold for the 1.3.0 release. The current (unstable but highly functional) trunk version is still in beta. I can tell you having more people test and use the trunk build will help us get to a stable release faster. I can tell you the (de)bug turnaround is typically very fast with the fog project.

I do suggest (if you have time in your project) that you give the pre-1.3.0 version a try. If you discover issues post them here.

yes after you do the svn up then cd to the bin folder and run setup again.

@hernani First of all I would suggest that you open a new thread since your situation may be unique with a similar end results.

While this may not be “the” solution that fixes your immediate problem, but please update to the latest release which is about 7850. You didn’t mention the FOG server OS in your post (i.e. unique ??).

There should be an install error log. Its moved around a bit during the different trunk releases. It could be in /var/log or /opt/fog/log or in /home or /home/fog. I just ran the svn update again and my install completed without error on Centos 7.

Part 7 Tying it all together

At this point we need to insert the call to our custom bash script into the FOG task sequence. Please do the following:

1. After your script has been fully debugged we need to tell the fog post install script to call our script. With your favorite text editor edit /images/postdownloadscripts/fog.postdownload and at the end of the script insert . ${postdownpath}fog.postexamp
   It is important you include the dot prefix a space and then the full path to your post install script. While that lonely dot seems to be out of place, it tells the bash shell something important that we need. It tell the bash shell process to include the environment (bash variables) from the calling script to the called script. I’ll say this again, its important for our bash script to know about the variables the fog developers created for their scripts to run. We will use some of these variables in our example scripts.
2. After you have added the call to our example bash script save and exit out of the fog.postdownload script.

Thats it, the FOG install sequence will call the fog.postdownload after the image is on the workstation. The fog.postdownload will call our custom application and then return back to the FOG install sequence to finish up the house keeping functions.

@Wayne-Workman I think other than the fog installer, and postdownload scripts, FOG doesn’t use the bash shell (on the server side).

If someone had the motivation one could take a WAMP setup on Windows, CygWin, plus a few posix utilities from the Windows resource CD. One could make a Windows based FOG server.

The other issue is the FOS client OS. The bash shell would help there because the scripts as mostly bash from what I saw.

But again would it be really worth the effort. Now you would burn a windows server license for each fog server. The windows server would also have a higher system requirement than a linux equivalent as well as all of the windows vulnerabilities and patch management cycles.

Maybe its just my distorted view, but I’m not seeing FOG on Windows as a win.

@Rusty Some systems will try to do a two way match between conical name->IP address -> conical name. This is a standard function of DNS. I’m kind of surprised that this issue (not having a reverse lookup zone) hasn’t been a problem.

whelp that wasn’t it. Fixing that did some crazy things to the web gui.

(place holder)

@C-M Lets see where to start. (I did quickly read through Wayne’s most excellent posts).

For your setup I would go about it this way.

First setup MDT to create your reference image in a VM. ESXi is the best choice, but you can use vm player (watch your licensing), or hyper-v. This is only to create your reference image. If you use the light touch method, once you start the image creation process the next time you touch the reference image is when you sysprep it. You can have MDT install the OS, run windows updates to download and install all current updates and then layer on any applications and then finally run one last windows update. We use this method to create one thin image (OS and updates only) and a fat image (OS, updates, and all applications) using the light touch method. Understand it take time to setup this environment but once it’s done we can build a new reference image each quarter without any pain.

Drivers: One comment you can either let MDT add the drivers to your reference image or do the hackish way to load your drivers. If you let MDT do it you will have to add every driver for every combination of hardware you will deploy your image to. In my case that’s 15 model of dell computers. The hackish way to do it is via a post install script where you will copy the correct drivers to a certain location on the target computer based on the model of that computer. Then on first boot of the target computer it will detect and load the drivers as needed. If you are working as a MSP I would go with the thin image (and then have your custom apps layered on after) or one fat image per client, but that is up to you.

Once you have the reference image build and sysprepp’d then pxe boot the vm into the FOG menu and capture the image. From there you just deploy as normal.

In regards to connect to the domain, if you don’t use the fog client then just use the unattend.xml file to connect the client to the domain. That is how I do it for one environment here. I can’t have any non-MS software on the target computer, so I just let the unattend file connect the computer to the domain and the right OU.

@Rusty said:

Updating to SVN 4367 didn’t help with this Dell Inspiron I have here. The second laptop I have here boots into FOG menu everytime.

Not to fork this thread, but just so I can get this clear in my head.

You have two computers that are exactly alike. They are the same models, with the same bios release and the same bios settings. But one boots to the fog menu and the other hangs at the init devices?

Have you tried to reset the bios back to defaults on the one that doesn’t work, save and reboot, then make any changes necessary for your image (uefi, legacy, roms, etc.) save then pxe boot. If it still hangs. Power it off, remove the battery and charging cable. Then power everything back up. If it still hangs then I might consider the mobo has issues. There may be a way (kernel parameter) that the developers can set to tell exactly where its hanging.

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.