@mashina said in Providing installation media via pxe booting for UEFI systems.:

I encounter a “Reset System” message and the machine reboots

I can say I’ve never seen this before. When you see this message what is the default boot device? Is it the hard drive or PXE booting. Its not clear if its the UEFI firmware or iPXE/rEFInd (fog’s boot loader) that is throwing this error.

This is only a guess, but I might think it the uefi firmware saying “hey something changed from the last boot” should I fix up the boot settings with the new information?

It would be interesting to know if you reimaged the target computer again with the same FOG image would you also get that message, or do you only get the message when you change image formats (i.e. Windows was previously the boot image and now its ubuntu?)

@jmcooper The fault probably exists with the PXE boot rom on the device.

The answer is probably a bit complicated to explain so I’ll try to keep it simple.

PXE booting can use one of the two protocols bootp or dhcp. Its up to the hardware manufacturer to decide which set of fields it looks at for the pxe boot information.

The second part is kind of a dhcp server / pxe rom issue. On each dhcp/or bootp fields there is a byte counter that tells the pxe rom how many characters are in the field name. Common convention also marks the end of a text string with a null (0x00) character. Its up to the dhcp server and pxe rom programmer to decide which method to use (I’m sure there is an RFC document that describes this). I have personally seen this in which someone was not using a mainstream dhcp server, where it only populated the byte counter field and then never terminated the string with a null character. In this case the pxe rom used the null character as end of string and the name requested from the target computer was ipxe.kpxe<with extra characters at the end until a null byte was found>

While I can explain it, it still sucks that the pxe rom firmware is doing this to you.

@RobertD said in PXE boot - HP Elitebook 650 G10 - No configuration methods succeeded ...:

We have been using ipxe.efi for all of our devices for years so I’m afraid to change all our DHCP scopes to use this loader for this one problematic model. Any suggestions?

Its great that you have a path to boot these system via the snp driver.

You didn’t mention if you updated iPXE to the latest release to see if the ipxe.efi boot loader works once again.

Let me (re)clarify in this thread the differences between ipxe.efi and the snpX.efi boot loaders.

ipxe.efi (uefi) and ipxe.kpxe (bios) contain all of the known drivers built into the boot loader, this makes the iPXE boot loader much larger in file size (in 1990 terms of file size) because it has to carry all known drivers onboard the boot loader. For older systems > 6 years those were the preferred boot loaders for iPXE

snp.efi, snponly.efi (uefi) and undionly.kpxe (bios) use the network adapters built in driver through the generic snp or undi interface. This boot loaders are much smaller than the ipxe.* versions since they only need to have one driver onboard (snp or undi). The undi driver (bios) has been around for 30 years and is the preferred and very stable network interface for bios computers and should always be the #1 choice. The uefi firmware has only been around for 12 years or so. The early version were very buggy so the snp driver did not work well. This is the reason why the fog developers recommended the ipxe.efi boot loader for uefi systems. In the last 6 years or so the snp and uefi firmware has matured to a level where the fog developers are recommending snp.efi or snponly.efi for all modern hardware. For bleeding edge hardware you have a better chance to get the snpX.efi bootloaders to work before the ipxe.efi bootloader, because the iPXE kernel developers will need to add the driver to the bootloader. Its just a timing issue.

Now you might ask what is the difference between the snp.efi and snponly.efi drivers. snponly.efi will only initialize a network interface from where it was loaded from. For example lets say you pxe booting a compute with 4 nics, and you pxe bootin from nic2. The iPXE boot loader would only init nic2 using the snponly.efi bootloader. In contract snp.efi would try to init all nic intefaces starting with 1, 2, 3, and then 4. The issue becomes if nic1 takes the boot loader someplace else other than to the FOG server, since the fog server is on nic2.

@alexpolytech94 The shrinking of the disk when using single disk resizable is a bit of black magic. Sometimes because of the actual data size or location of the data on the disk its not possible to shrink the volume down enough to make it fit on a disk that is 1/2 the size of the source disk. I won’t go into too much detail, but if you have a partition that is fixed in size that can’t shrink, but a partition just before it on the disk that can shrink, fog will shrink the one that can be shrunk but leaves the one that can’t be shrunk as it were. If you were to deploy that image to a computer with half the size that non shrunk partition would be technically beyond the last sector on the 1/2 size disk.

To put it another way, always build your mother image on the smallest disk possible, because it can expand to a larger target disk more often than shrink your image to fit on a smaller disk.

When I was building golden images I would build them on a VM with a 50GB hard drive (smaller than anything I would deploy it to) and then let FOG expand the disk to match the target disk size. That always worked.

@zaboxmaster Well we are going to need your assistance to help debug this. I can give you the steps needed to collect the information to help debug this.

1. Schedule a new deploy/capture task, but before you tick the schedule task button, tick the debug checkbox. Now schedule the task.
2. PXE boot the target computer. After several screens of text you need to clear with the enter key, you will be dropped to the FOS Linux command prompt.
3. This next 3 steps will help with remote debugging and for copying the results out to post here. Key in ip a s and collect the IP address of the target computer.
4. Reset root’s password with passwd Give it a simple password such as hello This password will be reset at the next reboot.
5. Now connect to the target computer using ssh, either ssh from linux or putty from a windows computer.
6. Key in and post the results here of the following commands
   uname -a
lsblk
lspci -nn
grep -i -e firm /var/log/syslog
7. Keep the debugging session open for additional commands.

@Dominique said in PXE boot - HP Elitebook 650 G10 - No configuration methods succeeded ...:

I can build other laptops on that network jack
No new setup, have build hundreds of devices a day.

Ok just trying to establish what the problem isn’t. Ok so you updated your ipxe binaries to the latest version. So that’s good.

Looking at the model this hardware is pretty new (Aug 2023). Are you using the nic built into the chassis of the laptop or an external nic in a dock or usbX attached dongle?

Check to see if there is a firmware update available for this hardware. The snp.efi and snponly.efi boot loaders use the nic driver built into the UEFI firmware. On most modern uefi implementations its very robust and stable and should work right out of the box.

I would try for testing purposes to update dhcp to send ipxe.efi boot loader instead of the snp boot loader. Does that boot loader work? The ipxe.efi boot loader is a lot like the linux kernel where it has most of the common network drivers built into the boot loader.

@Dominique I guess I have a few questions in regards to this

1. Is it just this specific model or all models from this network jack?
2. Is this a new setup with FOG or have you used it successfully before?

From your picture I can see that you have the dhcp server setup correctly, you have secure boot off (or ipxe won’t boot), using snponly.efi will use the built-in driver that is part of the nic. You might try ipxe.efi to see if you have better luck, but snponly.efi or snp.efi is probably the best general purpose boot loader.

The no configuration methods screen is basically saying the ipxe kernel is not getting a dhcp response. I have seen this before if you have standard spanning tree enabled on your building switch. In this case you can check to see if its spanning tree issue, but placing a dumb unmanaged / cheap-o switch (like monoprice 5 port switch for $20) between the building switch and the pxe booting computer. If that solves the problem then its spanning tree causing the issue. Enable one of the fast protocols on your building switch like portfast, fastSTP, RSTP, MSTP or whatever your switch manufacture calls it.

@professorb24 I have a tutorial on how to do this with Dell computers, but the concept is almost the same for other vendors. The key is to have the driver files in inf format so pnputil.exe can install them. Lenovo use to have drivers in .exe format and not .inf format. That made things a bit harder when I was trying to setup lenovo computers.

Looking at the script and it doesn’t appear to do anything. other than mount a wim image, but also be aware that the post install script runs withing a linux environment so it can’t directly interact with windows or the .wim file.

Your post install script should copy the drivers over to the target computer after the image is placed on the target computer. All that FOG can do is leave files behind for windows to find them during OOBE/WinSetup.

@rpeterson I have never personally done this, but in theory it should be possible.

As I see it you will have 3 challenges.

1. your uefi boot firmware will need to use the serial port for communications. If you can interact with the computer’s firmware over serial then that clears the first challenge.
2. The ipxe boot loader needs to support a serial console. I don’t know off the top of my head is that feature turned on or not. If its not we/you can make it happen.
3. Lastly (and hopefully the easiest) we will need to turn on the serial console flags for the FOS Linux kernel. FOS Linux is the engine that captures and deploys images. You just need to google “serial console linux kernel” for the proper command line switches.

Once you achieve all of the challenges then it should be possible to do over just the serial port.

@GorkaAP Ok your explanation is very clear of the problem.

I have a couple of ideas here:

An additional building, located 4 kilometers away, shares the same network subnet.

I have see remote locations connected via a WAN have issue with loading the iPXE boot loaders via tftp. In this case the computers would error out where it can not download the NBF boot file. The issue was related to the tftp block size being larger that the MTU packet size on the WAN. If you are direct conneted between the remote building with fiber this is probably not your issue.

Having both locations on one subnet makes things a bit harder since dhcp works off broadcast domains and your local and remote locations have the same broadcast domain since they are on the same subnet.

The FOG booting process is such
PXE Rom (target computer) boots and queries dhcp to find dhcp options 66 and 67
PXE Rom downloads the bootloader pointed to by options 66 and 67
The iPXE boot loader boots and again queries dhcp for dhcp option 66 to locate the FOG server.
The IPXE boot loader then will chain load to the fog server over tftp default.ipxe
default.ipxe will chain load boot.php.

If you are on the same subnet between the sites and it works at the main campus but not at the remote campus then this is the first time ipxe chain loads to http instead of tftp. From the remote campus can you get to the fog server’s web ui?

It might help to debug if you can snap a clear picture of the error message on the target computer as you get the chain load error.

One additional thing I can think is if you have more than 1 dhcp server within this broadcast domain (such as a primary/slave) make sure both have the proper dhcp option settings. I have see two dhcp servers with one having the setting configured and the other without cause random issues. Whichever dhcp responded first the client would use (one having the proper boot setting and the other without).

Bonus additional thing: You are using dnsmasq to provide pxe boot information. Could there be something filtering out the DHCP Discover packet from the client at the remote site? I can see where/if DNSMASQ would work at the main campus, where the remote campus might not, if the DISCOVER packet is getting lost on its way to the DNSMASQ service. You can test this on the dnsmaq server by using tcpdump and monitoring for port 67 or port 68 Now power on a computer at the remote building, do you see the DISCOVER packet arrive at the dnsmaq server? The DISCOVER packet starts the process in DNSMASQ to send the pxe boot information to the target computer.

Bonus++ thing. If your link speed to the remote location is less than 1GbE you can install a fog storage node at that location and deploy your computers using the storage node. (this assumes you solve the pxe booting issue). You will install the location plugin into fog then assign computers to the remote location as well as the storage node. It will still boot using the main campus dhcp and tftp server, but actual image deployment will happen via the storage node not the WAN link.

@mashina Running this dual boot environment is always a pain to manage. Its probably best/quickest to do this with a virtual machine.

I know this will look like a lot of steps to test out an idea, but if it works then it will also help you with your deployment workflow.

So how I would go about trying to figure this out is to go ahead and deploy/create windows 11 to disk 0 on your mother computer and capture that with FOG single disk resizable.

Now deploy/create linux to your mother computer and capture that with FOG using single disk resizable. This may/will overwrite the windows 11 install with linux on the mother computer.

So what you will have is 2 images (1 Windows and 1 Linux) both captured from disk 0. This will be a complete and bootable image with the efi partition intact.

Now create a target computer (VM) with 2 hard drives. Register that target computer with FOG, and set the target disk to disk 0 (/dev/sda for a sata disk or the nvme disk name for a nvme drive) in the host configuration. Now deploy the windows image to this target computer. Once the deployment is done, verify the computer boots. Go into the fog ui and the host configuration for this target computer, and change the target disk to disk 1 (/dev/sdb). Deploy the linux OS to disk 2. Note: there are other ways to go about this but the goal is to have 2 hard drives with a complete OS with UEFI partition on each disk.

Now that you have the groundwork in place, go into the target computer’s uefi firmware. The uefi firmware should see both disks with valid uefi bootable disks on it. If you made it this far and the firmware can see both disks as uefi bootable, then exit out of the firmware setup and reboot the computer. The next step is to access the target computer’s uefi boot manager. On Dell computers you keep pressing hit the F12 key quickly as soon as you see the Dell logo. In the uefi boot manger you should be able to pick windows 11 or linux boot disk. Test both operating systems. If you can boot both without issue then you are 90% of the way done.

The next decision is how you want the user to select which OS to boot.

1. The UEFI firmware boot manager via F12 key
2. The windows boot manager
3. The linux boot manager (grub)
4. If you PXE boot through FOG, you can create a boot menu using refind (FOG’s UEFI exit boot manager)

Now on the workflow moving forward. The target computer’s configuration still points to disk 1 for all new image deployment. So any new images will be deployed to disk 1 (remember that windows is on disk 0). So if you have it setup the user can pick any OS images from the list and they will always be deployed to disk 1 (the transient disk) without touching the windows boot image.

@GorkaAP I hate to begin with this, but that referenced document deals with a 10 year out of date version of FOG.

Lets see if we can work out a solution using a current release. Please state the problem you are trying to resolve.

@mashina I guess you will need to decide your best method for deploying these linux distros to the target computer.

1. As in the referenced post netboot into the native linux distro installer and install linux that way.
2. Create a standard image and capture that standard image for the user’s to deploy.

The method you use is really dependent on the skill of the user that will install linux. Both methods have their advantages. With option 1 you get the most flexability, but also requires more technical skills on the user. Option 2 you can create a custom linux install with all of the required apps preinstalled.

@professorb24 I can read your post a number of ways. Let me see if I understand the intent. Let me use my words to describe your issue as I understand it.

You imaged a computer with the same image that works with an HP laptop onto a Lenovo. When you boot through the FOG iPXE menu on the HP, it exits correctly and the target computer boots as expected. But when I boot through the FOG iPXE menu with the Lenovo it fails to boot saying inaccessible boot device.

If I understand the issue correctly, then if you changed the boot order on the lenovo so that it boots directly from the hard drive does it boot correctly? In my mind its not clear if it is an image issue (something wrong with the information on the disk) or is it an iPXE or refind issue.

@plyons7890 The error message about an unclean file system is typically related to the source computer not being powered off correctly and files are still marked open.

If the source computer is a ms windows computer I can understand this error. You must not use the standard “shutdown” command because it is not really a shutdown/power off command but more of an advanced sleep command, leaving files open.

You can/should do the following

1. Let sysprep power off the computer before cloning with FOG.
2. Turn off fast startup in windows, this will switch shutdown into its traditional shutdown mode.
3. Use the windows shutdown command shutdown -s -t 0 command to power off the computer before cloning.

@plyons7890 said in Creating image - permission denied:

x.x.x.x:/images2/dev/

Where is this path coming from? Its not a fog standard path.

What is the output of this command showmount -t 127.0.0.1 if you execute the command from the fog server’s linux command prompt.

@AdKlSc There was an issue with the FOG Project web site in 2018 or 2019 where we lost all uploaded images. Unfortunately I see that post lost it images. Are you having a specific problem following the tutorial?

@flat4vw I guess a couple of things.

Instead of realtek.pxe you probably want to use realtek.kpxe.

The *?pxe files are for bios based computers. They will not boot on a uefi system.

The file is physically located in the FOG server in the /tftpboot directory.

How do you make the computer load the file? Update dhcp option 67 on your dhcp server. Either by the windows dhcp manager or if linux in /etc directory.

@professorb24 I’m not sure I understand your problem. I can read your post a few ways.

First let me say does the target computer download the NBP files? Does iPXE kernel start but iPXE is unable to obtain an IP address?

@GlaDio For reference.

bios firmware needs a bootloader like: undionly.kpxe
uefi firmware needs a bootloader like: ipxe.efi or snp.efi

If you have a linux or windows dhcp server then this guide will help you setup a dynamic pxe boot: https://docs.fogproject.org/en/latest/kb/how-tos/bios-and-uefi-co-existence/#example-1

If you are using some other dhcp server it might have the feature for dynamic pxe booting built in. If not we can use dnsmasq to provide the pxe boot information that is dynamic.