Use dnsmasq on the fog server to supply the pxe boot information.

The quick steps are this.

1. Remove the pxe boot information from your router.
2. Install dnsmasq service from your linux distribution’s repo
3. Make sure its at least version 2.76 by issuing this command at the fog server’s linux command prompt sudo dnsmasq -v The version needs to be 2.76 or later.
4. Create a configuration file called ltsp.conf in /etc/dnsmasq.d directory.
5. Paste this content into that file.

# 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

# inspect the vendor class string and match the text to set the tag
dhcp-vendorclass=BIOS,PXEClient:Arch:00000
dhcp-vendorclass=UEFI32,PXEClient:Arch:00006
dhcp-vendorclass=UEFI,PXEClient:Arch:00007
dhcp-vendorclass=UEFI64,PXEClient:Arch:00009

# Set the boot file name based on the matching tag from the vendor class (above)
dhcp-boot=net:UEFI32,i386-efi/ipxe.efi,,<fog_server_IP>
dhcp-boot=net:UEFI,ipxe.efi,,<fog_server_IP>
dhcp-boot=net:UEFI64,ipxe.efi,,<fog_server_IP>

# 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.kpxe
pxe-service=X86-64_EFI, "Boot to FOG UEFI", ipxe.efi
pxe-service=BC_EFI, "Boot to FOG UEFI PXE-BC", ipxe.efi

dhcp-range=<fog_server_IP>,proxy

6. Be sure to replace <fog_server_ip> exactly with the IP address of your fog server. Be aware that <fog_server_ip> appears multiple times in the config file.
7. Save and exit your text edit.
8. Issue the following command to restart dnsmasq service sudo systemctl restart dnsmasq
9. Ensure that dnsmasq service is running in memory by issuing this command ps aux|grep dnsmasq. You should see more than one line in the response. If its running then go to step 10.
10. Ensure that dnsmasq starts when the system is rebooting with sudo systemctl enable dnsmasq
11. PXE boot a target computer.

NOTE: If you are supporting multiple foreign subnets (not on the same subnet as your dnsmasq server, you will need to add additional with dhcp-range statements that properly describe that foreign network segment. If you fail to do this the dnsmasq server will not respond to the request from your dhcp-relay service an example of what is needed is below:

dhcp-range=<fog_server_IP>,proxy
dhcp-range=192.168.100.0,proxy,255.255.255.0
dhcp-range=172.16.45.0,proxy,255.255.255.0

Dhcp option 93 to hardware type table

DHCP option 93 Client architecture|
0 Standard PC BIOS
6 32-bit x86 EFI
7 64-bit x86 EFI
9 64-bit x86 EFI (obsolete)
10 32-bit ARM EFI
11 64-bit ARM EFI

Introduction

First I have to say this article contains the results of many brilliant people and is not my content. I’m only assembling this information into a consistent document instead of spread around buried in posts and responses. My intent is to not dig into the details behind the scripts or how to tweak them for your needs. You can read the links below to figure out why things are being done the way they are. I wanted to create a tutorial that was as close to a cut and paste to get driver injection going in your environment. Now I will primarily focus on Dell hardware for the main reason that Dell does supply driver archive files (known as .CABs) that can be downloaded and extracted quickly to create the driver structure. I’m sure that HP, Lenovo, and others have similar driver packs.

You can download the Dell driver cabs for your hardware from here: http://en.community.dell.com/techcenter/enterprise-client/w/wiki/2065.dell-command-deploy-driver-packs-for-enterprise-client-os-deployment

Reference links:
https://forums.fogproject.org/topic/4278/utilizing-postscripts-rename-joindomain-drivers-snapins
https://forums.fogproject.org/topic/7740/the-magical-mystical-fog-post-download-script-under-construction
https://forums.fogproject.org/topic/7740/the-magical-mystical-fog-post-download-script
https://forums.fogproject.org/topic/8878/fog-drivers-script-will-not-run-correctly-in-postdownloadscripts/46

In this series if posts I plan on outlining what the FOG post download script is, what its about, and how to use it to your advantage with image deployment.

I’ve debated with myself if another post was needed since Lee https://forums.fogproject.org/topic/4278/utilizing-postscripts-rename-joindomain-drivers-snapins and I https://forums.fogproject.org/topic/7391/deploying-a-single-golden-image-to-different-hardware-with-fog have written tutorial about them in the past.

Where I want to explore with this series of posts is more about the background behind its function and to cover some of the script elements from Lee’s and my previously linked tutorials.

First of all lets get a little background here and some terminology defined. The FOG image deployment system consists of three main components:

1. The FOG management environment. The FOG management environment is the FOG server itself, which is responsible for planning, scheduling, instructing and documenting the image deployment.
2. The FOS (FOG OS) target engine {need better name here}. The FOS target engine, or FOS (as it will be known in this document) is responsible for capturing and deploying images from the defined storage node, as well as other actions on the target computer. FOS is actually an FOG Project created high performance linux operating system that was specifically constructed to image target computers. We have to remember for the rest of the tutorial, FOS is a linux based operating system that is used to deploy any OS image to your target computer.
3. FOG Client. This is an add on utility service for windows and linux, which is installed on the final or target OS. The FOG Client queries the FOG server for instructions and actions. I’m not planning on discussing the FOG client during this tutorial since it is out of scope in regards to post installation scripting.

The FOG Post install scripts give FOG system admins the ability to inject actions in the image creation process. To allow this custom scripts to run the developers added an external call into the image deployment sequence. Just after the image is placed on the target computer’s storage device, the FOG server calls a script in the /images/postdownloadscripts directory (on the FOG server). That script is called fog.postdownload. The fog.postdownload script is created when the FOG Server is installed. In its default state the script doesn’t do anything much. It is just a place holder to call your custom post install scripts. As I mentioned the fog deployment process calls this fog.postdownload bash script just after the image is placed on the target computer’s storage device. Once all of the external post install scripts have completed the FOG server completes the imaging and data recording steps.

While the post install scripts are stored on the FOG server in the /images/postinstall directory, they are executed by FOS running on the target host. So you have to remember when writing your post install scripts, they execute from the perspective of the target host. The post install scripts have limited access to resources on the FOG server (outside of the /images directory), but have full access to the target host. As noted above, these scripts run on a linux OS, so any resource (programs) available to linux operating systems can be run against the target host. I want to make this distinction to make it clear that FOS is linux and not MS Windows based. So you can not run MS Windows based applications, like DISM, in your post install script. FOS and linux is very powerful, but also limiting in some ways. As long as you are aware that MS Windows based applications can not run in a post install script then you should have little trouble. There are some cross over applications that are compiled for both MS Windows and linux, you just need to ensure you have the correct application for the OS and architecture (IA32 or X64).

Setting up the foundation for installation

Hopefully this setup will be pretty clean and easy (just hoping…)

In this tutorial, I’ve personally setup each distribution and booted it into a virtual machine. I didn’t run the installer to completion, but I did ensure the installer was running as far as I took the install (unless otherwise noted).

These setups were only tested with a bios (legacy mode) target computer. They WILL NOT work with uefi systems. For uefi based systems they have their own kernel requirements and options. The intent of this tutorial was to show its possible to boot your installation media via pxe booting.

First we need to setup the storage locations for our boot images. The plan is to put the installation media on the /images nfs share and the boot kernel and initfs in the tftp boot directory.

mkdir /images/os
mkdir /tftpboot/os
mkdir /mnt/loop

For the foundation setup that should do it. On to the OS specific configuration…

Link to Windows 7 & Windows 10 BIOS Mode Only
Link WinPE 10 for BIOS and UEFI based systems
Link to Centos 7
Link to Ubuntu 16.04.03
Link to Ubuntu Desktop 19.10
Link to Ubuntu Server 19.10
Link to Ubuntu 17.10 Desktop
Link to Ubuntu 16.04.03
Link to Linux Mint 18.1
Link to Linux Mint 19.1 Cinnamon
Link to Debian 9.2
Link to OpenSuSE Leap 42.3
Link to Fedora Workstation v26
Link to Fedora Workstation v27
Link to Ubuntu Desktop 17.10
Link to installing Samba on your FOG server
Link to Kali Live 2017.3
Link to ESXi v6.5u1
Link to ESXi v6.7u2
Link to SystemRescueCd 5.2.2 x64
Link to GParted 0.33.0 x86
Veeam Agent Rescue DVD
Acronis 2018 (WinPE version)
Paragon Hard Disk Manager
Parted Magic version from May 2023

The developers found this issue to why the log file grew so big (after almost a year of log file collection). The log file will now be capped at the log file maximum set by the fog configuration settings. This was just a fluke case that caused this file to grow to an abnormal size.

The fix / log file limiting code will be in 1.3.5RC11 when its released.

What you need to understand that the FOS Engine (the customized linux operating system that captures and deployed images on the target computer) is a complete linux OS. It is built with 2 halves. The first part is the the kernel (bzImage) which contains the core linux functions as well as the compiled in device drivers. And the second part is the virtual hard drive (inits) which contains the linux utilities, programs, and fog command scripts. When you PXE boot a target computer into the iPXE menu, certain iPXE menu options will send the bzImage and inits files to the target computer. The iPXE menu will also send specific kernel parameters to tell the FOS Engine (linux) how to react when it boots.

You can take the FOS Engine (bzImage and inits) and just as easily boot directly from a usb flash if you use grub as your boot loader. The FOS Engine will boot from the USB stick without requiring the FOG server to be online. The FOS Engine won’t do much without the proper kernel parameters being passed from the FOG server. But in the end FOS is a specialized, high performance, standalone linux OS.

Now for specifics, I don’t have the details from inside FOS, but I suspect there is something in /etc/init.d that calls the main fog script called /bin/fog that script. The fog master script reads in the passed kernel parameters and then selects the proper task to execute.

Preface

The bits I’m going to cover here are the general outline of what needs to be done to create and deploy a hardware independent image across your fleet of computers. In this tutorial I’m going to discuss how to do this with Dell computers. I know this process works with Lenovo, Intel NUC, and a few others with some caveats. I’m going to touch on some steps that you need to do in MDT to build your universal reference image, but I’m not going to discuss how to setup MDT to create your reference images. There are plenty of examples on the internet on how to do this.

This process makes use of a custom script that gets executed post image deployment but prior to the reboot of the FOS client. This step is vial since we need to make some tweaks to the windows environment pre first windows boot. This is the key. I can’t/won’t share that script I created because of my contract with my employer, because it is derived work because of my employment. So that script is intellectual property of my company. I’ve held the job title of unemployed, its not a great title. The pay stinks, the stress level is high, but the hours are great. I don’t plan on going there any time soon, so no script for you. BUT, sitting here on my zorin (ubuntu) dell laptop I should be able to reverse engineer the important parts to give the crafty scripters here the tools they need to create their own post install script.

Our master image is created following the standard Microsoft SOE guidelines, meaning MDT to build the reference image, sysprep to reseal the image, use a custom unattend.xml file (required to make this process work for Win10) and some disk imaging tool to capture and deploy the image to the target hardware. In this process sysprep is mandatory since we want to create a single image that can be deployed to any hardware. The generalize process of sysprep removes all hardware references (for the reference image) so that when windows first boots it goes through the hardware discovery process. Without sysprepping the image the process I’m going to discuss will not work. So use sysprep.

When I started out creating this process for FOG, I began with the process we created for deploying Windows XP from a usb stick using Ghost. In that process we would automate the image deployment with ghost to lay a hardware independent image onto the target hardware and then detect the current hardware using a DOS program that would query smbios to get the target hardware. Then once the target hardware was known we would move the correct driver pack into a location where windows would find it on the first boot. This worked extremely well with Windows XP. So I took the knowledge that I had from that process and tried to do something similar with FOG.

I do have to say I did not think up this entire process all by my self. I did start the design base on the information found on this wiki page. https://wiki.fogproject.org/wiki/index.php?title=Auto_driver_Install This page and associated scripts gave me just what I needed to take our xp/ghost process and covert it to windows 7/FOG. So without that wiki page the remainder could not be possible.

NOTE: Changes in FOG's code since this article was written have made it harder to use NAS' as storage node with FOG. If you use a NAS with FOG 1.5.x and beyond the FOG replicator will continue to cycle and recopy files over and over again.

Part 1 NAS Setup

So far I’ve setup what should work from the synology NAS side of the fog storage node. This has NOT been proven to work just yet. So far the synology nas has been configured to what “should work”. On my test NAS I’m using DSM 6.0.

The following is just my short hand notes that will be used to create the actual tutorial. I’m out of time tonight to complete the docs for this.

The first thing we need to do is setup our NAS with the required network shares. To do this you need access to the Synology NAS’s web console. Log into the web console as admin and do the following.

1. Control Panel->Shared Folder
   Create new share
   Name: images
   Location: volume 1
   Checked Hide this shared folder in My Network Places
   Checked Hide sub-folders and files from users without permissions
   Press OK
   NFS Permission (tab)
   Create new Permission
   Hostname or IP: *
   Privilege: Read/Write
   Squash: No mapping
   Security: sys
   Checked Enable asynchronous
   Checked Allow users to access mounted subfolders

2. Control Panel->Shared Folder
   Create new share
   Name: snapins
   Location: volume 1
   Checked Hide this shared folder in My Network Places
   Checked Hide sub-folders and files from users without permissions
   Press OK
   NFS Permision (tab)
   Create new Permission
   Hostname or IP: *
   Privilege: Read/Write
   Squash: No mapping
   Security: sys
   Checked Enable asynchronous

3. Control Panel->Shared Folder
   Create new Share
   Name: tftpboot
   Location: volume 1
   Checked Hide this shared folder in My Network Places
   Checked Hide sub-folders and files from users without permissions
   Press OK
   NFS Permission (tab)
   Create new Permission (we only need this nfs shared for setting up the storage node)
   Hostname or IP: *
   Privilege: Read/Write
   Squash: No mapping
   Security: sys
   Checked Enable asynchronous

4. Control Panel->File Services
   Select Win/Mac/NFS (tab)
   Checked Enable NFS

5. Control Panel->File Services
   Select FTP (tab)
   Checked Enable FTP service (no encryption)
   Checked Use the default port range

6. Control Panel->File Services
   Select TFTP (tab)
   Checked Enable TFTP service
   TFTP root folder: tftpboot (this is the share name we created above)

7. Control Panel->User
   Select User (tab)
   Create user foguser
   Name: foguser
   Description: FOG User
   Password: fogremote1 (pick your own secure password)
   Conform Password: fogremote1
   Checked Disallow the user to change account password
   Press Next
   Join to group: users
   Press Next
   images: RW
   snapins: RW
   tftpboot: RO
   Press Next
   (Assign quota as needed)
   Press Next
   Assign application permissions: None
   Press Next
   Speed limiting: None
   Press Next
   Press Apply

8. Control Panel->User
   Select the Advanced (tab)
   (scroll way at bottom)
   Under User Home
   Checked Enable user home service
   Press Apply

That completes the setup of the Synology NAS.

In the next part we’ll test the network shares we setup above and create the remaining flag files and directory structure needed to transform the Synology NAS into a FOG storage node.

Sometimes when we can’t understand why the pxe booting process is going sideways and we’ve touched on the common causes, the easiest solution is to setup the FOG server to eavesdrop on the dhcp setup process between the dhcp server and pxe booting client.

This process will work perfectly if the fog server, dhcp server, and pxe booting client are in the same broadcast domain (IP subnet, network, vlan). It will work if your fog server and pxe booting client are on the same subnet too, its just not as clean of a trace. And the last way to achieve this is to use a second computer running wireshark on the same subnet as the pxe booting computer. Setting up the wireshark filters are similar to the tcpdump filters, but that is a bit beyond the scope of this tutorial.

This is going to be a pretty low impact test. We just want to capture a packet trace of the pxe booting process to the error.

First a little background. The DHCP protocol is broadcast based. That means that discovery, offer, request and ack are all sent as broadcast messages (because the client doesn’t have an IP address during this process). Knowing this fact we can eavesdrop on the communication between the dhcp server and pxe client with the FOG server as long as all three are in the same broadcast domain, subnet, vlan, etc.

So what we need to do is this:

1. Install tcpdump on your FOG server from your linux distributions repository.
2. Start tcpdump on the FOG server’s linux console with this command tcpdump -w output.pcap port 67 or port 68 or port 69 or port 4011
3. PXE boot the target computer until you see the error or the FOG iPXE menu
4. Wait about 5 seconds then hit ctrl-C on the FOG server’s linux console.
5. You can review the pcap with Wireshark or upload it to a developer/moderator for their review.

Just a quick sidebar: We are telling tcpdump to write the output of the packet capture to output.pcap. And we have setup some filters because we only care about dhcp (port 67 and 68), tftp (port 69), and dhcpProxy (4011). One thing you should do is keep the time when you start tcpdump and start the pxe boot process on the client as short as possible. Because if you have a busy dhcp network we may key in on the wrong dhcp boot process. So you want to start tcpdump and then right away start the target pxe booting.

We have seen (sometimes) the FOG Admin will use/change/modify the linux user fogproject’s user account properties and password (note: versions prior to 1.5.6 use fog as account name). This is generally a bad idea to use a service account for normal system maintenance. In fog’s case if someone outside of the FOG installer changes this account your fog installation will become broken.

Understand this linux user account fogproject (fog if you run 1.5.5 and earlier versions) is not the same as the default WebGUI administrator of the same name (fog). We are discussing resetting fog’s linux service account fogproject.

You will typically see this error when trying to capture an image to the FOG server. FOG will throw an error like:

Reattempting to update Database.... Failed

or

Message: ftp_login(): Login incorrect., Host: xx.xx.xx.xx, Username: fogproject

The following is the procedure for resyncing the fog service account. This must be done while logged in using a linux user account other than fogproject

1. Review the file /opt/fog/.fogsettings (this is a hidden file)
2. In that file there is a entry called password=
3. Capture that password. You will need it to reset the FOG server.
   Hint: I can tell you its much easier to do these steps by connecting to your fog server using putty from a windows computer. Copy and paste works great using putty (free terminal program).
4. Now reset the linux user fogproject’s password with sudo passwd fogproject
5. Now go to the FOG WebGUI and FOG Configuration->FOG Settings->TFTP Server and ensure the password listed in FOG_TFTP_FTP_PASSWORD matches the password you collected in step 2.
6. While still in the FOG WebGUI goto Storage Management->All Storage Nodes select the default or storage node in question.
7. Ensure that Management Password matches the password you collected in step 2.
8. Now finally back in the linux console of the fog server, navigate to where your fog installer files are (typ either /root/fogproject or /opt/fogproject) and rerun the fog installer (./bin/installfog.sh) to realign the remaining bits…

Once these steps have been completed your FOG server should be happy with you again.

@chevengur there is not enough information to help you in that picture. If we could see more of the error message that partclone threw (i.e. just above the top of your picture) we would know what happened. At the point in the script all we know is that partclone wasn’t happy.

@JasonNaughton This is a strange one. The linux kernel just doesn’t just invent mac addresses. It would be interesting to look up the first 6 characters of the mac address to see if you could identify the manufacturer.

So are you saying there are 4 physical nics in this computer. LOM, PCie 1, PCie 2? Does that mac address belong to the LOM?

I can say that we are dealing with 2 kernels here. The iPXE boot loader, and FOS Linux. Its technically possible to get to the fog ipxe menu and then when you start up FOS it doesn’t get an IP address because either the nic order has changed or there is missing firmware that is needed to init certain nics.

@chevengur I can tell you how I would go about figuring this this.

1. Take a computer that represents the finished design of how your disk are laid out.
2. Schedule a deployment to that computer, but before you hit the schedule task button, tick the debug checkbox then schedule the deployment. No worries as long as you pick debug mode since it will never get to the deployment phase.
3. Now pxe boot the target computer, it should boot into the FOS linux console. After a few screens of text you need to clear with the enter key you will be dropped to the FOS linux command prompt.
4. From there issue, the efibootmgr command with no parameters. It should print something similar to below (note this is from my laptop)

thunder@lightning:~$ efibootmgr
BootCurrent: 0005
Timeout: 2 seconds
BootOrder: 0005,0004,0000,0001,0002,0003
Boot0000* UEFI BC511 NVMe SK hynix 256GB SN9BN62231050BJ2H 1	HD(1,GPT,d00df89f-1edb-44f8-b325-245b607b2321,0x800,0x100000)/File(\EFI\Boot\BootX64.efi){auto_created_boot_option}
Boot0001* ONBOARD NIC (IPV4)	PciRoot(0x0)/Pci(0x1f,0x6)/MAC(b44,0)/IPv4(0.0.0.00.0.0.0,0,0){auto_created_boot_option}
Boot0002* ONBOARD NIC (IPV6)	PciRoot(0x0)/Pci(0x1f,0x6)/MAC(b440)/IPv6([::]:<->[::]:,0,0){auto_created_boot_option}
Boot0003* UEFI HTTPs Boot (MAC:B445065BDC4B)	PciRoot(0x0)/Pci(0x1f,0x6)/MAC(b445065bdc4b,0)/IPv4(0.0.0.00.0.0.0,0,0)/Uri(){auto_created_boot_option}
Boot0004* debian	HD(1,GPT,d00df89f-1edb-07b2321,0x800,0x100000)/File(\EFI\debian\shimx64.efi)
Boot0005* Ubuntu	HD(1,GPT,d00df89f-1edb-607b2321,0x800,0x100000)/File(\EFI\ubuntu\shimx64.efi)

You can see from this the default BootOrder is 5, 4, 0, 1, 2, 3 this lists the different boot managers found by the firmware.

So it will boot ubuntu first, then debian, the hard drive, onboard nic v4, onboard nic v6, http boot.

Now lets say I wanted debian to boot first I might issue the command.
efibootmgr -o 4,5, 0,1, 2, 3

Now reboot the computer with the reboot command see if it changes the boot order specific to your options.

After you get this worked out, you will need to clean up this deploy task on your fog server so it doesn’t do this moving forward. But for debugging as long as the fos engine doesn’t complete, every time you reboot the computer will enter the FOS debug console. This helps with debugging and tweaking your post install script.

@chevengur I have not had to do this before, but I can tell you in concept how to go about it.

You will need to create a post install script, that script gets executed just after the image is pushed to the computer and before its rebooted. This script is a bash shell script (remember the FOS engine is linux based).

Since it is linux based you will need to use linux command line tools to reset the boot image. The tool named is efibootmgr. This command is built into FOS linux engine.

So on its simplest form, you will create a FOG post install script and that script will call the efibootmgr to set the boot image. Understand that MS Windows will change this order without notice and at random times during its life.

Its not hard to do, but it will take a little effort on you to work out what is needed.

I can’t give you a step by step on how to do this but I can give you a general direction to look in if you want to go down this path.

@JasonNaughton Looking at the code the error would indicate that the target computer can’t reach the fog server.

https://github.com/FOGProject/fos/blob/8893d32bfb702dcf7b8f5427ccd6748fac15df17/Buildroot/board/FOG/FOS/rootfs_overlay/etc/init.d/S40network#L64

What I want you to do is to pxe boot the computer into debug mode. Schedule a deployment to this computer but before you hit the schedule task button tick the debug checkbox. Now pxe boot the target computer, you will still get the errors but you will be dropped to the fos linux command prompt.

run this command ip a s that should show if your network interface has an IP address. If not then issue this command.
/sbin/udhcpc -i enp128s31f6 --now where enp128s31f6 is the name I gleaned from your screen shot that appears to have picked up an IP address. See if it gets an IP address now. See if you can ping the fog server’s IP address.

The ‘checker’ script makes this call to verify your fog server is reachable.
curl -Ikfso /dev/null "${web}"/index.php --connect-timeout 5 replace the entire ${web} with the IP address of your fog server. See if that returns a value.

Finally search the system messages to see if there is something related to firmware.
grep -i -e firm /var/log/syslog I think syslog is the right file, if it returns nothing try /var/log/messages One error could be the network adapter needs a specific firmware for the network adapter to communicate. That firmware may need to be added to the linux kernel.

@AlexisPHC said in Use serial number as hostname in Fog:

did you ever get round to writing a guide for this?

Yes. I think the previous comment to your post referenced the files.

https://forums.fogproject.org/topic/14278/creating-custom-hostname-default-for-fog-man-reg?_=1762381023512

the file fog.customhostname uses a linux command dmidecode to extract the serial number from the smbios. And the rest of the ‘hack’ will pump that name into the full registration files. When I wrote that script I worked for a company that had a composite host name with the site code, a hardware type and then the dell asset tag appended onto the end. That is what this tutorial shows.

Now Tom mentioned that {SYSSERIAL} in the quick registration field works too. I wasn’t aware of that feature, it must be new. I know FOG version 0.30 had that feature but it was removed when FOG 1.x was released. If its back, that’s great!! that makes my script(s) unnecessary.

@AlexisPHC said in Issues with Windows DHCP Server:

because we run them in HA mode

but there doesn’t seem to be another DHCP server present

My interpretation of these two statements sounds in opposition.

If you are running windows server in HA or failover mode, make sure that both dhcp servers have the dhcp boot options configured. If I remember right these settings are not copied over between the dhcp HA nodes. Understand this might have changed with later releases of dhcp server but with 2016 the pxe boot stuff needed to be set on each node individually.

@AlexisPHC If it magically stops working again, then I would check to see if you have two dhcp servers on your network. If it continues to work, then move on to the next issue. But in general I don’t like it when stuff just starts working, because the tides can shift the other direction with out notice too.

@sega said in FOG Multicast on different VLANs:

Is there something that I can look up, to see where the problem is?

Well your router supporting PIM is a good sign. Some routers have a service called igmp proxy or igmp relay, or even igmp snooping (you will find this more on switches, but check). This service typically has a number of interfaces to listen on and then a master interface where your multicast source lives. Its job is to relay the multicast requests to the proper interface.

PIM has two modes sparse and dense, that may be just for switches, I don’t remember. Sparse mode only sends the multicast traffic to the subscriber’s port, where dense just blasts out the muticast to all ports. You want sparse mode if possible, that way only the ports with a multcast receiver will see the traffic and not flood your network.

@Kram-Man This won’t work. When fog captures an image it also creates a metadata file that describes the target hard drive. Also fog when it captures the image it creates partition base image files, not a monolithic file describing all partitions. Could you do this outside of the fog image capture process, probably. FOG uses partclone and zstd to capture and compress the partitions. You would just need to create the metadata data file that represents the target system layout. Its possible to do, but just creating your golden image and then capturing with fog would be just as quick IMO.