@michaeloberg Interesting workaround you cam up with! Using dnsmasq for legacy BIOS machines (undionly.kpxe) and Windows DHCP for UEFI ones (ipxe.efi). While it seems to work properly I am fairly sure this will be failing one or the other time because both send out PXE boot information and this is known to cause trouble.

As George said, would be good to get the packet dump (pcap) to understand what’s going on. For that you’d disable option 66 & 67 on your Windows DHCP, install tcpdump on your FOG server and capture the packets while PXE booting the legacy BIOS host first and when it waits at the iPXE menu try booting the UEFI machine too and stop the packet dump just after that ran into the error.

@elibirau Just so you are aware, this is not a hardware forum by any means. There are way better places to post this kind of questions with people around knowing way more about hardware than we do! This forum is about the FOG project… 🙂

@georgeyates Please realize that FOG 0.32 is 8 years old already. I would not expect it to run on any current disk hardware, understand gpt disk, uefi, nvme, any current network adapters, Windows 10 disk structure. If you have it working now with the 3.3.3 linux kernel, great job.

@Quazz said in HP Probook x360 11 G1 EE Unable to Image:

This particular model seems to be bad news in Linux environments in general.
People having trouble installing Linux on it, getting it to boot, etc

To me this sounds pretty clear. We might still try to help getting this fixed but it won’t be easy I suppose. It’s not something FOG is doing wrong but HP decided to release a device that seems to be Linux unfriendly.

What I’d suggest is you download different kinds of Linux live CD ISOs and try booting those one after the other to see if any is able to boot up and run this hardware without issue. Ubuntu Live, Knoppix, Kanotix, CentOS live, openSUSE, SystemRescueCD, …

@InfoOverload said in iPXE/tftp error - Extra chars in the RRQ:

working through some of the troubleshooting/ I decided to look at the dhcpd.conf a little closer
This is what I had - “broken”

Great you figured this out! Not something I’d know from the top of my head and believe me I have done very extensive debugging and use of the Linux DHCP server.

The difference between option bootfile-name and filename as far as I understand it, is that the later actually puts the filename into the answer body vs. the other one adds it as a option later in the DHCP packet. Take a look at the DHCP packets in wireshark and you’ll understand what I mean.

Why some NICs handle the DHCP option properly while other do not - I don’t know. It would be interesting to see if the DHCP server actually sends those malformed names or if it’s the NICs miss-reading it. I suppose it’s some kind of missing “end of string” character that makes some NICs read beyond the actual filename in the DHCP option… just guessing here.

Upload a PCAP and we can figure this out. 🙂

Solved. After eliminating one item after another, and initially only looking at the NIC, I went ahead and removed the DMS card. Wouldn’t you know it, no longer the rEFInd error and they went on to image. Thanks for everyone’s suggestions. This goes to show that some errors are not really related to what they appear to. 40 + machines saved from surplus.

@gazzer82 You should be able to use the efibootmgr tool if the machine is properly booting in UEFI mode. Please describe in more detail how you boot from USB. One time you say pxelinux (which is really old and not used by FOG since years) and then you say rEFInd…

If you boot up to a FOS debug shell run efibootmgr, take a picture of the output and post here.

@Shad0wguy said in HP Elitebook g6 slow to image:

where the first image will deploy without issue, but then subsequent deployments hang.

Can you clarify what “subsequent deployments” mean? Is that to the same device you are deploying again, or are you deploying to a different device and it hangs?

Is the hang with image push from fog or WinSetup/OOBE provisioning of the device?

If it is a different device, is there anything that is being shared between the two devices? What happens if you reboot the fog server when the subsequent devices hang?

What version of FOG are you using?

thank you 🙂

@sysengine1125 What is serving DHCP in your network? A Windows Server? Which version?

@weidongyan said in How to make fog server using my new storage pool:

The storage pool that I created has been mounted.

To which path is it mounted?? As well post the output of the commands George requested!

@TBCS Are all the Yogas in a specific part of your network (one switch/room/subnet)? It’s kind of unlikely this is caused by the Yogas being UEFI systems. What could be the case is that the network driver for the NIC used (probably an external adapter, right?) is kind of buggy and not allowing for a proper NFS connection. But as we check network connection on bootup it’s also very unlikely.

I guess George is on the right track here. Your network seems to not handle the default 0.7 second timeout well and therefore you see random failures. Try manual mounting as George suggested a couple of times in a row to see how often it fails.

mkdir /testfs mount -o nolock,proto=tcp,rsize=32768,intr,noatime 10.10.1.93:/images /testfs umount /testfs mount -o nolock,proto=tcp,rsize=32768,intr,noatime 10.10.1.93:/images /testfs umount /testfs ...

Then add the timeout option as well and see if it’s doing any better.

mount -o timeo=10,nolock,proto=tcp,rsize=32768,intr,noatime 10.10.1.93:/images /testfs umount /testfs mount -o timeo=20,nolock,proto=tcp,rsize=32768,intr,noatime 10.10.1.93:/images /testfs umount /testfs ...

Hi, I am having the exact same issue, with the Optiplex 3020’s. Were you able to find a solution?

There is currently no way to work around the secure boot issue.

To boot with secure boot on the boot OS needs to have a signed certificate. This certification process requires both iPXE (from another FOSS project) and FOS (from the FOG Project) to be digitally signed. Getting these items signed and certified is time consuming and expensive (from a FOSS standpoint).

@Sebastian-Roth Thanks you!!! I swapped out the ipxe.kpxe file and it worked.

@george1421 Got it. I made the changes and in the process of deploying my first image now. Appreciate the help.

Server

FOG Version: 1.5.6 OS: Debian 9.9 Kernel: 4.19.48 TomElliott 64 and 4.19.48 TomElliott 32

Client

Model: Lenovo X1 Carbon Gen6 Dock: Lenovo Dock USB-C DK1633 OS: Windows 10 Pro 64 Secure boot: disabled

Description
Hello,

I’ve the same problem on Lenovo X1 Gen 6.
As @george1421 suggested, I turned to FOS. Unfortunately I don’t understand the documentation to build an image.

Thanks for your help.

Solution
This works well with the adapter provided by Lenovo.

@george1421 Just wanted to let you know that I updated to the latest kernel as suggested and it worked! Not sure if anyone else has the same issue, but now we can image about 630 PCs! You guys rock!

@Zark110 Just as a quick test an you connect a dumb unmanaged switch between the client and your main switch? Then try again.

@Sebastian-Roth Intel Core i5-7260U @ 2.2GHz * -shrugs- *