Posts made by george1421

@Ryxn I checked and that nic has been in the linux kernel for several years.

And secondly when you checked for missing firmware the kernel wasn’t complaining about missing something.

Its a good thing you were able to get the error while in debug mode. Because that was going to be the next quest for you. To get the system when its behaving badly.

So when you get it into debug mode and its complaining about no nic lets do the following.

ip a s should show if the network interface has an ip address, I’m going to suspect no because it complained about it earlier in the boot process.

lspci -k -nn | more Look through this list until you find the entry. The number in the square brackets will be what you posted earlier. [8086&1502]. See if the nic is visible to the kernel. AND if it is it should mention what kernel driver its using. I’ll give you a for example using my laptop.

0000:00:1f.6 Ethernet controller [0200]: Intel Corporation Ethernet Connection (
13) I219-V [8086:15fc] (rev 20)
	Subsystem: Dell Ethernet Connection (13) I219-V [1028:0a22]
	Kernel driver in use: e1000e
	Kernel modules: e1000e

lastly if everything looks good, kernel sees the nic, there is a kernel driver assigned. Lets see if time fixes your problem.

When you ran the ip a s command it listed all of the network interfaces and if it has IP addresses. You will need to know the interface name for your network adapter. It may be something like eno1 or ens192, or something else. Get that device name.

Now run this command /sbin/udhcpc -i $iface --now replacing the whole word $iface with the device name listed from the ip command. This will tell the network adapter to again poll for an IP address from your dhcp server. If it picks up an IP address this time, then time does solve your problem and you will need to look into your network configuration and make sure that port-fast or fast-stp is enabled on your network port.

@ProfessorFow OK what I want you to do is on the master node, go into the storage group where this remote node is. Look at this remote node. There should be a ftp user ID and password listed there (said from memory). Use those credentials to connect like you did with the ftp CLI from the master node to the remote node. See if you can login using ftp to the remote node. Then issue a ls command, Its not important what the answer is as long as it gives you an answer and not an error.

If you can’t login using those credentials then on the remote storage node look at the /opt/fog directory. There is a hidden file called .fogsettings. issue the command cat /opt/fog/.fogsettings In that file should be the password for the account used when the fog server was installed. Make sure they match what is on the master node.

There is something with ftp that is not working correctly, that is why the replication is not happening.

@ProfessorFow The FOG replicator uses ftp to transfer files to the storage node. Make sure ftp is not being blocked between the master server and the remote storage node. You might test by on the master node, issue `ftp <remote_server_ip> if you are not prompted to enter a login then FTP is being blocked.

@Ryxn Ok to divide and concur this issue, if you are getting to the FOG iPXE menu then your pxe booting is working ok and that’s not the problem.

Since you mentioned bzImage, and the network interface shutting down once bzImage starts then issue is with FOS Linux kernel, 6.1.22 is your current version. The issue is with this 6.1.22 kernel and nothing else.

What we need is the hardware ID of that network adapter. In windows you can get it from the device manager hardware ID. There will be a vendor code and a device code. Under linux if you run lspci -nn | grep -i -e net the code will be in the form of [8086:1fd6] (made up code). Once we have that code we can look to see if there is a linux driver for that nic.

You need to schedule a task for the target computer and tick the debug checkbox. PXE boot the computer and after several screens of text you will be dropped to a fos linux command prompt.

Also run this command, the file is either /var/log/messages or /var/log/syslog (I can’t remember)

grep -i -e firm /var/log/syslog (remember the file may also be messages)

What we are looking for is the kernel complaining that the nic requires a specific firmware to activate the nic. To keep fos linux fast and light there are only a limited number of firmwares built in. That can be fixed but we need to know which one.

@Donutsrule5

OK lets see if we can boot from a usb drive. This tutorial will instruct you on how to build a usb boot image. https://forums.fogproject.org/post/69606 the google drive link below will take you to step 7 in the thread.

https://drive.google.com/file/d/1psCrPVzBTvlakLkCMvhdoScAEZp1CKE6/view?usp=drive_link

Once you build the usb boot drive, take the kernel and init.xz from your current version of fog and replace the ones on the flash drive with the ones in from the FOG server. The files are in /var/www/html/fog/service/ipxe directory.

Once you have the usb drive ready, pxe boot into the grub menu on the flash drive, then go into debug mode. After several pages of text you need to clear with the enter key you will be dropped at a fos linux command prompt. If you can get that far then fos linux is OK and the problem is probably with ipxe or the handoff between the two.

If you want to image with the flash drive, schedule the task in the fog server BEFORE you usb boot and select option 1 from the menu. If you get it out of sequence you will get an error that says something about Null. Basically its saying you don’t have a task scheduled on the fog server so there is nothing to do. Lets see if we can get it to boot this way.

@sideone said in [BUG] iPXE Boot Loop & Menu Failure After FOG 1.5.10.1660 Upgrade:

Your suggestion of trying a realtek.efi didn’t work

At running the risk of polluting this thread just a tad more. If undionly.kpxe worked in bios mode then snp.efi should work in uefi mode.

Also knowing the exact realtek nic model could be important if its a 8168 (1GbE) or 8125 (2.5GbE) the default drivers in the linux kernel wont work well. You can try to use the experimental kernel that has the official realtek drivers built in https://github.com/rluzuriaga/fos/releases/tag/EXPERIMENTAL_REALTEK_DRIVERS Understand this will only help once you get past the FOG iPXE menu. This would be after undionly/snp has displayed the FOG Menu.

@Donutsrule5 said in Del Pro 14 Premium PXE fails:

Any ideas or help

This is failing at the nexus of iPXE handing off control of the computer to FOS Linux. So it could technically be either iPXE or FOS linux. The version of FOG is mostly irrelevant at this time.

I would say rebuild ipxe and make sure you have the latest FOS Linux kernel, I think 6.12.35 is the latest, but not sure. Here is a tutorial on how to rebuild ipxe: https://forums.fogproject.org/topic/15826/updating-compiling-the-latest-version-of-ipxe There is also a link in that article to the official wiki page with the updated instructions too.

We are not done, at a road block yet. I can create a newer one off kernel based on 6.15.5 as well as we can build a USB boot drive to boot FOS Linux from a USB stick and bypass iPXE and the handoff between the two.

@aurfalien said in Mellanox ConnectX 3 imaging issues.:

So all good here.

Did FOS Linux have the driver enabled for that 10GbE card (i.e. were you able to image with FOG once you got past the iPXE menu)?

FWIW: For uefi mode snp.efi or snponly.efi should work if undionly.kpxe worked in bios mode. I’m saying it should because ConnectX3 is a somewhat older card (circa 2017/2018).

@punch07 to view the /tftpboot use the command line terminal window. Now I do have to say that different distros have the directory in different locations like /var/lib/tftpboot.

@punch07 I agree from the picture everything looks good.

What we don’t know is the number of actors involved with this pxe booting process. We really need to know what the client is being told and by who.

Follow the instructions in this tutorial. Collect the pcap and look at it with wireshark.
https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

What will be specifically interesting will be the OFFER packets. If you only have 1 dhcp server on your network you should have only one OFFER packet. If you have more than 1 then you need to identify each dhcp server that is responding.

If you have only one OFFER packet, then look into that packet. In the ethernet header you should have two fields. {next-server} and {boot-file} those settings should match what you have set in dhcp options 66 and 67. Both the bootp section and the dhcp options section need to be set.

If you can’t figure out the pcap, unload the pcap to a public file share site and paste the link here. We can take a look at the pcap and give you additional guidance on where to look, but in the pcap file you should see at least 4 packets, DISCOVER, OFFER, REQUEST, ACK/NACK. The OFFER packet comes from your dhcp server(s).

One additional note if you have a primary and backup dhcp servers make sure both have the boot settings configured.

EDIT: I just thought of another issue it might be. If you did not complete the installation properly the /tftpboot directory on the fog server might be empty. Double check to see if you have ipxe.efi in that directory. If its not there, make sure you complete all 3 phases of the install. fog server console->web ui to install database-> fog server console to complete the install.

@punch07 said in Unable to install Fog successfully.:

DHCP server is a router or a win server

I guess I need to ask the question a different way. Did you update the configuration on your dhcp server to include dhcp options 66 to the IP address of your fog server and dhcp option 67 to be ipxe.efi? According to the error message its saying your dhcp server is not handing out the boot file name (dhcp option 67).

If your dhcp server is a soho router, then I understand why its not working. If it is a ms windows server then you need to look into the setup.

@punch07 The issue is related to your dhcp server not specifically FOG. Your dhcp server is not sending out the boot file name, that is what the client is complaining about.

What device is your dhcp server for this netwokr?

@bobbywitt Are you having a problem or are you just seeing if others have had issues?

@skyhawk3355 I remember awhile ago I needed to create a one-off kernel for a system that had a 486 cpu. I checked but I don’t have that kernel any more.

I just recompiled the linux 6.6.85 for a 586 based CPU. I can recompile for a 486, but I don’t know if that is going to get us anything better.

Here is 6.6.85 586 version
https://drive.google.com/file/d/1GAzFjbtpDVXXCRpe6bIZ5mwySSXeDHko/view?usp=drive_link

Here is 6.6.85 586 where I stripped out some drivers like scsi, nvme, uncommon network drivers, virtualization drivers, etc. I was able to strip out over 1MB of kernel size from the previous one above. Did I through out too much?? YMMV.
https://drive.google.com/file/d/13dE7BLgofsFiNJj_Q8nLDknplRbWRqkJ/view?usp=drive_link

@Eazis said in ASUS NUC14MNK fos kernel no netwerk drivers:

So the 8125 driver was missing?

Well if you close one eye and squint with the other, you can still see it. The kernel developers consolidated all of the realtek drivers into the 8169 driver which kind of works except the driver updates lags behind the hardware by a few months. It looks like the FOG developers have a way to integrate the official realtek drivers moving forward so that should make life with the reaktek nics easier because realtek releases a new subversion of the hardware every few months.

Anyway I’m glad you have your issue sorted out and the FOG developers have a plan forward too. @rodluz (well done!)

@rodluz said in FOG Very Slow to Deploy Image - Lenovo Neo 50Q Gen 4:

That is exactly what I did, I disabled the 8169 driver from the kernel config too.

Good going. That 8125 driver was originally in the linux kernel individually but then the driver was merged into the 8169 unified driver which has not kept up with the realtek hardware changes. I was getting lost trying to integrate a third party driver into the linux kernel. I could compile it as a module and add it to the init.xz but that is not a sustainable solution. If you have it integrated into the kernel for the 8169 (1GbE) and 8125 (2.5GbE) that should cover most of the common network adapters today from realtek (outside of the 10GbE stuff, but those haven’t hit the desktops yet).
Well done!

@Eazis Will you test a new experimental kernel that @rodluz in this post
https://forums.fogproject.org/post/156904

@jack_darnellits Historically when the intel rst adapter is in raid-on mode linux can’t see the disk behind the raid controller and the sata controller presents itself as a different device depending on the raid mode. When you look at it when its in ahci mode linux will see it as a sata controller, when its in raid mode linux sees it as a different device, not a sata controller but a raid controller with a different device ID.

So that is all historical information. I’m a bit surprised that you were able to image the system in raid mode with FOG (because of historical experiences). You did the right thing by loading the intel rst driver into your golden image. My past experiences with the intel drive is that you need to make sure you have the right one. I’ve had troubles loading windows from dvd on laptops where its not seeing the drive and getting the right F6 driver seemed to be a real pita.

With all that said, what I would do is try to get into windows using recovery mode, that may mean booting from a recovery drive. Verify what you are loading into your mother image is the proper intel driver for the OS to see the network drive. Also make sure you have the dell winpe drivers loaded into the golden image too (you can use the pnputil.exe command to load drivers from the expanded cab file). Right after imaging windows first boot is in winpe mode. The real mode drivers might not be available since windows has not really started.

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