@GlaDio said in Boot in PXE uefi:

NBP filename: undionly.kpxe

This is your problem. The design of the computer’s firmware is different between bios and uefi. Because of this each firmware requires a different boot loader and technically operating system.

You are sending undionly.kpxe (bios boot loader) to a uefi system. It doesn’t know what to do with the file so it rejects it. For a uefi system you need to see the uefi boot loader of ipxe.efi or snponly.efi (its akin to undionly.kpxe). With a uefi boot loader that target computer will accept it as long as secure boot is disabled in the firmware.

If you have a mix of bios and uefi computers on your campus then you might need some configuration that support both uefi and bios pxe booing.

@jfernandz said in FOG and Secure Boot:

The problem is apparently I have to sign also the refind_x64.efi binary, not sure if refind.efi is actually loading refind_x64.efi … but I’d suggest also to include this point in your tutorial. In fact I’m guessing you should also sign refind_ia32.efi and refind_aa64.efi as your whole environment could include also another archs.

You are correct I really missed the refind files. I will update that info too. While I had 1.6k viewers of the file not many people have returned comments. I have that turned off in the tutorial because it makes the multipart tutorial a bit messy because of the way the forum works.

I think the signing process (with sbsign) may be automated in a bash script

Towards the bottom of the document there is a bash script easter egg. I initially wrote the bash script then broke it up to explain what each part did. For those that never made it to the bottom of the post, they missed out on the bash script. I intentionally did it that way so people knew how it worked before they simply cut and pasted the script.

@jfernandz said in FOG and Secure Boot:

You actually don’t need to mv dbx.esl dbx-fog.esl as you are not generating any dbx.esl, you cannot even run that command successfully as dbx.esl file doesn’t exist

I can’t believe I wrote that article in 2021, man time goes by quickly. The dbx file is created for black listed certificates. It is kind of an optional for the vendors to include in the firmware. The idea is if a secure boot certificate gets compromised the vendor can add it to that database. So I can see if the database is empty on the target system then the file might not get created. I should add a note into the document explaining this, thank you for the catch here.

For reference my notes say that I referenced this document as I was writing my document: https://wiki.gentoo.org/wiki/User:Sakaki/Sakaki's_EFI_Install_Guide/Configuring_Secure_Boot_under_OpenRC

Also the param chain tftp:/${fog-ip}/EnrollKeys.efi for fog.keyenroll should actually be chain tftp://${fog-ip}/EnrollKeys.efi

Thank you I will fix that.

@jfernandz Looking at your video, can you confirm that 172.120.1.4 is your fog server?

From your post it looks like “time” solves the problem, because you can repeat the same steps after a few seconds and it works??

If this is the case, intuition is telling me spanning tree issue. One network switches using standard spanning tree it take about 27 seconds to start forwarding the data while the switch ports listens for a BPU packet. This timer starts every time the network port “winks”, and it will “wink” (go down and up quickly) as each kernel starts (ipxe firmware, ipxe.efi, and then bzImage. To test this idea, get a dumb/umanaged/cheap network switch, like one of those 5 port monoprice switches. These do not support (typically) spanning tree. Place this switch between the pxe booting computer and the building network switch. See if this fixes this refind issue. -OR- contact your network infrastructure team to verify that one of the fast spanning tree protocols are configured on the port (portfast, fast-STP, RSTP, MSTP, etc). At this point I don’t think your issue has anything to do with secureboot.

@hernani In domain moves you are better to stick to the Windows world for this action. You can use FOG to deploy vbs/ps/cmd file that changes the target computer’s affiliation. You will have less issues if you do this in the windows realm.

For one deployment I setup the computers where initially put in one Imaging OU that had no GPO policies that would break imaging. Then in the first run part of the unattend.xml file I ran a VBS script called move to OU to relocate the target computer to the proper OU. Now this was not moving to a different AD domain, just to a different OU.

I think there was a netdom command that we used at one time to join computers to domain (not by using fog). That utility had the ability to connect and disconnect a device from domains.

One other thing you need to keep in mind is make sure you have a local admin account on the target computer you can use if the domain move fails, otherwise your target system will be lost if the reconnect to the new domain fails.

@professorb24 The quick answer is YES.

The bit longer answer is around your deployment techniques.

Lets go with the driver aspect first. I have a few tutorials around this (pertaining to windows 10 and earlier but should work with windows 11 too since its built on the windows 10 kernel). While this is an older tutorial its still accurate and functional: https://forums.fogproject.org/topic/11126/using-fog-postinstall-scripts-for-windows-driver-injection-2017-ed Its just the unattend.xml section doesn’t work correctly now where there is a post that discusses using the pnputil.exe program called from the setupcomplete.cmd batch file.

For the applications and fonts, you can install them using FOG Snapins function to deploy those apps with FOG. Myself personally I would create a golden (mother) image and preload all of the apps that don’t use a GUID for identification (enterprise AV comes to mind) and preload them onto the golden image (using audit mode) prior to using sysprep and capturing the image with FOG. Then for one off or GUID based applications install them post deployment with FOG Snapins.

@oz-agoston said in Need help with new FOG server installation and setup (PXE, image creation):

Unfortunately our bosses wouldn’t want us to use the windows DHCP server for the FOG server to avoid possible network problems.

We have solutions you can use where you don’t or can’t update your primary dhcp server. You don’t necessarily need to setup an isolated network. Depending on your deployment your target computers may need access to AD during deployment, where an isolated network might cause a problem.

In cases where you can’t/don’t want to update your primary dhcp server you can install dnsmasq onto your fog server to provide pxe boot information only to the target computers. It takes about 10 minutes to install dnsmasq using this configuration: https://forums.fogproject.org/topic/12796/installing-dnsmasq-on-your-fog-server

Now just be aware that dnsmasq (as well as dhcp) only works on local vlan/subnet because dnsmaq as well as dhcp uses broadcast messaging. So right there dnsmasq pxe boot information will be localized to the current subnet where the fog server is installed. If you want to pxe boot on another subnet where the FOG server is not, you will need to update your network’s router and add the FOG server’s IP address to the list of dhcp servers in the dhcp-helper/dhcp-relay service. This will allow dnsmasq to hear pxe booting from other subnets. One of the many advantages of dnsmasq running on the FOG server is that if the fog server is off-line no pxe boot information will be sent to the network.

@renewedharry While I can’t give you a solid answer with your issue, but someone else on the forums had an issue just recently with this software that you might be able to start from: https://forums.fogproject.org/topic/17124/i-can-t-boot-up-parted-magic-2023-08-22/2

For a mixed environment where you have bios and uefi computers, they take different bootloaders to successfully boot. Being on version 0.3 may be hurting your knowledge if FOG since SO MUCH has changed since that version was released. For bios/uefi coexistence you might want to review this wiki page. https://wiki.fogproject.org/wiki/index.php/BIOS_and_UEFI_Co-Existence

@Cire3 said in Not a Fog problem, but solution ?:

Carbon X1 Gen 7 just returns to boot menu after Downloading NBP file

Check secure boot is off and if the proper boot loader is being sent to the target computer.

You might use a witness computer on same subnet as the pxe booting computer. Use a capture mask of port 67 or port 68 or display filter of bootp Start the capture, pxe boot to error and then stop the capture. You will see the DORA process (discover, offer, request, ack/nack). Look at the offer packet this is coming from the dhcp server to the target computer. Look to see if both the ethernet header (bootp part) has next-server of IP address of fog server and boot-file as the proper boot loader name. Now confirm that dhcp options 66 and 67 are set properly. Its up to the pxe boot firmware vendor to decide to use bootp fields or dhcp option fields to locate the boot information. If you grab the pcap I can look at it for you if you get lost or not sure.

@gabrielchun The error messages says (in my words) that the kernel (bzImage) doesn’t understand the virtual hard drive (init.xz)

The image name looks suspicious to me. bzImage4152 looks like one of the custom kernels I built. At least that has the same numbering format that I use. If that is true then that is linux kernel 4.15.2, which is very old. I might understand why it can’t connect to the virtual hard drive. Please upgrade your linux kernel to very 6.0 or later. You can do this from the fog ui under fog configuration->kernel update. Understand this is bzImage kernel not the fog server host OS kernel.

@oz-agoston I agree with Gabriel check your dhcp server(s) (if you have more than one) to ensure dhcp options 66 and 67 are being sent to the target computer. PXE booting will simply not work if these values are not set on your campus dhcp server.

The next questions is if you have a screening router between the subnets (client and fog server) that might be blocking tftp.

If you could supply the actual error message created by the target computer during a pxe boot that would help us identify where to look.

@yonatan FOG doesn’t have the concept of displaying certain ipxe menus based on platform type. You can probably do this with a custom advanced menu but then you have to hand code the menu. iPXE (the bootloader that creates the FOG iPXE menu) can branch in the code based on arch or platform.

While this quote doesn’t speak to your issue, you can see how the iPXE menu item can branch based on the iPXE platform field.
https://forums.fogproject.org/topic/15984/integrate-fog-with-wds-mdt/11?_=1702084351302

You could use that concept to create an advanced ipxe menu. One other tip I can give you is that you can view how the FOG iPXE menu is constructed by pointing your web browser at the following url http:<fog_server_ip>/fog/service/ipxe/boot.php?mac=00:00:00:00:00:00

@Cire3 In general what you ask is possible. It will take a little setup to complete, but possible.

What you need to know

1. FOG has the ability to create custom FOG iPXE menu items. You will want to create a fog ipxe menu to chain to your netboot.xyz server. So you will want to build this menu first and manually select the netboot server to confirm it works (more on that in a bit)
2. If you want to manually select this menu item then you are done. If you want to default to this menu item instead of booting the local hard drive then go to the next step.
3. You can change in the fog ipxe menu builder what menu item you want to execute if you don’t select a menu item. Just change the default menu item to your netboot.xyz iPXE menu.

I have a tutorial on how to netboot installer disks so the concept of creating IPXE menu items. If you read over it you will see how to netboot alternate operating systems. https://forums.fogproject.org/topic/10944/using-fog-to-pxe-boot-into-your-favorite-installer-images

Look at this post: https://forums.fogproject.org/topic/15984/integrate-fog-with-wds-mdt/11?_=1702084351302 if you need to chain to another boot loader than this will help. Specifically this section of the code.

set next-server 0.0.0.0 # Replace with WDS server IP address
...
set net0.dhcp/filename ${wds-bootfile}
set proxydhcp/filename ${wds-bootfile}
chain ${wds-bootfile} || goto Menu

You see how to populate the dhcp next server and bootfile so that the chained bootloader will think it was pxe booted natively. The other thing this ipxe menu shows you how to dynamically change the bootloader based on bios or uefi.

@Tauric said in Can't deploy/register/debug with parallels:

Also for the initrd=init.xz

That is precisely why you should not trust my memory. For a little clarity this is what boot.php file creates for the auto reg function.

kernel bzImage loglevel=7 initrd=init.xz root=/dev/ram0 rw ramdisk_size=275000 web=http://192.168.50.23/fog/ consoleblank=0 rootfstype=ext4 storage=192.168.50.23:/images/ storageip=192.168.50.23 nvme_core.default_ps_max_latency_us=0 loglevel=7 mode=autoreg
imgfetch init.xz

So the command at the IPXE> prompt would be
initrd init.xz or imgfetch init.xz There is no equals = sign in the command.

And just to tag along with what Tom said, when I first read your post I was confused if your target computers are ARM or Intel? You menitoned Intel iMac, and then a little later ARM. But I took the ARM reference as it should work because its not ARM based.

OK by setting the logging to 7 and you don’t see a bunch of text on the screen then the kernel (bzImage) is not starting up. So at the IPXE prompt I would try kernel bzImage to see if it is really transferring it. The boot command at the IPXE> should try to run the kernel.

@Tauric I have doubts that bzImage is getting transferred to this computer. I can tell you that bzImage will boot even if init.xz is not sent to the target computer. You will get a vfs not syncing error. In the fog configuration->fog settings page. Press the expand all button then search for “log” change the default log level from 1 to 7. Save the setting then try to pxe boot the target computer again. Logging level of 7 will cause the linux kernel “bzImage” to print out a lot of debugging information. That will tell us if the kernel is booting.

At the ipxe prompt you can download the init.xz file (as a test) by keying in initrd=init.xz and press enter. Lets see if we get any useful error messages.

@diegogyn said in Two VLANs (Two IP ranges):

Is it possible to configure the ipxe boot loader to try to download files from 2 different IP ranges?

Fog is not designed to have/support multiple imaging network interfaces. If this is what you are trying to do, then that is your problem. You might need to setup an additional FOG server on the vlan 3600 subnet if there are filtering rules blocking access to the 192.168.10.1 IP address.

@diegogyn You need to have full routing working between the subnets. More precisely for this error you need to be able to reach the fog server’s web ui from the 3600 vlan. It looks like you have tftp setup because fog’s ipxe boot loader is running.

@mark29 said in PXE-E32: TFTP open timeout:

it screens PXE-E32: TFTP open timeout.

This can be (most commonly) caused by either

1. DHCP options for that subnet have dhcp options 66 set incorrectly.
2. You have two or more dhcp servers on that subnet and both don’t have all of the setting needed to pxe boot.
3. The tftp service is not running on your fog server.

I would setup a witness computer on the same subnet as the pxe booting computer that witness computer will run wireshark, with a capture filter of port 67 or port 68 or use a display filter of BOOTP. Start wireshark and then pxe boot the target computer until you get the error, then stop the wireshark capture.

Now review in wireshark the OFFER packet. This comes from the dhcp server to the client.

1. Look to see if you only have one OFFER packet. You should because the pxe error is “Open timeout”.
2. Look at the OFFER packet in the ethernet header verify that both the {next-server} field has the IP address of the FOG server, and the {boot-file} has the proper FOG boot loader.
3. Now look at the DHCP options under option 66 and 67 they should match whats in the ethernet header.

FWIW: I’ve seen soho routers that eventhough you properly configure them, they set themselves (the routers) as the pxe boot server and not what you put in dhcp option 66.

@miyaqub said in Boot UEFI mode slow:

Has anyone come to a solution for this problem.

I’m pretty sure that neither the developers or myself have one of these Dell 3000 systems handy to test. So they will rely on the user community to help debug this issue.

The issue/problem with the partclone speed, is that its a composite speed of timing or the fog server to read the file off from disk, send that file to the target computer, then the target computer to receive that file, expand it in memory and then write it to the disk. Any one of the steps in the sequence can cause a performance issue.

As you have seen, a 1GbE network link has a theoretical max bandwidth if about 7.5GB/min (assuming ideal and non realistic conditions). In practice if you are getting 6.1GB/min the entire process is working as intended and very efficiently.

So if you look at the problem logically. If you setup a test, from the same network cable. Test a 7010 (or older kit) and a Dell 3000. If the 3000 is slower you can probably rule out the fog server and network infrastructure as the problem. So that leaves something inside the 3000 as cause of the slowness. So if you look at the data flow now all you have left is the target computer intake of the image, expanding it in memory and writing it to disk as the potential problems.

To try to understand where out of the 3 is the problem, schedule a task for the target computer (capture or deploy doesn’t matter) but before you hit the schedule task button tick the debug checkbox. Now pxe boot the target computer. After several screens of text is displayed where you need to press enter to clear it, you will be dropped at the FOS linux command prompt. Of the three remaining steps, you can probably rule out the expanding the image in memory as the problem. So that leaves you will network intake of the image and writing to disk. I won’t go into the steps you need but you can look at this article about benchmarking FOG. https://forums.fogproject.org/topic/10459/can-you-make-fog-imaging-go-fast

So basically you use iperf3 to test network bandwidth between the target computer and the FOG server. Then test using dd to write a 1GB file to the hard drive (note you may need to create a partition and format it for a linux file system). But those benchmark hopefully tell us where to look.

@Kram-Man Is your main ipxe server running ipxe as the bootloader or syslinux? If its truely iPXE then on the FOG server, in the tftpboot directory there is a file called default.ipxe At the bottom of that is a chain load command or chain load the default.ipxe You can look at this line on github. https://github.com/FOGProject/fogproject/blob/a4bb1bf39ac53c3cbe623576915fbc3b5c80a00f/src/ipxe/src/ipxescript#L32 Just replace ${next-server} with the IP address of your fog server.