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