@anthonyglamis if you are using svn to manage the trunk package, you change into the trunk folder and run svn up that will download the latest code from the subversion repository. Then cd bin and then ./installfog.sh
If you are using git they have a comparable update command.
Windows 10 BIOS/UEFI 2021 edition
17-Mar-21 this post is currently being edited, so its not complete
First we’ll create the required directories. In this tutorial we will use a windows server/workstation to host the installer files. This is the easiest solution, but if your goal is to only use the FOG server follow the instructions at the end of this thread for SAMBA install instructions. On your file server copy the content of the Windows installation DVD to a folder on your file server. Be sure to set the permission so that everyone has read only access to that directory. Now share that directory. For this tutorial the Windows file server will be called \fileserv01 with the share name of \win10$
In this next step you will need a valid user ID. It can be a domain level or machine level. Create this user id and password. For this tutorial we will create a domain account called consento\user01
Beyond this point you will need a Windows 10 1909 (or later) workstation. You also need to be aware what version of windows 10 you intend to deploy. You need to download the proper version of Windows ADK for the version of Windows 10 you will execute these instructions against.
Download the appropriate ADK for the version of Win10 you have from here: https://developer.microsoft.com/en-us/windows/hardware/windows-assessment-deployment-kit You will need both downloads “Windows ADK for Windows 10” and “Windows PE add-on for the ADK”.
Launch the ADK installer. You will be presented with about 15 different modules to install. You only “need” the Deployment Tools feature from the “Windows ADK for Windows 10”. Now run the “Windows PE add-on for the ADK” installer . From this installer you will need (the only option) Windows Preinstallation Environment (Windows PE).
It might take as long as 20 minutes to install both packages depending on your network connection and target computer.
While this step is not necessary it is also a bit of an assurance that WinPE10 will have a good install of basic drivers needed to boot current hardware.
Download the WinPE10 drivers from the Dell Enterprise site here: https://www.dell.com/support/kbdoc/en-us/000180533/dell-command-deploy-driver-packs As always download the latest WinPE Cab pack. At the time of this writing it was A23.
I realize that you may not be using a Dell for your imaging, don’t worry these drivers only cover network and disk subsystems.
Extract the winpe folder from the cab file and copy it in the winpe folder in the root of C drive (c:\winpe).
After the install launch the ADK environment from Start Button->Windows Kits->Windows ADK->Deployment and Imaging Tools Environment Make sure you run this command window as Administrator. FYI: you’ll need admin rights to use DISM.
In the Deployment and Imaging Tools Environment command window you just opened you will need to execute the following commands.
For the rest of the instructions we’ll just go copy and paste. Its fast and quick.
cd c:\
copype amd64 C:\WinPE_amd64
Dism /Mount-Image /ImageFile:"C:\WinPE_amd64\media\sources\boot.wim" /index:1 /MountDir:"C:\WinPE_amd64\mount"
Dism /Add-Driver /Image:"C:\WinPE_amd64\mount" /Driver:"c:\winpe\x64" /Recurse /ForceUnsigned
notepad C:\WinPE_amd64\mount\Windows\System32\Startnet.cmd
@echo off
echo Setting up WinPE
wpeinit
REM Set power configuration to Performance
powercfg /s 8c5e7fda-e8bf-4a96-9a85-a6e23a8c635c
echo Connecting to the remote share
net use z: \\<server_name>\<share_name> /user:<domain\uid> <pass>
z:
setup.exe
I stopped here editing this document
15. Now that we have the settings the way we need them. Lets close the wim file and create our ISO.
Dism /Unmount-Image /MountDir:"C:\WinPE_amd64\mount" /commit
MakeWinPEMedia /ISO C:\WinPE_amd64 C:\WinPE_amd64\WinPE_amd64.iso
Now move the C:\WinPE_amd64\WinPE_amd64.iso file to the FOG server in the /images/os/mswindows/7Pro-x64 directory.
The last bit of magic we need to do is setup a new FOG iPXE boot menu entry for this OS.
NOTE: This instruction is for legacy bios only. If you need to boot both uefi and bios installs follow the WinPE10 section above. The issue is that memdisk utility is not supported in uefi mode, so another method is required. For bios mode memdisk IS the quickest method to boot a small iso image. https://forums.fogproject.org/topic/10944/using-fog-to-pxe-boot-into-your-favorite-installer-images/10
In the fog WebGUI go to FOG Configuration->iPXE New Menu Entry
Set the following fields
Menu Item: os.Win7Pro-x64
Description: Windows 7 Pro x64 OEM
Parameters:
initrd nfs://${fog-ip}:/images/os/mswindows/7Pro-x64/WinPE_amd64.iso
chain memdisk iso raw
boot || goto MENU
Menu Show with: All Hosts
That’s it, just pxe boot your target system and pick Windows 7 Pro x64 OEM from the FOG iPXE boot menu.
For this process to function you must also setup SAMBA on your fog server below.
References:
https://forums.fogproject.org/topic/7765/pxe-booting-into-ms-windows-7-setup
While I don’t remember v2929 that number is close to FOG 1.2.0 stable, which does not support NVMe drives, gpt disks, or Win10 (in general).
What error is being thrown when you try to upload that image?
The ultimate answer is to upgrade to 1.3.0-RCX to get new hardware support as well as Win10 Support. But I do have to admit that I have not created a 1607 reference image as of yet, so there may be changes that not even fog 1.3.0 supports as of now.
In this tutorial we will walk through the process of setting up FOG to utilize the Secure Boot option in the UEFI firmware.
This thread is very much still under construction and not as refined as I would like it. In this state its more of a brain dump than a finished product.
Understand this process is complex, detailed, and is not officially supported by the FOG Project Devs. In the end does it work, so far yes.
Secure booting into any non-microsoft OS is a bit complex. There are basically two ways to go about it.
If the FOG project would go with having Microsoft officially sign the FOG kernel that would be the best solution since you would not need to change anything on the target computer other than enabling Secure Booting. The down side to this is that the FOG Project would have to create some kind of subscription service (my opinion) and charge for the secure booting feature. Not only does it cost to have Microsoft sign the FOS linux kernel they will need to hire someone to manage the entire secure boot kernel and boot loader process. To be able to completely image with FOG with secure boot on, we need to have signed bzImage, bzImage32, ipxe.efi, snponly.efi, refind.efi. As you see its not really a simple matter of just having FOS Linux signed. The other thing with having an outside party sign our files is that it will slow down the FOG versioning and upgrade process. The real answer is to somehow have the FOG server to add a digital signature to the files needed for booting. The problem with this approach is that target computer’s firmware needs to hold the same certificate used to sign the files needed for booting to signal that the software that is starting up is valid and known.
I checked a another FOSS imaging solutions (Clonezilla) to see how they managed secure booting linux for imaging. They took an interesting approach and used debian/ubuntu generic kernels that were signed by microsoft. Since Clonezilla is not booting over the network in this case they eliminated the need for needing a network boot loader signed. Everything that is needed for imaging with Clonezilla is on the boot usb drive.
I have to say when I started this project I did not have any idea how secure boot worked and what was needed to make thinks click in order. I still only know enough to be dangerous. Everything I now know came from these articles.
https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html
https://wiki.gentoo.org/wiki/User:Sakaki/Sakaki's_EFI_Install_Guide/Configuring_Secure_Boot
https://forums.fogproject.org/post/145434
I’m not going to explain how secure booting works because I really can’t add anything more that the articles above could provide. In the following posts I will go through the step by step process I used to get secure booting working in my test lab. The actual process, while it has many steps, none of the steps are more difficult to execute.
The overall workflow of this tutorial will be to add the capabilities to a ubuntu or debian FOG server (I was able to duplicate the process on a centos/rhel 7 server, but alas, red hat is now dead to me) and create the secure boot PKI infrastructure, create an enrollment boot loader, sign the FOG boot files, and lastly update the certificates on the target hardware with the new FOG secure boot PKI certificates.
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.
The instructions above are only for the dynamic part of dhcp option 67. You still must supply dhcp option 66 which should be the ip address of your FOG server.
If you have everything setup and if its still not working then I suggest a test.
Place the fog server, dhcp server and test target computer in the same subnet. This is only for a test. We need to capture the network packets of the dhcp booting process. This will tell us 1) the filters you created are working as intended, 2) what is really going down your network wire.
Please do the following once all three are on the same subnet (broadcast domain):
tcpdump -w output.pcap port 67 or port 68 or port 69 or port 4011Just be aware there are several different types of uefi systems you may have to create different filters than just arch 0007. The pcap will tell the truth of what is needed.
While this is a bit off point, we are seeing with windows 10 that a shutdown is not really a shutdown. Its a bit more like enhanced sleep state. If you want to capture a windows 10 image we have better luck with a reboot into the fog capture from audit mode or using sysprep with the power off command line option to properly close the disk and not leave that dirty bit turned on.
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.
md /var/www/html/isoimg or md /var/www/isoimg depending on your linux distribution.cd /var/www/htmlchown -R fog.fog isoimgBe 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)
Tom IM’d me and suggest that I update again. He made a few changes since 7657. So r7665 works as expected.
@x23piracy Yes you will (might) need the others depending on the hardware you are tying to boot. The pcap will tell you what the client is saying. I still think its worth the time for you to learn this part to debug pxe booting. But I also understand that it will take a little time to setup.
I agree if the wiki is not clear we should revise it to include a mention of be sure to set the dhcp option 66.
We are here is you need help.
Setting up DNSMasq on Centos 7 is pretty straight forward and can be done in about 10 minutes.
Use case(s):
Here are the steps needed to setup dnsmasq on your FOG server running under Centos 7
yum upgrade -yyum install dnsmasq -yvi /etc/dnsmasq.d/ltsp.conf# Don't function as a DNS server:
port=0
# Log lots of extra information about DHCP transactions.
log-dhcp
# Set the root directory for files available via FTP.
tftp-root=/tftpboot
# The boot filename, Server name, Server Ip Address
dhcp-boot=undionly.kpxe,,<fog_server_IP>
# Disable re-use of the DHCP servername and filename fields as extra
# option space. That's to avoid confusing some old or broken DHCP clients.
dhcp-no-override
# PXE menu. The first part is the text displayed to the user. The second is the timeout, in seconds.
pxe-prompt="Booting FOG Client", 1
# The known types are x86PC, PC98, IA64_EFI, Alpha, Arc_x86,
# Intel_Lean_Client, IA32_EFI, BC_EFI, Xscale_EFI and X86-64_EFI
# This option is first and will be the default if there is no input from the user.
pxe-service=X86PC, "Boot to FOG", undionly
pxe-service=X86-64_EFI, "Boot to FOG UEFI", ipxe
pxe-service=BC_EFI, "Boot to FOG UEFI PXE-BC", ipxe
dhcp-range=<fog_server_ip>,proxy
The above values are for BIOS booting via PXE. As of the date of this post, dnsmasq does not support the uefi menu or uefi booting. So for now dnsmasq and uefi are not compatible (as of May16 the devs of dnsmasq have released their first attempt an supporting uefi firmware. I can see great things coming from this).
You must update the <fog_server_ip> values with the exact IP address of your FOG server.
5) Create the needed .0 files. By creating a link each time the undionly file is updated the .0 file will remain current.
ln -s /tftpboot/undionly.kpxe /tftpboot/undionly.0
ln -s /tftpboot/ipxe.efi /tftpboot/ipxe.0
6) Restart the dnsmasq service
systemctl restart dnsmasq.service
7) Then ensure dnsmasq service starts on each boot.
systemctl enable dnsmasq.service
For the copy and paste people like me here is the concise version.
yum upgrade -y
yum install dnsmasq -y
vi /etc/dnsmasq.d/ltsp.conf
<insert text>
<update settings in text>
ln -s /tftpboot/undionly.kpxe /tftpboot/undionly.0
ln -s /tftpboot/ipxe.efi /tftpboot/ipxe.0
systemctl restart dnsmasq.service
systemctl enable dnsmasq.service
@Tom-Elliott While this vote comes after the decisions has already been made. I vote for removal too. While I feel strongly that FOG needs quite a bit finer access control, that plugin isn’t the right tool and it causes more question than provides any type of solution.
For those that use the current access control plugin in today. You WILL need to find a way to (side load) the plugin so they can remain using it. But for mainstream users, it should be hidden or just removed. If you flat remove the plugin then people that need it will not migrate past RC2 since they will lose this utility. (for discloser I do not use the plugin).
Now for FOG 2.0 access control (as well as security) needs to be built in from the beginning.
@george1421 After a lengthy chat session then switching to team viewer we found the issue.
Basically the fog.driver script was throwing this error:
/images/postdownloadscripts/fog.drivers: line 2: $’\r’: command not found
/images/postdownloadscripts/fog.drivers: line 3: $’\r’: command not found
/images/postdownloadscripts/fog.drivers: line 4: syntax error near unexpected token $'in\r'' 'images/postdownloadscripts/fog.drivers: line 4:case $manu in
The key to me was seeing the \r that was being complained about.
In a nutshell the issue was how the file was copied from the web, pasted into notepad++ on windows and then copied to the FOG server using winscp. Somewhere along the way carriage returns where added to the end of each line in the script. I installed dos2unix and ran that utility on the fog.drivers script. That cleaned up all of the errors. We again single stepped through the install process. I confirmed that the source path existed as well as the files on the target computer after the fog.drivers script completed.
When I left MotD he started to reboot the target computer to start the Win10 OOBE process.
Summary: The issue was related to the Windows->Unix file migration only. The script worked as outline in the thread.
@Marinus After I made my post, Tom posted a tidbit of information in another thread that only Tom knew about. With FOG 1.2.0 it can only support kernel images below 4.4. Once you get to 4.4 and newer the kernel relies on some additional code in the inits that is part of the trunk build (and 1.3.0-rc1). One way for you to use the latest kernels is to upgrade to 1.3.0-rc1 (a.k.a the trunk release).
Note: This article has been replaced by a newer document at https://forums.fogproject.org/topic/7727/building-usb-booting-fos-image This newer document doesn't have the details developed in this tutorial. I'm leaving this document in place for historical purposes only. You should follow the instructions in the referenced tutorial to produce a functional FOS boot usb.
I’m documenting this process to help with the target device debugging process (but mainly to see if I could do it). Lately we’ve had many leading edge devices fail to pxe boot into the FOG kernel (at the time of writing this the Surface Pro 4 is being tough to debug. The surface pro 4 boots into the ipxe menu, but as soon as you pick an action it appears to hang). By booting the fog client directly into the debug kernel we can help determine if the issue is ipxe related or fog kernel related.
I have an idea how I can rewrite this for the windows folks, for now this is the linux based instructions
Method #1 (linux path / BIOS boot)
The process steps are not complicated, you will need to acquire these things before you begin
Steps to create the bootable usb drive drive
$ lsblk
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/jondoe/myflash
From this we can see the flash drive (in my case its a 16GB flash drive) is mounted as /dev/sdb. We must remember this path since we will execute several destructive commands next. You MUST be sure you correctly identify the flash drive. The next step is to delete all partitions on this flash drive. If you get it wrong something important may be lost forever
5) We’ll use fdisk to delete all partitions on the flash drive. In most cases there will be just a single partition on the flash drive. The lsblk command shows us this too. Key in the following command.
fdisk /dev/sdb
6) Key in d (if fdisk prompts for a partition number enter 1)
7) Key in n to create a new partition p for primary 1 for first partition and then enter twice
Key in p to print the current partition table. You should get a printout similar to this
Command (m for help): p
Disk /dev/sdb: 16.1 GB, 16131293184 bytes
255 heads, 63 sectors/track, 1961 cylinders, total 31506432 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0007f93b
Device Boot Start End Blocks Id System
/dev/sdb1 63 31506431 15753184+ 83 Linux
Note its important that the partition ID be 83 Linux. This was selected as the default value when I created this partition.
9) If everything looks good press w to write the partition table. If fdisk does not exit to the command shell key in q to quit.
For the rest of this post I’m going to switch to say /dev/sdX to represent the flash drive. I don’t want someone to just blindly copy and paste the commands and wipe out something really important.
10) At this point we have a flash drive that has a linux partition on it. Now we need to format the drive. Key in the following:
sudo mkfs /dev/sdX1
11) Now lets mount it so we can install grub.
sudo mount /dev/sdX1 /mnt
12) Next we’ll tell grub to install its boot loader onto the flash drive. Key the following command in to setup the grub environment on the flash drive:
sudo grub-install --force --no-floppy --boot-directory=/mnt/boot /dev/sdX
13) Next we’ll need to install the FOG boot files on the flash drive. Change into the boot directory that was created by the grub-install command.
cd /mnt/boot
14) Next download the following files from the fog project web site. We’ll use the wget command for this.
sudo wget https://fogproject.org/inits/init.xz
sudo wget https://fogproject.org/inits/init_32.xz
sudo wget https://fogproject.org/kernels/bzImage
sudo wget https://fogproject.org/kernels/bzImage32
15) When all of the image files have been downloaded, we need to tell grub how to use them. For this we need to create the grub configuration file. (note: I’m old school and use the vi editor, you could use any text editor you wish here.)
sudo vi /mnt/boot/grub/grub.cfg
16) Paste in the following section into the grub.cfg file.
set timeout=10
set default=0
menuentry "FOG 32-bit Debug Kernel" {
linux /boot/bzImage32 loglevel=7 init=/sbin/init root=/dev/ram0 rw ramdisk_size=127000 pcie_aspm=off consoleblank=0 isdebug=yes
initrd /boot/init_32.xz
}
menuentry "FOG 64-bit Debug Kernel" {
linux /boot/bzImage loglevel=7 init=/sbin/init root=/dev/ram0 rw ramdisk_size=127000 pcie_aspm=off consoleblank=0 isdebug=yes
initrd /boot/init.xz
}
The above text will create two menu items in the grub boot menu. The fist will be the 32 bit FOG client operating environment, the second will be the 64 bit FOG client. The default client is the 32 bit version. You have 10 seconds to select the 64 bit version. I selected the 32 bit version as default because the 32 bit will boot on both IA32 an amd64 processors.
17) Now that everything is in place we need to move out of the USB drive and unmount it.
cd /
18) Then issue the unmount command
sudo umount /mnt
19) Remove the usb drive from the setup computer and insert it into the target computer
20) Power on the target computer and press F10 or F12 (depending on the manufacture) to bring up the boot menu and select the USB drive.
21) The grub menu should show up right away.
22) Select either the 32 bit or 64 bit boot images and press enter.
Note: If you select the 32 bit image, there will be an unsettling pause with a flashing cursor in the upper left corner of the screen, after about 8 seconds you will see the kernel boot. If you pick the 64 bit image, you will see text spew across the screen right away then boot the kernel. The only thing I can think is that the 32 bit image blanks the screen while the inits are loading and the 64 bit version does not.
@ddeatrich Hint: Please use putty to connect to the FOG server using ssh. With putty you can copy and paste better than snapping screen images of logs and such.
With Putty just click and drag across the text like you can do in a windows console then you can paste it in.
@hancocza I’m going to say you have an nfs issue, where you might not have all of the ports open you need.
@PageTown I know it was a long path to get to this point, BUT know in your heart you are in a better place for the pain you went through. (just channeling Dr. Phil).
You are on a current and supported release of the your OS and for FOG. When 1.3.0 stable is finally released you will be on a solid platform that you can use for a few years.
Part 3 Code snippets
This first code snippet will connect our post install script to the target computer’s hard drive. This connection may or may not have been made by a previous FOG script. If the connection has already been setup we’ll just error gracefully and continue on with the execution. This is a good programming style in that you need to do a task, perform that task as if no other script has run on this target computer, go through the steps to set it up and then tare it down before you script is over.
or windows partition. If there is a 
drive in the target image then there will be a 3rd partition, and so on. For our script this second partition will be the target of our attention. To allow our script to interact with the windows partition on our target computer we will first need to create a mount (or connection) point in FOS and then attach the second partition of the first disk to that mount point. We’ll use the following code snippet.osdiskpart will represent the disk and partition we are interested in.# windows 7
osdiskpart="/dev/sda2";
# create a directory to hang the Windows C: drive partition on in FOS
# the 2>/dev/null below just redirects any errors from the mkdir command to null. i.e.
# if the directory already exists, I don't want to know about it, just hide the error. Understand
# that I could have tested if the directory already existed, but that takes more programming steps
# I'm just going to try to create it and ignore the error if it already exists.
mkdir /ntfs 2>/dev/null
# This next command connects the hard drive partition to the directory we just created. You will see the
# 2>/tmp/mntfail at the end of the mount command. In this case if the connection fails we want to write
# the output to a text file we can review and test to see if it exists. If the file exists then something went
# wrong with the connection to the hard disk partition.
mount.ntfs-3g "${osdiskpart}" /ntfs 2>/tmp/mntfail
# this last bit of magic checks to see if the mntfail file exists and if it does then it means the mount
# failed so there is no need to continue on with the script.
mntRet="$?";
if [ ! "$mntRet" = "0" ]; then
echo "Failed to mount C:";
# display what happened
cat /tmp/mntfail;
# give the reader a chance to see what the error was
sleep 12;
# terminate the post install script
exit 1;
fi
Note: the unattend.xml file is only used if the reference image was sysprep'd before image capture. Since we were following the recommend rules and sysprep'd the image before capture this is the current state our reference image# Unattend.xml path (note the case specifics in the file name and path)
unattendfile="/ntfs/Windows/Panther/unattend.xml";
sed -i -e "s#<ComputerName>\([^<][^<]*\)</ComputerName>#<ComputerName>$hostname</ComputerName>#gi" $unatendfile
sed -i -e "s#<TimeZone>\([^<][^<]*\)</TimeZone>#<TimeZone>$timezone</TimeZone>#gi" $unattendfile
computer ou
sed -i -e "s#<MachineObjectOU>\([^<][^<]*\)</MachineObjectOU>#<MachineObjectOU>${oupath}</MachineObjectOU>#gi" $unattendfile
< insert keyboard>
< insert system language>
6. Lets say we need to determine what type of computer is the target computer (i.e. desktop, laptop. ?). We can query the SMBIOS using dmidecode to extract we are installing the chassis type using this code snippet.
chassis=`dmidecode -s chassis-type`;
chassis="${chassis%"${chassis##*[![:space:]]}"}"; #Remove training space
chassis="${chassis,,}"; # Convert string to lower
if [ "$chassis" = "laptop" ]; then
chtype="Portable";
elif [ "$chassis" = "tablet" ]; then
chtype="Tablet";
else
# We'll default every other chassis type to desktop
chtype="Desktop";
fi