@rodluz said in FOG Very Slow to Deploy Image - Lenovo Neo 50Q Gen 4:
You are welcome to continue using the “OEM driver” kernel for now until I create a full upstream release.
What did you do here, did you fold in the realtek oem driver into the kernel build. I was looking at going this path for another open issue with a realtek 8125, where the oem driver solves a lot of the issues with the default universal drive 8169.
@olivier-bonnici said in FOG Very Slow to Deploy Image - Lenovo Neo 50Q Gen 4:
tar xzf linux-6.14.9.tar.gz
Ah that explains the difference. You didn’t just rebuild the kernel you jump to the next version. The FOG developers typically only use long term supported kernel. Currently the latest long term kernel is 6.12.x, you used a development kernel 6.14.x which is not EOL (just means fixes and updates will not happen in this branch).
It looks like whatever was causing the slowness was resolved in 6,14.x and later versions of the linux kernel. Thank you for the clarification.
@skyhawk3355 said in Sub 512MB RAM Devices:
ith my 384Mb computer it’ll boot to the menu but will freeze on inventory or imaging.
To just add a little clarity here. The iPXE menu is under the control of iPXE. Once you pick a menu item FOS (bzImage and init.xz) is loaded into memory and executed.
Both bzImage and init.xz are compressed images, so the size on disk is not indicative of the space consumed in RAM. Both are decompressed as they are loaded into memory. I’d have to look to verify, but I think bzImage is in the 8MB range and init.xz is in the 200mb range.
If you just consider the baselines of a standard gzip compression ratio of 1.6:1, the kernel will expand to 13MB, and the 200MB init.xz would expand to 332MB. That puts us at 345MB for just the image to be held in memory. That leaves almost no ram to execute FOS. Just to caveat this, I have not looked at what the current size of bzImage and init.xz are.
Now if you have no choice, surely look into the 32 bit version of FOS linux since it should consume less space. But with 384MB of ram, that is going to be very tight.
Second option is to remove the hard drive from the computer and image it on a system that has a bit more resources, then place the drive back into the limited computer for first boot.
@Eazis Will you do a few things to help us try to sort this out?
Schedule a capture or deploy to this computer, but before you do tick the debug checkbox before scheduling the task. If you don’t have this computer registered with the FOG server manually register it.
Now pxe boot the target computer, it should start to image right away, but instead of imaging it will drop you to a linux console on the target computer. There will be several screens of text you will need to clear with the enter key, but at the end you will be dropped to a linux command prompt.
How I want you to key in the following.
ip a s
lspci -k -nn | grep -i net
grep -i -e firm /var/log/syslog
get a clear picture of all of the values and post it here.
The first command will show us the network adapters
The second command will show us the hardware ID of the network adapters
The last command searches /var/syslog for any message that has firmware in the name.
After you are done with this, delete the capture/deploy task from the fog server.
@Jias94 Hey no worries, I’ve created that error a few times myself so I had a good idea where to look. I’m glad you have it sorted out and can get back to imaging.
@Jias94 Where I’ve seen this before is in a custom fog menu. The menu id has a minus sign in it and ipxe is thinking its a command not an id. Somewhere around the choose command its getting hung up.
So how do you find this? Using a web browser and access the ipxe menu at http://<fog_server_ip>/fog/service/boot.php You need to replace <fog_server_ip> with the correct ip address. Since you are messing with https, you may need to change that so. You should end up with a screen full of text that makes up the ipxe menu. Looks for things you have entered that have a minus sign. If you can’t find it post the entire content of the ipxe menu here and we will take a look for you. But I would focus your attention around the choose command, one of its entries as a dash where it thinks is an internal command to the menu
@Tom-Elliott said in ASUS NUC14MNK fos kernel no netwerk drivers:
I suppose we could attempt to add all of them, but we don’t know which one applies to your specific device.
Also if we booted into debug mode and after the error is presented search syslog for the key word ‘firmware’ the kernel should post anything its missing. grep -i -e firm /var/log/syslog
@Eazis Ok A little google-fu shows this is not an 8169 nic but a 8125 (2.5GbE) nic. (I personally really dislike realtek because of this BS).
So now we need to figure out how to add 8125 native nic support to the FOS kernel.
@hariskar It looks like your root partition ‘/’ has 1.8T or 1800GB of space. The command I would have run is df -h to give you usage. but assuming that debian is less that 50GB you should have plenty of space to capture a modern computer with 50GB of data. Use single disk resizable to use zstd to compress that 50GB of data down even smaller.
What error message are you getting? A screen shot of the error might help set the context of the error.
@Eazis will you check to see if the beta version 6.12.x series fixes the issue? https://github.com/FOGProject/fos/releases
If not we will need compile a special kernel with the current realtek driver installed. The linux mainstream kernel drivers typically lags current hardware.
@wamis let start by updating your fos linux kernel to something more modern. I think 6.8.86 may be the latest. FOG Settings->Kernel->update kernel. FOG 1.5.7 is old. Lets see if we can update the kernel without needing to update fog.
@Eazis said in ASUS NUC14MNK fos kernel no netwerk drivers:
ASUS NUC14MNK.
Using either windows or linux can we get the hardware ID of that nic. In windows its under the device manager and the hardware ID. It should be two series of hex numbers. Under linux you would use lspci -nn | grep -i net in this form the code we need looks like [8088:14dc] (made up number). That will tell us if there is a driver in the linux kernel for that.
@olivier-bonnici said in FOG Very Slow to Deploy Image - Lenovo Neo 50Q Gen 4:
A friend of mine have added the correct driver into the bzimage file
Can you explain this in a bit more detail? Lets see if we can help everyone do better, please.
@jack_darnellits Are you able to get IP addresses on vlan 1? If yes then dhcp is working. Your dhcp server may be doing a directed broadcast (not common) its kind of like a unicast message directly between the dhcp server and target computer. Normally dhcp servers use broadcast messages which can be detected by a monitoring computer running tcpdump/wireshark.
You may have to put the pxe booting computer on a mirrored port to see this communications.
Or as an alternative use / install dnsmasq on your fog server to give pxe booting information (only) to the computers. https://forums.fogproject.org/topic/12796/installing-dnsmasq-on-your-fog-server
We will typically recommend dnsmasq when you have an uneditable dhcp server or a soho router/dhcp server that will not play nice.
@jack_darnellits ok looking at the first image you posted. I see that next-server and boot-file are not set in the ethernet header these are the bootp settings, where dhcp settings are option 66 and 67. Both groups of fields need to be set because its up to the pxe boot vendor which fields they will look at so both need to be set.
Also make sure you have only one offer packet from the expected dhcp server. If you are getting more than one offer packet that means you have multiple dhcp servers responding to the dhcp DISCOVER packet.
@jack_darnellits said in UEFI PXE not booting:
Running tcpdump on Ubuntu, I can see that the server is receiving requests from the client machine - but I suppose nothing is being sent back?
If your fog server and dhcp server are on the same subnet then tcpdump on your fog server should see the offer packet from the dhcp server. Inspect the offer packet to make sure in the ethernet header both next-server and boot-file values are being set correctly, also look in the dhcp options and make sure that dhcp options 66 and 67 are set correctly. I’ve seen some soho routers always point to them selves as the boot server even if your configuration says something ekse.
Additionally, i’ve used TFTP on a windows 11 vm to attempt to get the ipxe.efi file - which times out. Wireshark showed that it was receiving data packets back from the server, but would eventually time out after 8 or so attempts.
for tftp to work from a windows computer, you need to temporarily disable the windows firewall then it should work. tftp is similar to ftp where there is a command channel and a data channel. The windows firewall will block one of the channels (can’t remember which ATM).
I can get some screenshots come monday, but any suggestions would be greatly appreciated. If some more details are needed, please do let me know.
I also have a tutorial on how to start debugging this: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue you can view the pcap in wireshark to make it easier to review than just a straight tcpdump.
@olivier-bonnici If you have time to test, I have an idea what maybe causing this. I just saw a video on hacking a chromebox (seemingly unrelated), and they had a similar issue with downloads being unnaturally slow but uploads were OK.
It came down to the energy efficient ethernet built into the realtek nic.
What I want you to do this this:
ip a s . Look in the list for the network device that has an IP address. Write down that name for the next stel.ethtool --set-eee eno0 eee offfog and press enter. This will place you in single step mode. You will need to press enter at each breakpoint in the code but you will be able to see the partclone screen to see if the speed has improved.I don’t know specifically if this is your issue but its worth a shot. If it does work we can do a few things to make this a forever change, but first we need to find out if it works or not.
@stokehall From the error it appears that FOS linux is not loading correctly.
So I would have to ask:
What I would do to try to fix this is:
@alterak If you know how to program linux bash scripts this is possible. You will need to edit a script called fog.man.reg that is in FOS Linux (the OS that runs on the target computer to capture/deploy images). I have a tutorial on modifying that program to set a default hostname. But the concepts you need to do what you ware are listed here: https://forums.fogproject.org/topic/14278/creating-custom-hostname-default-for-fog-man-reg
@Faurel ok good that looks like a clean dhcp process. It would be helpful to have the pcap file in my hand, but you want to expand the OFFER packet. The OFFER packet you can tell from the Info column.
In the packet you may need to expand the dhcp section. You should see the image similar to below. What is important is the next server IP address should point to IP address of your fog server. and boot file name should be ipxe.efi. You see in this example that the boot file name was not given, this is the error with this packet. The next server and boot file are in the ethernet header. This is the legacy bootp pxe section.
The next place you need to check is the dhcp options below. You should see dhcp options 66 which should be the IP address of the fog server and dhcp 67 should be the boot file name of ipxe.efi. In this picture this packet is also in error since the dhcp server is not sending out all of the pxe booting info. So if your offer packet looks like this you have a problem.
