Topics created by John L Clark

@john-l-clark What version of the FOS Linux kernel are you using? (web ui -> fog configutation -> kernel update) Are you on 5.15.x

@john-l-clark said in Lenovo L13W Yoga not booting to FOG:

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.

@george1421 Thank you, That worked.

@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.

@sebastian-roth Printer Install.PNG

This is how I install it manually. I browse to it and right click and click connect. I will uninstall it on my computer and try it your way. Thanks

Looks like @John-L-Clark has a huge setup with many hosts. Talked in chat and figured that increasing the value of php_admin_value[memory_limit] in /etc/php/7.4/fpm/pool.d/www.conf fixed the issue.

Possibly moving to InnoDB could help here as well. Though this is not supported in an official release yet. Take a look at those topics:
https://forums.fogproject.org/topic/15162/the-list-all-hosts-tab-takes-a-long-time
https://forums.fogproject.org/topic/14254/high-cpu-usage
https://forums.fogproject.org/topic/14689/high-cpu-usage-on-fog-server/9

@george1421 Worked Great thank you sir. It was the Storage node password was incorrect.

@george1421 Thank you again, that fixed it.

Figured it out. The old database was using the wrong bzImage file. Thank you again for all the help.

@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 update apt upgrade apt-get install wget git build-essentials -y reboot git clone https://github.com/acooks/tn40xx-driver cd tn40xx-driver make sudo make install modprobe tn40xx tail /var/log/syslog 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.

@george1421 Thank you lol, yeah the ips are still the same, we are working through it and will post the resolution.

@george1421 I was able to edit the Grub.cfg and add our Fog server IP in and then boot with USB and register and capture and deploy. Thank you again for all the help.

@george1421

Thank you, perfect followup…
worked well as well L13 Yoga success.

Thanks to all.

@george1421 said in issue with netcard of dock gen2 of lenovo l390:

@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.

Hope this helps

@x23piracy said in Could not open inode XXXXXX through the library...":

Hi,

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.

Regards X23

That has worked for the guy here: https://forums.fogproject.org/post/97015

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

@John-L-Clark if an entry is made properly in /etc/fstab it will mount on boot, else it wont. Reboot and see. This is something that needs dealt with immediately - don’t wait.

@Tom-Elliott Great thank you