Posts made by george1421

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

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