Testers

There are two exit modes one for bios and one for uefi. Make sure you set the global settings to SANBOOT for bios and rEFInd for efi.

Now for bios SANBOOT works 99% of the time. For UEFI refind works (out of the box) about 90% of the time. Refind does a pretty good job of finding the EFI boot partition. You many need to tweak the refind.conf settings to have it search more locations.

So are these target system, uefi? What target OS are you trying to boot?

@John-L-Clark When I worked at a foundry in the early 1980s they use to have the saying, if something broke look for forklift tracks. Meaning, you might want to ask whoever changed something or we are going to be hunting and pecking all afternoon. Just remember that FOG doesn’t like the IP address of the FOG server changing after FOG has been installed.

Also this goes without saying you should update FOG from 1.3.5 to the latest version to support the latest hardware. 1.3.5 is pretty old, I don’t think it supports nvme disks.

@John-L-Clark FOG server on same subnet as pxe booting client?

https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

@John-L-Clark said in FOG clients not PXE booting:

no none of our machines are booting

Ok well that changes the scope a bit.

So is the target computers on the same subnet as the FOG server?

Have your confirmed that your dhcp server has dhcp option 66 pointing to the FOG server’s IP and dhcp option 67 set to undionly.kpxe?

What device is your dhcp server? (make and model)

@John-L-Clark Hmmm you can pxe boot a different computer but this lenovo fails to transfer undionly.kpxe If you are sure you are transferring a bios boot loader it should boot.

What model lenovo?

What version of FOG?

What hardware are you booting?

What mode is the target in UEFI/BIOS?

What boot file are you sending to the target computer (DHCP option 67)

Is this a new FOG install or one that has worked and you are just having an issue with this specific computer?

@kevinnew22 I don’t understand why registration gets stopped at loading bzImage and imaging works fine. Both tasks transfer bzImage before running FOS Linux on the target computer.

Is it just the Dell 320 model or all models do the same?

@kevinnew22 When it uploads bzImage forever, that usually means you have a networking problem. When it errors out you are in the 2nd stage of pxe booting. The first stage is when undionly.kpxe gets transferred over to the target computer and it boots. Then iPXE will download bzImage in the second stage.

Undionly.kpxe uses the network driver built into the network cards. It is possible the network card has a bug in it where undionly.kpxe does not work. You can try to send ipxe.kpxe instead of undionly.kpxe to the target computer see if ipxe.kpxe driver will boot better.

In regards to the kernel args of your wiki post you can find it here:
You can go in the FOG web interface FOG Configuration -> FOG Settings -> General Settings and in the KERNEL ARGS field enter acpi=off Then save the settings. Next pxe boot the target computer again see if The acpi=off command will tell the target computer when FOS Linux is running (bzImage) to not use acpi code to talk to the hardware.

Your problem right now is with iPXE and not bzImage (where you use kernel args) so you can skip the kernel args part for now until bzImage starts up.

@alzen Well when you run sysprep it kind of resets the computer back to a neutralized condition. You can preset some values using an unattend.xml file you reference when you run sysprep. If you have ever installed windows directly from the dvd drive you know it asks a bunch of question before windows is setup. The unattend.xml file can be used to answer those questions ahead of time so it skips asking the installer the questions. This asking questions bit is part of OOBE (Out Of Box Experience) that is managed by WINdows SETUP. When you run sysprep it cleans out the system of drivers and settings that are important for that specific model of computer and reset its back to a discover new hardware mode.

In my case I have 1 golden image for 15 models of hardware. I use a FOG feature to copy the correct drivers over to the target computer during imaging then when winsetup is running it finds the drivers and adds them to the windows configuration. WinSetup will only run when you reset the computer using sysprep.

@alzen said in Sysprep after deploying image:

Those images that we are capturing already have the drivers installed. Do we need to run the sysprep.exe in …/System32/Sysprep after deploying the image?

Well you have 2 concepts here so let me answer each.

If you are capturing from a specific model with all drivers installed, do you need to sysprep the image? No. Should you, yes because it follows M$ best practices. But you do not as long as the source and target hardware is exactly the same.

Sysprep happens before you capture the image then after being deployed winsetup/oobe will use the reset information provided by sysprep when deploying to new hardware.