@george1421 I have had to disable secure boot to PXE boot at all with FOG, but I think you can re-enabled it after the image deploys but before it starts the OOBE experience (meaning you will need to have it shut down after imaging or catch it on reboot). One of the more experienced guys might prove me wrong though.
You will have to leave it disabled if you want to PXE boot in the future though.

If the devices are in bios mode certain usb to etherent adapters support pxe booting. For uefi mode computers you must use the network adapters supported by your hardware. Each hardware vendor has usb to ethernet adapters that support pxe booting. In uefi mode there is a bit more vendor lock in than with bios mode computers.

But usb booting does work.

@george1421 I was able to add a TP-Link TG-3468 Card to the server and it worked.
The trick for anyone following or finding this thread will be to be patient and let the server go though both integrated nic’s failing to bring link up. Once it hits the 3rd nic the system will boot.

I didn’t see the option for a hardware compatibility test on the iPXE menu, so I tried the option for “client system information (compatibility)”.

It was unable to find the NIC as well.

@george1421

I’ll get back to you about the booting from USB thing later.

To answer your questions in the second post:

the device lists the system UEFI version as 106.1624.768 1.5.2 (as a troubleshooting step i did update fog from the git repository) I’ve tried all kernels from 4.12.3 and upwards
the complete list is:
4.12.3
4.13.4
4.15.2
4.16.6

@george1421 Aha that explains it. Thank you very much for the clarification. Will figure out the DHCP thing and get going on the two machine types, with an upgrade planned for 1.5.x for sure! Thank you

That’s exactly what I was wondering! Thanks for the reply. We will get ourselves up to date.

here is it my new video, sorry for the quality
https://youtu.be/0nQm-_9Eoe8
thx @Sebastian-Roth for the new binary in 32-bit

@george1421 Update.

So we did some more testing and it turns out that the Intel Volume Management Device setting in our system BIOS is whats causing the issue with our NVMe drive. We found this because even after getting FOG to successfully push an image to the drive, Windows was unable to boot from it. We disabled the VMD setting and the PCI device is no longer addressed on an extended root hub and Windows booted normally, so we tested this with the orignal bzImage as well and it all still works as expected.

@kyron said in surface Pro 4 FOS dhcp issues:

Kernel 4.13.4 or higher just gives a black screen.

Can you please verify if the device is hanging or if it’s just the screen staying black. For that note down the client IP (DHCP log or something), boot it up into a job while you send ICMP ping messages from another computer. Keep your eyes on the ping to see if it stops responding at some point (“freeze”?) or if it keeps going (display just black).

Just as an FYI, we had to remove the DHCP relays on the AP’s. As the switches were apparently handling the relays anyway, the ones on the AP’s were not needed.

@george1421 Thank you, its weird it decides to encrypt by default and then say its not enabled. That thread helped a lot

@george1421 thanks for your answer. i will try that.

@Twilems I am sorry but we don’t have enough resources to support older versions of FOG. I’d suggest setting up a test setup with FOG 1.5.0 on a different server/VM and see if you still have an error with your Lenovo Thinkpad 13 G2.

@Almeida How is your question related to the FOG project? Please tell us a bit more on what you are having an issue with.

That’s it! I only tried each “Adaptertyp” for the second adapter. After disabling the second adapter (I’ve read somewhere else that two adapters are required…) and changing the first adapter from PCnet… to IntelPro/1000 MT Desktop, the problem was solved.

Now I was able to install my Ubuntu image via the fogserver in the VirtualBox.

Thanks a lot!!!

@andrew-asph
Hello, this thread has a patch that solved the bug.
https://www.mail-archive.com/netdev@vger.kernel.org/msg189347.html

The patch is here:
https://www.mail-archive.com/netdev@vger.kernel.org/msg189923/0001-tg3-Add-clock-override-support-for-5762.patch

More details in here:
https://forums.fogproject.org/topic/10731/crash-due-to-timeout-in-tg3-kernel-module-tg3_stop_block-timed-out-ofs-4c00-enable_bit-2?loggedin=true

After all it was my basically my fault.

The IPXE UEFI USB Boot did not work…

So, following the instructions provided by George, i decided to use the FOS image.

I built one, using these instructions: https://forums.fogproject.org/topic/7727/building-usb-booting-fos-image/4

One caveat: The PC that I used to build the image is a Fedora 27, so I used the CentOS 7 script and i added the following line to create the 32 bits setting for grub2:

grub2-install --removable --no-nvram --efi-directory=/mnt --boot-directory=/mnt/boot --target=i386-efi

After that, I got the error reported here, but it was because I did not have started a task on the server. After I scheduled a capture task on the FOG Server, everything worked smootly.

@cabraln said in Realtek NIC fails to load undionly.kpxe?:

02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15)

That’s your wired NIC, thank you for providing that. Please look into 802.3az as George requested.

@george1421 Same problem.
0_1518010916911_fog.jpg