Posts made by Zer0Cool

I actually made some progress on this front. It became a bit more clear when I thought it over and made some considerations.

My setup is such that I have mirrored (via rsync) local repos of CentOS and Fedora. I then symlink the ISO’s within those repos to another place to make them easy for people to download the ISO. In this scenario I don’t have to do anything with the ISO to get the installation files need by PXE as they are available in the repo as I have syncd them.

With the above in mind, I should be able to accomplish the same for any Linux distro that I can mirror/rsync locally which nullifies the needs/goals of my OP.

I then thought about what OS’s this need actually applied to, and in my case it came down to Windows 10 and ESXi (various versions). I don’t mind downloading the ISO manually. What I was looking to accomplish was being able to take an iso or a batch of them in a dir and identify their; OS, version, build, revision and be able to use that to create a unique directory structure for said iso and then dumb the iso contents into the created dir structure for it.

The part I was hung up on was how to get the information I needed for this and that part, at least for Windows 10 (really any Windows ISO) and ESXi I have figured out at least as a proof of concept. I realized that the iso file name would not be the most reliable method of doing so and found ways unique to each OS family to identify the metadata I needed.

ESXi (having checked multiple Dell isos from 6.5-6.7):

I found that they had a /upgrade folder with 2 note worthy files in them. metadata.xml contains the version number and build number. profile.xml has the full name (so even if the file name of the iso is changed this should stay the same) from which I could extract things like the Dell revision and U1/U2 monikers used for Update 1 and Update 2, etc. It also has a tag for “creator” so I should be able to differentiate between Dell isos and non-dell isos.

To parse out the xml I found that xmllint provided by libxml2 would allow me to reliably pull this info from the xml files. Coincidentally, libxml2 was needed by wimlib anyhow (mentioned below for Windows).

Windows 10:

I installed wimlib and using the wiminfo command on the install.wim (combined with grep) I am able to pull information about the ISO as well as deduce if the ISO is a Windows ISO. I can get name, version, build number in this fashion.

I may expand this to Server 2016/2019 if they start releasing new iso builds “frequently” like they do with Windows 10, but older versions the iso hasnt changed for a long time and I have these setup already.

So basically it comes down to checking the ISO’s for the structure/files that match the OS family. In this case /upgrade/metadata.xml being ESXi and /sources/install.wim being Windows. Then I either parse out the XML for ESXi or using wiminfo pull the info from the wim file for Windows.

After that should be “easy”. Create a path using that info, check if it already exists, dump the iso contents, unmount, etc. I am also considering putting a fail safe kind of option in so that if the ISO doesnt match any conditions I am checking to “classify” it, I can prompt the user for manual input if they want to process the ISO allowing them to determine the path to dump it into.

Follow Up Question:

I hadnt considered it before, but generally speaking I assume it would be possible via the bash script to also update or add to the FOG’s iPXE menu by manipulating the “config” file that stores the menu? Or is there a database in between that would make that problematic?

I am not stuck on automating the menu creation but if its a relatively simple addition might as well add it.

Conclusion:

Once I get this written up into a moderately working fashion I intend to post it on my Github and would be happy to share the link back here.

Thanks

This isn’t really FOG specific, though it will help me in my use of FOG (and maybe others). If it isn’t appropriate to ask here please feel free to close the thread, my apologies.

I was wondering if anyone knows of a script or tool for automating the process of preparing the OS dirs/content needed to PXE install and OS.

What I mean is, before ever getting to creating the iPXE menu entry, one would typically mount an OS iso and copy its contents to a directory on FOG.

What I am finding is that I often need to repeat this process as new versions of OS’s come out and generally check every couple of weeks/months so I end up finding multiple OS’s with new versions. Its then a laborious process to manually create each destination dir/subdirs, mount the iso, copy the contents, unmount the iso and repeat.

I am considering trying to write a bash script to help automate this but figured I would ask before diving in in case someone else has already addressed this.

So, essentially what I would like to accomplish is to point something to a dir and have it process all the iso’s in the dir such that:

• Each iso has a folder created for it according to its OS/ver. IE: win/7 or esxi/6.5 A01
• Each iso is mounted and its contents copied to the right directory for it then unmounted.

From my perspective, the tricky part in a bash script would be how to identify each iso and properly “categorize” it to create the desired dir/subdirs.

I have searched online to see if a tool for this exists but couldnt find one, maybe its just not feasible?

I dont mind updating the iPXE menu entries (or creating new ones) manually in FOG, but processing the isos is starting to be a chore I feel automation could address.

Thanks

@george1421 Hey Thanks for the reply. To answer your question, we do not use any other DHCP server currently. All IP’s on other VLANs are set statically. The only DHCP server is the FOG server.

I know it sounds dumb, but in my environment, it makes sense for many reasons.

As you have explained it, am I to understand that I need another DHCP server aside from the FOG server to make this work? If not, does it make it any easier?

I am open to any suggestions that would make it possible (preferably easy) to have FOG (or a “helper” DHCP server) be able to work across VLANs.

Thanks

FOG 1.5.3
CentOS 7.5
Run as a VM in ESXi 6.7 free
FOG uses a single virtual NIC (typically)

FOG is the only DHCP server on any of the desired VLANs I know of. I do use 2 other servers for DNS. Otherwise the FOG server is self sufficient. Everything works as expected for hosts on the same VLAN/subnet as the FOG server.

Goal
I need to get FOG to PXE boot and be able to image/capture from hosts on multiple VLANs/subnets. Its not an option for me to put everything on the same VLAN.

Setup
I have a physical network that’s structured as follows:

1. Palo Alto Firewall
2. Juniper Switch
3. Arista Switches
4. Hosts

I have the following VLANs/subnets:

• 100/10.0.0.x - FOG is 10.0.0.2 on this vlan and works when physical and virtual hosts are on the same vlan
• 1600/172.16.0.x - Many hosts on this vlan.
• 1605/172.16.5.x - Many virtual hosts (VM’s) on this vlan.

The 100 VLAN can cross communicate with all other VLANs, setup under the settings in the Palo Alto (rules, zones, etc). IE: its possible to ping across VLANs, SMB, etc.

I am currently not concerned with making any other VLANs work with FOG but it would be nice to be able to expand to include others in the future.

Things I Tried
I started by creating a DCHP Relay agent on the Palo Alto and editing the dhcpd.conf file to include another subnet section. This alone ended up with the closest to working I got. Hosts on 1600 for example would PXE boot, get the proper IP address from the proper subnet but would then give a PXE error, I think #11 regarding ARP (PXE-E11: ARP Timeout). At this stage they would just give the option to press a key to reboot.

I then took steps to try and configure Juniper/Arista switches to also handle DHCP relay with no luck, 0 change in the outcome.

I also tried adding another virtual NIC to FOG, placing it on another VLAN/subnet and ran into odd issues, eventually I think coming down to TFTP being assigned a static/single IP address in the FOG gui/settings. The first problem with this was that the original NIC on 10.0.0.x seemingly stopped working for everything expect PXE booting (ping, network, internet all stopped working) while the new NIC on 172.16.0.x worked as expected. Disabling the new NIC (in CentOS) would make the 1st NIC instantly start working completely. Machines PXE booted on the second new VLAN would get a little further than before but are unable to load the boot files as TFTP still appears to try loading them from the original IP/vlan address on 10.0.0.x and fails.

So I am not sure whats easier to correct, the ARP timeout when using DHCP Relays or the issue of TFTP not using the IP/vlan of the NIC on FOG matching the hosts VLAN/subnet.

Final Thoughts
I am open to any solution that can get this working or at least an explanation of the limitations of FOG in a setup like this, as I imagine its possible I am just trying to do something that shouldnt be done. For what its worth I have been through our wiki, many hours of research on Google and trying to iron this out with the help of multiple co-workers and we are stumped.

I have tried to provide as much relevant details as I can and will be happy to provide more to the extent that I am allowed.

Thank you for any help or guidance you may be able to provide.

Here is my entry, this just boots up as if you put the disc in the host, should work UEFI or BIOS. I just did a new iPXE entry from the web GUI and placed this in the parameters.

kernel http://${fog-ip}/os/cz/live/vmlinuz
initrd http://${fog-ip}/os/cz/live/initrd.img
imgargs vmlinuz initrd=initrd.img vga=791 boot=live union=overlay components noprompt edd=on nomodeset nosplash config locales=en_US.UTF-8 keyboard-layouts=NONE fetch=http://${fog-ip}/os/cz/live/filesystem.squashfs ocs_prerun="" ocs_live_run="" ocs_live_batch="no"
boot || goto MENU

I have the Clonezilla CD contents at ${fog-ip}/os/cz/live which I have pointed httpd/apache to. You can replace http with tftp or whatever protocol you use for PXE booting.

Clonezilla has a list of parameters someplace that I used to help me work out the menu.

I am sure you have a good reason for using Clonezilla or wanting it, would you mind if I asked why?

I have it for old images captured using Clonezilla while I transitioned to FOG, but honestly dont need/use it anymore.

@tom-elliott said in FOG 1.6 Testing Needed - Help would be greatly appreciated as needed:

I know you all have been hearing about our work on 1.6 and maybe even our “kind of” roadmap with 1.7, 1.8, 1.9, and 2.0.

Is there any specific place we can check this info out? I would be interested to read about future plans. Thanks

Forget it, sorry to waste anyone’s time. Redoing it has worked on all machines. I am guessing applying just the snapin via group wiped the key fields for each host.

FOG 1.5.3
CentOS 7.5

I am not sure if this is a known issue, an unknown issue or simply my own fault.

I have 7 hosts registered. For each one set the key, clicked update, then went back to the hosts list, back to the updated host and verified the key was in the field. I then followed the same process for enabling a snappin on each and setting domain join on each.

After having done that for all 7, I added all 7 to the same brand new group. From the group I applied the same snappin previously applied to each via the group and made no other changes/updates independent or via the group.

I then did a multicast via the group and sent the same Windows 7 image to all the machines. I used an 8th machine already imaged from this image (literally solo deployed the image to it prior) to run the task via the web GUI. Its worth mention that the 8th machine was imaged and worked just fine.

The 7 host machines went through the entire imaging process including joining the domain and running my snapin but did not activate Windows with the keys I had previously provided. Going back to check each host in the web GUI and none of the 7 have a key in the field now.

I am hoping I just made a dumb mistake in how I executed my process (likely something to do with doing the keys before using the group to update something else), but its possible this is similar to the bug I found/helped find with the iPXE descriptions not being saved on creation (updates stuck, but initial creation would not save this field) in a prior version of FOG.

I have assigned the keys 1 by 1 to all 7 hosts again, verified that they are in the field and also exported the key list from reports. This all checks out. I am going to re-image the same 7 machines using multi-cast again and see if the result changes or if it happens again. I will report back my findings in case this is a bug.

Any input is welcome, as I am working on 0 sleep now its possible I will make more mistakes

@ty900000 Was a permissions issue for me, had nothing to do with TZ

https://forums.fogproject.org/topic/12048/unable-to-install-kernel-4-17-0/22

CentOS 7.4 and 7.5

Works with: UEFI or BIOS

To start we need the installation files in our /tftpboot/os/centos directory. This can be done by manually copying the required content from a CentOS iso or by using rsync to sync from an online mirror. A list of official mirrors with rsync links can be found here. The following will presume the latest version of CentOS (at this time 7.5.1804) but altering the version to your desired version in the steps should work.

You do not have to do the steps in BOTH “Using Files from ISO” and “From rsync”, its one or the other.

Using Files from ISO:

1. Create the directory for CentOS/version if it doesnt already exist:

mkdir -p /tftpboot/os/centos/7.5.1804

2. Mount the ISO and copy the required files to the above directory:

mount /{path to the iso}/filename.iso /mnt/iso/
cp -R /mnt/iso/* /tftpboot/os/centos/7.5.1804
umount /mnt/iso

Using rsync:

1. Do not create the subdirectory for the CentOS version, just have /tftpboot/os/centos ready, rsync will create the subdirectory.

2. run the rsync command using a rsync url from the list of mirrors you want to use. This can take hours to run:

rsync -avzP --log-file=/var/log/rsync_cron/rsync_yum_mirror.log --delete --include="/7.5.1804" --include="/7.5.1804/**" --exclude="*" rsync://mirrorurl/centos/7.5.1804/os/x86_64/ /tftpboot/os/centos

feel free to change the path/name of the log file. I use this rsync to also pull updates allowing me to use my FOG server as a local YUM repo as well. If interested in doing so change the rsync path to be rsync://mirrorurl/centos/ instead. This will make the amount of data downloaded much greater, but will later let you use the FOG server as a YUM repo. I placed the rsync command above in my crontab -e without the -P switch for rsync and have it sync once a day. Doing so is a bit beyond the context of this guide though.

Also note that if the mirror is down the command can fail, you may need to switch to another mirror or if setting up cron having it sync multiple mirrors just in case.

Adding iPXE entry:

From the FOG web GUI, create a new iPXE entry (or edit an existing one) as follows:

1. Menu Item: name as desired (ex: os.centoslatest)
2. Description: as desired (ex: CentOS 7.5.1804 - Install). Note: This is what is seen in the iPXE menu on the host machine!
3. Parameters:

Manual or rsync without wanting YUM server too:

kernel http://${fog-ip}/os/centos/7.5.1804/images/pxeboot/vmlinuz
initrd http://${fog-ip}/os/centos/7.5.1804/images/pxeboot/initrd.img
imgargs vmlinuz initrd=initrd.img root=live:http://${fog-ip}/os/centos/7.5.1804/LiveOS/squashfs.img repo=http://${fog-ip}/os/centos/7.5.1804
boot || goto MENU

With rsync pulling all data for YUM:

kernel http://${fog-ip}/os/centos/7.5.1804/os/x86_64/images/pxeboot/vmlinuz
initrd http://${fog-ip}/os/centos/7.5.1804/os/x86_64/images/pxeboot/initrd.img
imgargs vmlinuz initrd=initrd.img root=live:http://${fog-ip}/os/centos/7.5.1804/os/x86_64/LiveOS/squashfs.img repo=http://${fog-ip}/os/centos/7.5.1804/os/x86_64
boot || goto MENU

4. Menu Show With: as desired.
5. Save changes

Alternate directions here.

ESXi 6.5 U1 and 6.7

Works with: UEFI (BIOS booting is only possible if you compile your own undionly.kpxe iPXE kernel to include the IMG_COMBOOT parameter. FOG does not ship with an iPXE kernel supporting this. I have not tested this and compiling is outside the scope of this guide)

To start we need the installation files in our /tftpboot/os/esxi directory. This can be done by manually copying the required content from an ESXi iso. The following will presume ESXi 6.7 but altering the version to your desired version in the steps should work.

Using Files from ISO:

1. Create the directory for CentOS/version if it doesnt already exist:

mkdir -p /tftpboot/os/esxi/6.7

2. Mount the ISO and copy the required files to the above directory:

mount /{path to the iso}/filename.iso /mnt/iso/
cp -R /mnt/iso/* /tftpboot/os/esxi/6.7
umount /mnt/iso

Preparing ESXi Media for PXE

ESXi is a bit unique in that we need to modify some of its files to work with PXE booting. This seems to be one of the bigger areas of confusion for those trying to setup iPXE to boot ESXi.

The file to modify is boot.cfg and ESXi has 2 of these files, one is used for BIOS booting and the other for UEFI booting. We are only concerned with the UEFI version of the file, but it may be worthwhile to do both to avoid issues or if you do want to compile your own kernel to support BIOS installs.

The UEFI version of the file is located at /tftpboot/os/esxi/6.7/efi/boot/boot.cfg

I will be editing it with vi/vim but you can use whatever text editor you like:

1. First we need to remove all of the / characters from the boot.cfg file using:

sed -i.org 's&/&&g' /tftpboot/os/esxi/6.7/efi/boot/boot.cfg

2. Open the file to edit:

vi /tftpboot/os/esxi/6.7/efi/boot/boot.cfg

3. add the prefix line between timeout and kernel (change FOG-IP to your FOG servers IP address, ie: 10.0.0.2…hostname may work too):

prefix=http://FOG-IP/os/esxi/6.7/

4. change the kernelopt line to:

kernelopt=runweasel

5. Save and close the boot.cfg

Adding iPXE entry:

From the FOG web GUI, create a new iPXE entry (or edit an existing one) as follows:

1. Menu Item: name as desired (ex: os.esxilatest)
2. Description: as desired (ex: ESXi 6.7 A01 - Install (UEFI Only). Note: This is what is seen in the iPXE menu on the host machine!
3. Parameters:

Supporting only UEFI:

iseq ${platform} efi && goto esxi67_efi || goto esxi67_bios
:esxi67_efi
kernel http://${fog-ip}/os/esxi/6.7/efi/boot/bootx64.efi -c http://${fog-ip}/os/esxi/6.7/efi/boot/boot.cfg
boot || goto MENU
:esxi67_bios
prompt --timeout 30000 Host must be UEFI booted for this option. Press any key to return to the menu... && goto MENU || goto MENU

Supporting BIOS and UEFI (assuming you compiled your own kernel for it to work and edited both the /tftpboot/os/esxi/6.7/efi/boot/boot.cfg and /tftpboot/os/esxi/6.7/boot.cfg files as per the above steps):

iseq ${platform} efi && goto esxi67_efi || goto esxi67_bios
:esxi67_efi
kernel http://${fog-ip}/os/esxi/6.7/efi/boot/bootx64.efi -c http://${fog-ip}/os/esxi/6.7/efi/boot/boot.cfg
boot || goto MENU
:esxi67_bios
kernel http://${fog-ip}/os/esxi/6.7/mboot.c32 -c http://${fog-ip}/os/esxi/6.7/boot.cfg
boot || goto MENU

4. Menu Show With: as desired.
5. Save changes

Alternate directions here.

Windows 7, Windows 10, Windows Server 2012 R2, Windows Server 2016

Works with: UEFI or BIOS (Windows 7 only with BIOS in my testing, hypothetically could be modified to UEFI boot))

To start we need the installation files in our /tftpboot/os/win directory. This can be done by manually copying the required content from a Windows iso. I will be providing directions for Windows 10 Pro x64, but the same general steps apply to all versions of Windows mentioned in this posts “title” and likely other versions as well. I had only tested x64 versions for myself.

Using Files from ISO:

1. Create the directory for Windows/version if it doesnt already exist:

mkdir -p /tftpboot/os/win/10

2. Mount the ISO and copy the required files to the above directory:

mount /{path to the iso}/filename.iso /mnt/iso/
cp -R /mnt/iso/* /tftpboot/os/win/10
umount /mnt/iso

Preparing Windows for PXE:

See the post on WinPE. It is assumed going forward that you have a working WinPE image that connects to the Samba share setup in the first post, correctly pointed to the version of Windows to install and with the proper drivers injected to run.

Adding iPXE entry:

From the FOG web GUI, create a new iPXE entry (or edit an existing one) as follows:

1. Menu Item: name as desired (ex: os.winlatest)
2. Description: as desired (ex: Windows 10 Pro - Install). Note: This is what is seen in the iPXE menu on the host machine!
3. Parameters:

iseq ${platform} efi && goto win10_efi || goto win10_bios
:win10_efi
kernel http://${fog-ip}/os/win/wimboot gui
initrd --name segmono_boot.ttf http://${fog-ip}/os/win/10/amd64/media/Boot/Fonts/segmono_boot.ttf segmono_boot.ttf
initrd --name segoe_slboot.ttf http://${fog-ip}/os/win/10/amd64/media/Boot/Fonts/segoe_slboot.ttf segoe_slboot.ttf
initrd --name segoen_slboot.ttf http://${fog-ip}/os/win/10/amd64/media/Boot/Fonts/segoen_slboot.ttf segoen_slboot.ttf
initrd --name wgl4_boot.ttf http://${fog-ip}/os/win/10/amd64/media/Boot/Fonts/wgl4_boot.ttf wgl4_boot.ttf
initrd --name BCD http://${fog-ip}/os/win/10/amd64/media/EFI/Microsoft/Boot/BCD BCD
initrd --name boot.sdi http://${fog-ip}/os/win/10/amd64/media/Boot/boot.sdi boot.sdi
initrd --name boot.wim http://${fog-ip}/os/win/10/amd64/media/sources/boot.wim boot.wim
boot || goto MENU
:win10_bios
kernel http://${fog-ip}/os/win/wimboot gui
initrd --name segmono_boot.ttf http://${fog-ip}/os/win/10/amd64/media/Boot/Fonts/segmono_boot.ttf segmono_boot.ttf
initrd --name segoe_slboot.ttf http://${fog-ip}/os/win/10/amd64/media/Boot/Fonts/segoe_slboot.ttf segoe_slboot.ttf
initrd --name segoen_slboot.ttf http://${fog-ip}/os/win/10/amd64/media/Boot/Fonts/segoen_slboot.ttf segoen_slboot.ttf
initrd --name wgl4_boot.ttf http://${fog-ip}/os/win/10/amd64/media/Boot/Fonts/wgl4_boot.ttf wgl4_boot.ttf
initrd --name BCD http://${fog-ip}/os/win/10/amd64/media/Boot/BCD BCD
initrd --name boot.sdi http://${fog-ip}/os/win/10/amd64/media/Boot/boot.sdi boot.sdi
initrd --name boot.wim http://${fog-ip}/os/win/10/amd64/media/sources/boot.wim boot.wim
boot || goto MENU

Note: for something like Windows 7 that may not be able to UEFI boot, you can do something like (for the efi label, similar to ESXi examples):

:win7_efi
prompt --timeout 30000 Host must be BIOS booted for this option. Press any key to return to the menu... && goto MENU || goto MENU

4. Menu Show With: as desired.
5. Save changes

Alternate directions here.

WinPE

Preparing Windows for PXE

Windows requires some additional setup to PXE boot. First off it will load WinPE which in turn runs the setup of the desired Windows version. This part of the guide will detail how I do this, what adjustments you may consider and I will provide other links to supporting information.

When WinPE boots, we have it run startnet.cmd which is a batch file in the WinPE image containing commands to connect to our Samba share and get the instillation files to run the install. At least thats the basic description, it can be scripted to do much more.

The first thing for us to do is create a custom WinPE image. I use a batch file to do this. Following is the overall setup required to do this.

Requirements

• Windows machine (I use a Server 2016 box, you may use Windows 10 or possibly other versions).
• Windows ADK installed (Official link here). Usually the latest available, 1803 as of this post.
• WinPE10 Driver Pack (Official link here). More info found here. Despite being from Dell, they are generically useful it seems. Feel free to check with your OEM to see if they have their own packs. My guide presumes this file however.

I am not going to cover the installation of ADK, as many sources including some links I have provided detail it. After installation dism should be usable from the command line on the Windows machine.

Whatever media you want to use to PXE install Windows, you will want to copy the iso contents including install.wim and boot.wim to the Windows machine we are prepping from to get information about it. Run the following command on the install.wim file:

Dism /Get-WIMInfo /WimFile:C:\pathtowinfiles\sources\install.wim
Dism /Get-WIMInfo /WimFile:C:\pathtowinfiles\sources\boot.wim

replacing C: and pathtowinfiles with your drive and path to the root of the ISO contents. This command will list all of the images in the wim file along with index number(s) which we will need in our script to point to the correct install. You could for example have an ISO for Windows 10 Pro x64 with the ability to install many different versions of Windows 10. Its possible the one you want has the index number 1 or 5 or 7, etc. This command lists them all and lets us find out which index number to use later.

Generating WinPE Image with Batch File

My batch file to generate the WinPE image is based on the post found here (Thanks to @Quazz). I have adjusted it to meet my needs, which may or may not benefit you. I took out the x86/x64 portion and assume x64. I also added a portion to check if the destination folder exists and to delete it if it does prior to running. I also added a loop mechanism to the mounting of the share in case it fails (as for me it 99% of the time eventually connects). I also added a line to inject the WinPE10 drivers from the driver pack.

@echo off

rem The fileserver IP
set FILESERVER=10.0.0.2

rem Share on the fileserver.
set SHARE=pxeshare\os\win\10

rem Username for the share
set SHAREUSER=fogpxeu

rem Password for the share
set SHAREPASS=yourpassword

rem amd64 or x86
set ARCH64=amd64

rem Path to hold working files. Needs about 500MB of free space.
set PEPATH64="D:\winpe\%ARCH64%"

rem ##########################################################
rem     Don't edit anything below here
rem ##########################################################

rem *********** x64 ***********************

echo Remove old amd64 directory
IF EXIST %PEPATH64% rmdir /S /Q %PEPATH64%

echo Creating the PE image
call copype.cmd %ARCH64% %PEPATH64% > NUL

echo Mounting the image
dism /Mount-Wim /WimFile:%PEPATH64%\media\sources\boot.wim /index:1 /MountDir:%PEPATH64%\mount /quiet

echo Adding commands to the startup script in PE
echo. >> %PEPATH64%\mount\windows\system32\startnet.cmd

echo :loop >> %PEPATH64%\mount\windows\system32\startnet.cmd
echo ping %FILESERVER% >> %PEPATH64%\mount\windows\system32\startnet.cmd
echo net use i: \\%FILESERVER%\%SHARE% /user:%SHAREUSER% %SHAREPASS% ^|^| goto :loop >> %PEPATH64%\mount\windows\system32\startnet.cmd

echo i: >> %PEPATH64%\mount\windows\system32\startnet.cmd

echo i:\setup.exe >> %PEPATH64%\mount\windows\system32\startnet.cmd

echo Creating the pxeboot directory
mkdir %PEPATH64%\pxeboot > NUL
mkdir %PEPATH64%\pxeboot\Fonts > NUL
copy /y %PEPATH64%\mount\windows\boot\Fonts\*.* %PEPATH64%\pxeboot\Fonts\ > NUL
copy /y "%WinPERoot%\%ARCH64%\Media\Boot\boot.sdi" %PEPATH64%\pxeboot\ > NUL
copy /y "%WinPERoot%\%ARCH64%\Media\Boot\BCD" %PEPATH64%\pxeboot\ > NUL

echo Adding WinPE Driver Pack
dism /add-driver /image:D:\winpe\amd64\mount /driver:C:\Users\user\Downloads\winpe_3620\x64 /recurse /forceunsigned

echo Unmounting the image
dism /unmount-Wim /MountDir:%PEPATH64%\mount /Commit /quiet

echo Optimizing the image
imagex /EXPORT %PEPATH64%\media\sources\boot.wim 1 %PEPATH64%\pxeboot\boot.wim > NUL

echo.
echo All the files you need for your PXE server are in: %PEPATH64%\pxeboot\

The script should have its variables adjusted as needed, including IP, share path (remember this is a Samba share on the FOG server), and smb user and password. Change the index # in the script to match the index number discovered with the dism commands earlier in this post. Adjust any paths to match the drive and path you have on your machine to the needed contents.

Warning!!

Be aware that the username AND password for that user for Samba will be visible when PXE booting on the screen. This is why I do not use a user that can login to the server. Its a limited account I use only for connecting to the share from WInPE and I dont care if others PXE booting know the password as the only thing they can do with it is connect to the share. If anyone knows of a way to prevent the credentials from appearing when startnet.cmd runs let me know.

I run this batch file using the following command:

cmd /k winpe.bat

This will run it and leave the command window open until complete, making it easier to follow the process and troubleshoot issues.

Presuming it completes as intended, the result will be a folder called amd64. I simply copy this whole folder to the /tftpboot/os/win/10 directory on my FOG server. Many of the files we reference in the iPXE menu entry will be within this folder (and its subfolders). I also copy the boot.wim over as it has had the drivers from the driver pack injected.

I repeat this batch file for each version of Windows I want to install via PXE, editing the batch with correct paths, files, etc for that version.

Fedora Workstation 28

Works with: UEFI or BIOS

To start we need the installation files in our /tftpboot/os/fedora/ws28 directory. I was unable to find an ISO with the proper file structure to allow instllation, so instead I did an rsync to get the files needed. I will provide the directions for using the ISO in case it works for others. A list of official Fedora mirrors can be found here. The following presumes Fedora Workstation 28 but could apply to other versions and spins.

You do not have to do the steps in BOTH “Using Files from ISO” and “From rsync”, its one or the other.

Using Files from ISO:

1. Create the directory for fedora if it doesnt already exist:

mkdir -p /tftpboot/os/fedora/ws28

2. Mount the ISO and copy the required files to the above directory:

mount /{path to the iso}/filename.iso /mnt/iso/
cp -R /mnt/iso/* /tftpboot/os/fedora/ws28
umount /mnt/iso

Using rsync:

1. Create the directory for fedora if it doesnt already exist:

mkdir -p /tftpboot/os/fedora/ws28

2. run the rsync command using a rsync url from the list of mirrors you want to use. This can take hours to run:

rsync -avzP --log-file=/var/log/rsync_cron/rsync_fedora_ws28_mirror.log --delete rsync://mirrorurl/pub/fedora/linux/releases/28/Workstation/x86_64/os/ /tftpboot/os/fedora/ws28

Change the rsync path to your selected rsync mirrors path and adjust the lof path/filename as desired. I placed the rsync command above in my crontab -e without the -P switch for rsync and have it sync once a day. Doing so is a bit beyond the context of this guide though.

Also note that if the mirror is down the command can fail, you may need to switch to another mirror or if setting up cron having it sync multiple mirrors just in case.

Adding iPXE entry:

From the FOG web GUI, create a new iPXE entry (or edit an existing one) as follows:

1. Menu Item: name as desired (ex: os.fedoraws)
2. Description: as desired (ex: Fedora Workstation 28 - Install). Note: This is what is seen in the iPXE menu on the host machine!
3. Parameters:

kernel http://${fog-ip}/os/fedora/ws28/images/pxeboot/vmlinuz
initrd http://${fog-ip}/os/fedora/ws28/images/pxeboot/initrd.img
imgargs vmlinuz initrd=initrd.img repo=http://${fog-ip}/os/fedora/ws28
boot || goto MENU

4. Menu Show With: as desired.
5. Save changes

Alternate directions here.

9
Reserved for updates

8
Reserved for updates

7
Reserved for updates

6
Reserved for updates

5
Reserved for updates