@introloud said in Configure FOG Server's DHCP service?:

I’m gonna try both unicast and multicast to a couple of machines first but I doubt that it’d be any different since it’s on a simple network right now.

This is simple and complex to explain. But a unicast image is sending an image form the fog server to a single target computer. Lets say for example that take 50MB/s of network bandwidth. If you start up a second unicast deployment to a second target computer that will take another 50MB/s of network bandwidth. Now lets add a third simultaneous unicast deployment, Now you are sitting at 150MB/s of network bandwidth usage and 1GbE only has 125MB of available bandwidth, so you will get collisions and throughput slowdowns.

Now lets say you setup a multicast session with those 3 same computers. The image is now being sent out as a multicast. You can have as many receivers as you want, because only one image is being sent out you only consume 50MB/s of network bandwidth. If a receiver is late to the stream, they simply miss the stream and will not be imaged during that streaming session. Using a multicast streaming method you can image 30 computers in about the time it take to image 2 computers using unicasting.

They will be in the same VLAN but probably may have different subnet masks

Strictly speaking you would normally have only one subnet mask per VLAN unless you are doing supernetting for some reason.

imaging task to multiple machines, and have them reboot to get into network boot

Typically you would configure the computers to boot through PXE then boot to the hard drive. That way if FOG had any actions for the computer it could do it while the fog menu is displayed. If there were no jobs then it would just boot the hard drive. You would have the FOG client installed on the target computer so when the schedule task starts the target computer would be instructed to reboot via the fog client program.

@FoxNBeard said in General A to Z support (FOG):

It would install with the Administrator account activated. Through the unattend.xml I was able to figure out how to have it make a second user with administrator priviledges, but I couldn’t seem to solve how to not have the administrator account active and only the user.

Use the setupcomplete.cmd batch file to do this. With something like this in batch

REM Rename the default administrator account to something else
wmic useraccount where name='administrator' rename slipperyjim
net localgroup administrators slipperyjim /add

REM Rename the guest user account
wmic useraccount where name='guest' rename debbiedowner

REM Create a fake administrator account for hackers to bang on
net user Administrator NeG@tiveNancy-F@nT@#13s /ADD /comment:"Built-in account for administering the computer/domain" /PASSWORDCHG:NO /active:NO /Y

REM Be sure to remove from administrators and users groups, add to guest group to limit access
net localgroup Administrators Administrator /delete
net localgroup Guests Administrator /add
net localgroup Users Administrator /delete


REM create new System Admin user
net user sysstarr "1cecr3am-SanWitch0" /add /EXPIRES:NEVER /PASSWORDCHG:NO /active:YES /Y
net localgroup Administrators sysacce55 /add
wmic useraccount where Name='sysacce55' set PasswordExpires=FALSE

REM Disable slipperyjim (real admin/root user account)
net user slipperyjim /active:no

I presume due to limited knowledge, I couldn’t figure out how to let MDT install both updates and applications correctly.

There is a task sequence to apply windows updates. It helps if you have a local WSUS server to cache the packages. When I was just getting started in imaging this site helped out quite a bit. https://www.deploymentresearch.com/

I was wondering if I was able to manually configure a VM and pull an image to FOG that way?

Yes developing your golden image on a VM is the best choice so you can use snapshots to fix o-crap moments while perfecting your golden image.

Hostname was identical to the original machine (Although I think, unless wrongly configured, the hostname changer in FOG was active).

This is true because fog is a block level cloner, it knows nothing about the target system. To use the hostname changer will you will to register the computer with FOG and have the FOG client installed. That is not something you probably want as a system builder. You can have FOG set a name of the computer at deploy time via using a custom FOG post install script that will inject a new host name into the unattend.xml file at deployment time.

Yes I would still sysprep your windows system. For full disclosure I have not had to build an image for Windows 11 yet, so I might be incorrect here. BUT I would also build your golden image so that its protected from getting to the internet. I have seen on windows 10 if the workstation can get to the internet it will try to down stuff causing sysprep to fail.

I would spend my time getting MDT to do what you want it to do to give you the perfect golden image. The capture and deploy with FOG is the easy part (kind of). If you want to do more of the advanced stuff like editing the unattend.xml file on the fly it will take some time but I have examples for that.

@FoxNBeard Quite a few MSPs and system builders use fog for image deployment. So its possible to do, but it WILL take WORK on your side to setup the environment to get an efficient work flow. Once you have everything setup correctly you can go from bare metal to first user login in about 12 minutes. With a 25GB golden image push in about 4.5 minutes, the reset of the time is windows, being windows…

I would first start with a golden image, load all of your common apps into the golden image except Enterprise AV or any app that utillize a unique ID for each device. These apps need to be installed post deployment. You may need one of these golden images per customer if they have different core application mixes. The goal here is to be able to take a bare metal computer to a finished image as quick as possible for a system builder. So spend a little more time on the front end setting up your environment and reclaim the benefits on the back end.

I would suggest that you use Microsoft’s MDT for golden image creation. MDT will take about 1hr to create your golden image because it builds the golden image from the master DVD image, much like you would do by hand, but in an automated manner. Using MDT you will be able to customize your golden image builds on a per customer basis. I know this sounds counter intuitive, but use MDT to build a predictable and repeatable golden image. MDT will install all of the latest windows update if needed for you. Then you will only be out of date from the last time you created the golden image. Capture the golden image with FOG and then use FOG for the one to many deployments. Develop your golden image in a virtual machine environment to make the golden image hardware neutral. If you need hardware specific drivers, fog can place them on the target computer so that Windows OOBE/WinSetup can find and install them.

FOG uses block level cloning, which is super fast but not deploy time flexible. MDT uses file level cloning, which is deploy time flexible but slow. Each tool has its best use case and they fit together well.

In your golden image use an unattend.xml file to configure the workstation, like creating user accounts, tweaking the windows environment, or installing apps. This is all windows os tuning and standard windows deployment, not related to FOG.

Now back to fog, you have the golden image captured and stored in FOG. Normally you need to register each computer you want to image with FOG so you can deploy an image to it. But in your case once you load the target OS on the computer FOG will never see that computer again, so registering and deploying with FOG just adds extra steps. There is a process I use called “Load and Go”. This is where you pxe boot a target computer and pick “Deploy image” from the FOG iPXE menu. You would then select the image and then FOG will deploy to that system without requiring it to be registered. Once the image has been deployed then FOG forgets all about the target system. There are some caveats here like post install activities like deploying snapins (apps) and a few other FOG maintenance functions which you won’t use in your case. So make the golden image fully self contained. FOG will only push the image to the target computer quickly then forget about the computer using the Load and Go method.

So how might you deploy post install apps, use the setupcomplete.cmd or in the unattend.xml file under the auto login / first run section to call Chocolatey to do its thing to the computer.

@errbravosix Would you provide a complete ltsp.conf file because what you provided here shouldn’t have fixed the problem directly,

BUT from the original config, if you would have modified it to this for the pxe-service section:

pxe-service=X86PC,"Boot to FOG (BIOS)",undionly.kpxe,172.16.1.15
pxe-service=X86-64_EFI,"Boot to FOG (EFI)",ipxe.efi,172.16.1.15
pxe-service=BC_EFI,"Boot to FOG (EFI)",ipxe.efi,172.16.1.15

Then that config should have worked. dnsmasq is a bit cryptic with its optional parameters I do have to say.

BUT I can say if you have it working then its working so no need to change anything. Good job finding the solution.

@introloud said in Configure FOG Server's DHCP service?:

I can now edit the /etc/dhcp/dhcpd.conf file to create the configuration files right?

If you picked enable the dhcp server during the fog install it “should” automatically create that file with the proper settings. Make sure when you install fog you start the installer with the linux console, go to the web ui when instructed, then return to the linux console to finish the last part of the setup (which is the spot where the configuration files are created and the /tftpboot directory is populated. If you don’t do that last part your system will not be installed correctly. You can just restart the fog installer and install it again to fix the missing bits.

If I’m understanding correctly, dnsmasq would only supply pxe boot information, leaving the ip assignments to the main dhcp

Yes that is correct, If you use the proper dnsmasq configuration it will put dnsmasq in proxydhcp mode where only the pxe boot information will be supplied to the target computer. https://forums.fogproject.org/topic/12796/installing-dnsmasq-on-your-fog-server If you type slow it takes about 10 minutes to install dnsmasq on your fog server.

@errbravosix The more research I do the more I’m thinking that your config file should just work.

I did put together an alternate configuration for dnsmasq. As long as the dnsmasq server is running on the fog server this config should also justwork.

# 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

# 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-match=set:efi-x86_64,option:client-arch,7
dhcp-match=set:efi-x86_64,option:client-arch,9
dhcp-match=set:efi-x86,option:client-arch,6
dhcp-match=set:bios,option:client-arch,0

# Set the boot file name based on the matching tag from the vendor class (above)
dhcp-boot=tag:efi-x86_64,ipxe.efi
dhcp-boot=tag:efi-x86,i386-efi/ipxe.efi
dhcp-boot=tag:bios,undionly.kpxe

# PXE menu.  The first part is the text displayed to the user.  The second is the timeout, in seconds.
pxe-prompt="Buscando Servidor de Imagens", 5

# 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 (BIOS)",undionly.kpxe
pxe-service=X86-64_EFI,"Boot to FOG (EFI)",ipxe.efi
pxe-service=BC_EFI,"Boot to FOG (EFI)",ipxe.efi

dhcp-range=172.16.1.50,172.16.1.52,255.255.255.0

@introloud When you install FOG it does prompt you if you want to install the dhcp server. You can also do it after the fact. Just install the isc-dhcp server from your linux server’s distro repo. Then refer to this configuration file. Fog would use this template to create the configuration file. Make sure you update the ip addresses specific to your network. https://wiki.fogproject.org/wiki/index.php/BIOS_and_UEFI_Co-Existence#Example_1

Also be aware that you can run dnsmasq to supply the pxe boot only information and still keep your main dhcp server untouched. So if you wanted to connect your fog server to your business network that is also possible.

@errbravosix said in FOG server Withou dhcp services:

dhcp-boot=net:UEFI32,i386-efi/ipxe.efi,172.16.1.15
dhcp-boot=net:UEFI,ipxe.efi,172.16.1.15
dhcp-boot=net:UEFI64,ipxe.efi,172.16.1.15

In your LTSP.conf Update this section to:

dhcp-boot=net:UEFI32,i386-efi/ipxe.efi,172.16.1.15,172.16.1.15
dhcp-boot=net:UEFI,ipxe.efi,172.16.1.15,172.16.1.15
dhcp-boot=net:UEFI64,ipxe.efi,172.16.1.15,172.16.1.15

Lets see if that gives you a successful pxe boot.

@errbravosix said in FOG server Withou dhcp services:

enable the true dhcp on my pfsense, everthing works fine

This is because pfsense is filling out both the bootp and dhcp parts for pxe booting.

dhcp just work on legacy no problem

This can be explained because the legacy bios firmware is probably only looking at the bootp fields and not only looking at dhcp fields for pxe boot info.

The issue “I think” is specifically with dnsmasq and its configuration. There is something missing to tell it to also send dhcp fields and not just boot fields. I’ve just not used dnsmasq this way before I don’t know off the top of my head the answer.

@errbravosix OK I see the problem but not sure right away how to fix.

In the ethernet header we are seeing both the next-server [172.16.1.15] and boot-file [ipxe.efi] fields populated. But there are no dhcp options of 66 and 67. The PXE roms in computers can either look at the header or at the dhcp options or both to find the boot server. Its up to the rom manufacturer where to look.

What dnsmasq is doing at the moment is only filling out the ethernet header fields, this is BOOTP method. and not filling out the DHCP method fields. In your ltsp.conf file the field match is happening because its picking ipxe.efi for the boot file. Whats missing is the sending the dhcp options too. So its 80% working, we just need the remaining 20% to have a functional solution.

@errbravosix From the DISCOVER packet I see this is an EFI system.

What I need to see is in the OFFER, the ethernet header section is there a value for next-server and boot-file? And then in the dhcp options section is there a value for dhcp option 66 and 67? Your screen shot doesn’t show that. We really don’t need the other two packets for seeing what is going wrong.

@errbravosix Your config file looks OK, typically that configuration is used for proxydhcp where dnsmasq only gives the pxe boot information and not dhcp.

But I can tell you that wireshark will be your friend here to see what the client is doing and what its being told. Take wireshark and load it on a witness computer (third computer not part of pxe booting). Set a capture filter of port 67 or port 68 to capture the dhcp info. When you pxe boot you should see the DORA process.

Discover: client
Offer: DHCP server
Request: client
Ack: dhcp server.

In the discover packet the client will tell what it is in dhcp option 93 or 94. .The dhcp server will Offer in next-server and boot-file as well as dhcp option 66 and 67 the boot info.

@Roger-Saffle Using a web browser navigate to http:<fog_server_ip>/fog/service/ipxe/boot.php?mac=00:00:00:00:00:00 that is the text behind the ipxe menu. There must be something wrong with the menu or short name for the custom menu.

@Enigma I asked a few questions in chat, but I’ll reask them here.

1. Is this your fog server’s IP address? 192.168.107.200
2. Your dhcp server isn’t sending dhcp option values, what device is your dhcp server? Your dhcp server needs to be configured to support both bootp (values in the ethernet header that are present in the pcal) and dhcp (missing dhcp options 66 and 67).

@Enigma Would you install wireshark on a witness computer connected to the same subnet (ideally same network switch) as the pxe booting computer? If yes set a capture filter of port 67 or port 68

Start wireshark, then pxe boot the target computer to the error and stop wireshark capture. There should be ~4 dhcp packets captured.

DISCOVER: This is from the client asking to configure me
OFFER: there should be one or more responders. These are the dhcp servers. These are the packets we are interested in. How many offers do you see? Do they have dhcp options 66 and 67 set as well as in the ethernet header next-server and boot-file?
REQUEST: This is the client asking for the full details from the selected dhcp server
ACK: The dhcp server saying that IP address is now yours.

If you can’t figure out the pcap upload it to a file share site and either post the link here or use FOG DM chat to send me the url and I will look at it. The answer has to be “on the wire”.

@Sebastian-Roth I think I was able to solve this with the current buildroot build by just updating what buildroot package it would download to get the new e2fsk code. But I know you are right that we should update to the latest version since FOG is using kernel 6.2 now.

@ArtemZ I would check to make sure your dhcp server has the fog server’s IP address in dhcp option 66. The error message is kind of telling me that.

@Roger-Saffle Add in shutdown=1 into your custom menu parameters. The system will power off after wiping the drive.

@professorb24 said in Can't get pxe boot on my VM (FOG):

me to give out “fake” IP addresses

I think we have a language conflict here.

To use fog, the target computers (the devices where you will deploy your image), must use dhcp to get the pxe boot information. If you don’t have dhcp available for the client computers you will have a difficult time booting over the network. With that said, we do have a method to boot the computes into FOG via a usb boot stick. In this case you will need to take the usb boot drive around to the computers to start the imaging process.

The second issue you have is WDS. Right now FOG and WDS can not both occupy the same IP subnet since they will fight each other for network booting.

@professorb24 said in Can't get pxe boot on my VM (FOG):

and it only boots into WDS

This right here is problem #1. WDS has a net boot service that overrides dhcp settings for pxe booting.

I’m only allowed to use static IP and not can’t use DHCP

Please explain this, do you mean you can’t use dhcp for the fog server ip address assignment or you can’t modify dhcp which is a primary requirement to pxe boot for the target computers?