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

@tacOS said in Literally cant even run ./installfog.sh -_-:

I keep getting told to run “su -” or “sudo -i”, while and after having run one, the other, or BOTH. just the same error over and over.

It’s a workaround but I managed to continue by editing installfog.sh and deleting the if-fi block that has this message. I think it’s using a very specific way of testing that might not work in every distro ( like the previous block that checks if the user ID is 0 to see if it’s root and it won’t work on distros that randomize the root’s ID). I’m working on Garuda Linux (Arch based), and I’ve hit another wall at the end with TFT but at least it’s installed.

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

@Small0145 No, it’s not.

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

If undionly.kpxe worked in bios mode then snp.efi should work in uefi mode

Hi George, the BIOS claims its in UEFI mode but when booting it looks suspiciously like legacy (larger text etc). Its an old Viglin with a second generation i3 which is being retired this October so its not too much of a deal now I have a workaround.

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

@Almeida BitLocker is enabled in your master ? If yes, you should disable it. Enable it only on the final computer.

We do have the BCD issue when enabling BitLocker on 24h2 image, we are running the same commands, but you are missing one.

You need to set device partition=C: for the recover from hibernate entry too. The annoying part is that its ID is dynamic.

@Tom-Elliott I fixed it by directly removing the dirty flag using Linux. sudo ntfsfix -d /dev/nvme...

We need to redo our golden image, so we will check at that time if we still get the same behavior.

Thx for the help !

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

@Eazis I created an experimental kernel that includes the drivers to fix this issue. Would you be willing to test it and let us know how it goes?

@george1421 Just seeing if anyone else has had issues.

Haven’t purchased the new models yet.

Was hoping to confirm they’re compatible with FOG first, so thought I’d reach out and ask around.

Thank you!

@george1421 Thanks for the insight!

I’ve tried adding Dell’s WinPE driver package to the driver store but it doesn’t seem to have helped either. Whether it’s just the wrong drivers for the specific machine, i’m not sure yet.

I’ll give it another go once we get some more Dell stock in - but thank you for the help in the meantime 🙂