Posts made by Tom Elliott

@Eazis YEah, my suspicions correct, this far at least.

You can try downloading rod’s latest kernel:
https://github.com/rluzuriaga/fos/releases/download/EXP_20250617/bzImage

I doubt it will work, but who knows…

@Eazis IF you can boot in and run ip link show

@Eazis Well, what I’m seeing is that the 8125 isn’t being detected at all, and I’m not really sure why at this point. The kernel you tested with has all 8125 firmware associated, as well the driver set to load it. So I’m at a lost as to why it’s not loading that specific thing. The network is detected, but not loaded for some reason. More simply, it seems the kernel can see and tell the type of device, but for whatever reason it doesn’t actually want to load it as a potential interface as being available.

I’m unsure where to go until this portion can work and without one of these myself, it’s really difficult to guess about in the dark.

@Jim-Holcomb So unfortunately i’m not readily available for a remote assist due to work requirements and duties so I apologize.

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

After upgrading to the latest FOG version, my PXE boot environment is broken. What used to work flawlessly is now a disaster. PXE clients either hang, enter a loop, or display autoexec.ipxe not found. Sometimes pressing ESC brings up a green DOS-style login prompt, then fails to chainload. Sometimes they hang on “Booting…” indefinitely.

So this “autoexec.ipxe not found” always shows. This is not an issue. It’s simply saying there’s no file called autoexec.ipxe on your /tftpboot folder. It’s NOT whatever was causing ipxe boot issues. I’m guessing this PXE boot environment was broken due to whatever was changed?

As to the selective hard drive. I’m not sure I understand what is wrong here. YOu watched it write ONLY to the /dev/nvme drive but somehow it wrote to both the sda and the nvme? Something doesn’t sound right there. Single Disk resizable and Multiple Partition Single disk shoudl only write to a single drive and be done. Do you have video of this process writing to both? I only ask because seeing this in action will help me understand where the code is flawed. To my knowledge, however, it seems more likely that at some point before you wrote to the NVME it had accidentally written to the SDA drive, then you try to figure out how to have it write to the NVME. Then, finally, it was able to write to the NVME, but now it LOOKS like it wrote to both because the SDA drive was never cleared out?

And yes, d1.mbr is absolutely correct. That’s how it initializes the disk.

@Jim-Holcomb Is it just this one machine having this problem or ALL your machines are using bzImage32?

@Jim-Holcomb I’m seeing you have boot access enabled?

I don’t know why bzImage32 is being loaded.

Seems to me you likely need to check the host or global kernel settings. 64 bit kernel should be defined to bzImage This would show up under global configurations (FOG COnfiguration Page -> FOG Settings) “TFTP_PXE_KERNEL” should be set to bzImage
TFTP_PXE_KERNEL_32 should be set to bzImage32

THe other place to test would be under the host directly -> Host Kernel.

Please check that those are set appropriately.

@Jim-Holcomb Not all updates will force a db update. That is normal.

Looking at the error in question now that it’s been shown more clearly.

@Eazis The same link has been updated. It’s the same kernel version just no longer having the dummy/bond drivers (hopefully).

I doubt it will fix the issue you’re seeing.

If you can load up into a debug session (either how @george1421 has asked prior or however you’re most comfortable) and try running (once at the terminal for entering commands like you did before.)

echo $mac
echo
echo
/sbin/ip -0 addr show | awk 'ORS=NR%2?FS:RS' | awk -F'[: ]+' 'tolower($0) ~ /link[/]?ether/ && tolower($0) ~ /'$mac'/ {print $2}' | tr '\n' ' '
echo
echo
/sbin/ip -0 addr show | awk 'ORS=NR%2?FS:RS' | awk -F'[: ]+' 'tolower($0) ~ /link[/]?ether/ && tolower($0) !~ /'$mac'/ {print $2}' | tr '\n' ' '
echo
echo
/sbin/ip -0 addr show | awk 'ORS=NR%2?FS:RS' | awk -F'[: ]+' 'tolower($0) ~ /link[/]?ether/ {print $2}' | tr '\n' ' '

This should output the mac. Then it will output the interfaces it finds with that mac on the device. I suspect this is where things are failing. The mac in use for ipxe isn’t associated to anything the system see.s

The next output should show all interfaces the system sees that do not have that mac.

THe last will show all interfaces it sees in one list.

Based on what i see from your output, enp0s20f0u7 is the interface but it’s got a mac address of 08:be:ac:26:55:10. That one seems to have picked up an IP address so it’s really interesting.

@Eazis I’m working on recompiling without dummy/bond drivers.

@Jim-Holcomb if the boot.php was updated from the install folder, then you’d like need to repull the repository.

This can be done by going to your installer path. running:

git reset --hard
git clean -xfd
git checkout stable
cd bin
./installfog.sh -y

@Jim-Holcomb If you rerun the fog installer, this should fix your boot.php and reaches out to download and place the bzImage(s) and init(s) files.

Please re-run the installer, and anything that is currently broken from customization should at least be set back to what was produced for the 1660 information.

@Eazis Can you please try with this file:

https://drive.google.com/file/d/1RuMF_xvYLfJwjlXAYk9ZN1VUG004Uk85/view?usp=sharing

I know it’s google drive. It’s my personal one and this link is available for anyone.

It’s simply the 64bit kernel file (we generally name bzImage) Please can you try this?

It’s got a few drivers added that appear (to me) to have been missing. If this works, I’ll try to get this into the fos repository.

@Eazis It looks, to me, there’s a firmware that we may need to add to the kernel for these nics, but I don’t know what version? I see

rtl8125a-3
rtl8125b-1
rtl8125b-2
rtl8125bp-2
rtl8125d-1
rtl8125d-2

I suppose we could attempt to add all of them, but we don’t know which one applies to your specific device.

@jfernandz https://stackoverflow.com/questions/4713088/how-do-i-use-git-bisect

This is just very basic overview and probably unhelpful.

If you’re familiar with git, you can switch to different points in time (via the dev-branch) to figure out when we last knew things were good. So first, I’d suggest trying to find exactly when that would’ve been.

I’d likely start, using dev-branch as the primary “tester case”

git checkout -b dev-branch

If you haven’t already done so of course.

Then I’d put the branch at the same level as when we pushed out 1.5.10:

git checkout 081d1f4

Run your install and see if things worked, if they do:

git checkout dev-branch
git bisect start
git bisect bad
git bisect good 081d1f4

Of course the 081d1f4 is the hash of the commit where things were good: this might or might not be the 1.5.10 release, so your mileage may very and may need some more adjustment.

You can find these hashes on https://github.com/FOGProject/fogproject/commits/dev-branch/?after=f7fd3a7a3f188b4540f089a7f38c4d368b53376c+174 using the different pages at the bottom to find a point in time, and they show the hashes on the right and side of each commit.

It will iterate through things and you just mark after each install/test what worked (as good or bad) by testing:

If it still fails, you’d run git bisect bad, if it succeeds, you would run git bisect good each iteration.

It’s tedious I know. but it will help us find the exact point things broke and hopefully from what (maybe it’s something we did, maybe something within ipxe, but gives us a starting point to test things out.)

Thanks

@jfernandz It’s probably a combination of both. At least, best what i can tell about the 3930’s at least?

Either way, similar to the post about bisect, below, might help us out as well.

I mean firmware nearly always plays a part in things, but that’s not to say that something with the iPXE code is not at fault, either.

@jegan1337 That’s possible, that maybe something is missing (or was removed from IPXE)

If someone’s able to do a git bisect, figure out when it worked, figure out when it stopped.

Likely you would first do:

1.5.10

now

then use bisect to let it jujmp around and until you see when it narrows down exactly when it broke?

@jfernandz next-server comes from the dhcp server option 66 (I think that’s what it is in Windows DHCP at least?)

That said, often when next-server is empty it’s usually because there’s multiple dhcp servers trying to tell the same single client their next-server and it doesn’t know which one to use, so it just goes blank. That’s not to say it couldn’t be a firmware issue, but just expressing my past experiences.

As for the Keyboard:

@AxeMeAQuestion22 @jfernandz

The “legacy” setting shouldn’t be a Firmware related/removed thing. It’d be under (generally) the USB options of the BIOS settings. Not “Legacy BIOS modes” or anything. Specifically it’d usually be surrounding the USB specifically.

Now, I don’t have this particular gear, so I could be wrong, just again speaking from prior experiences of many different systems (in general.)

Edit:

Looking for what I see, if you’re using 3rd party keyboards (non standard that came with the system, or basic basic keyboards, it seems lenovo just might drop them beyond initial key entries (f1 for bios setup mode or whatever.)

https://forums.lenovo.com/t5/ThinkCentre-A-E-M-S-Series/M90q-gen-5-usb-keyboard-not-working-in-bios/m-p/5358388

This isn’t quite the same machine, but just kind of describing what I was thinking about with the USB Keyboard/Legacy Support.

@Clebboii So, you could use the 5.15.67 and earlier versions (whatever they actually may be) and all will be fine?

@jflash said in Lenovo ThinkPad L14 Gen 5 - kernel panic:

d. RTL8111/8168

Can you try with the realtek.efi file?

@Jim-Holcomb You should disable Secure boot