Ok I have found with the MAC passthrough in the Bios turned on we are not able to boot to FOG unless we were on the same subnet.
This is interesting. My intuition is telling me it might be an MTU issue. We have seen that with tftp, Where (typically) on the other side of a VPN WAN link the MTU of the data packet is less than the block size of tftp. The block size of 1468 comes to mind for tftp. When the network MTU dips below that level it causes fragmentation of the tftp packet, then the transfer fails.
Using the instructions I provided before for collecting a pcap on the fog server, you are interested in udp port 69. Start the packet capture and then pxe boot the target computer on the remote subnet. See if it attempts to contact the fog server. The tftp query will be 2 times before data is transferred, the first time the client queries the tftp server on the size of the file and the second time it asks for the file. My bet is that it will ask for the file size, but then the file is never sent.
@john-l-clark Up til this point we didn’t change anything. If you were able to make the database server change then we could do the next step that will solve the speed issue. SO with that said, its probably running fine now but the slowness will be back.
When you are to the point where you want to continue let me know. We can work through the rest of the changes.
@john-l-clark Here are the exact key sequences I used to build this driver on a brand now Ubuntu 20.04 image in my virtual lab.
sudo su -
apt-get install wget git build-essentials -y
git clone https://github.com/acooks/tn40xx-driver
sudo make install
lsmod | grep tn40xx
When you review syslog look for errors regarding this network adapter. Ignore the one about the tainted kernel.
If everything goes ok then you will need to create a startup file in /etc/modules.d so that this network driver loads on every boot up. Once its there then reboot and it should pick up an IP address, if not make sure its listed with the lsmod command like above. For ubuntu you may have to use the network manager to assign an IP address for it. I’m not a big ubuntu user, so I’m just guessing. But it took me longer to install ubuntu than it did for me to build this network kernel driver. Keep the installer files because when you upgrade your linux kernel you will need to recompile this network adapter driver.
@JJ-Fullmer The r8152.c from the torvalds github site failed to compile on 4.19.65, I’m suspecting its for a later release of linux. The version from the torvalds site was 1.10.10. The version in 4.19.65 was 1.9.9 of the realtek driver.
I was able to compile the realtek driver from the wget github site. This version is 2.12. Here is a link to that kernel with the 2.12 driver built in. I also enabled the usb-c code in the kernel that appears to have not been set. I don’t know if its relevant, but it should be on for other applications. https://drive.google.com/open?id=1wZwwOwbEr0nR3mnPLKg7AsulwJaGhO0A
Download this as bzImageRT (watch your case) and copy it to the ipxe directory with the other kernel images. Manually register the host and then in the host definition add in bzImageRT as the kernel for that host. Then pxe boot into FOS Linux debug mode to see if the network adapter inits correctly with this updated driver.
@John-L-Clark I realize that this is a few months old, but this problem sounds similar. Give this solution a try, download the kernel @george1421 made and set it on that host. It worked for me with the lenovo usb-c ethernet adapter, I imagine you’re using that or a similar adapter, this kernel fixed the issues we were having with the L390 and X390
@John-L-Clark This is out of FOGs scope as we find WIFI not to be a reliable connection for deploying or capturing an image to/from a PC. So years back it was decided to ignore WIFI adapters altogether. We don’t have drivers for WIFI enabled in the iPXE boot nor have we included drivers in the Linux kernel that we use in our FOS imaging environment booted on the client machines.
Would be a huge task to add this and make it work reliably in most cases (thinking about different WIFI standards, driver issues and encryption stuff).
Why do you want WIFI to be the default/primary MAC?
@john-l-clark If your image was from a machine that was in BIOS mode and the media to initially install was BIOS media as well, then the image is being deployed to the HDD/SSD with BIOS partitioning and not UEFI boot partitions. In this case the UEFI/BIOS would not consider it a UEFI bootable device (as it has no UEFI boot partition). Presuming your image is whole disk and not a single partition.
I have seen posts around about converting images that are BIOS to UEFI, but didnt pay much attention to them. If the process of setting up that machine with a new image isnt too much of a burden, that may be your best bet. Fresh install OS with UEFI settings/media, setup what you need and capture.
before you sysprep try to run chkdsk, if chkdsk was ok run sysprep but don’t use option /reboot or /shutdown just use /quit, then manually shutdown your machine with shutdown -s -t 0 -f, then try to image.
Ok this is resolved. I was able to unbox another new machine and build out the image and capture it from that machine. I then deployed the image to the other 11e that would not capture without error. Thanks All for the help