Posts made by Tom Elliott

@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

@AxeMeAQuestion22 Do the BIOS options have a “Legacy USB” mechanism to them?

@jflash so you changed it in mikrotek which is correct. however I believe your machines are also runnign with secure boot enabled, which often is what we see or somethign more along the lines of straight error loading, though freezing is more often what i recall from Lenovo, at least long ago when I first started seeing them.

@jflash Bootfilename should be snp.efi, or snponly.efi (if using UEFI booting) or one of the other ipxe files.

Having the bootfile be your kernel is likely the reason you’re seeing this issue.

@Jim-Holcomb If you’re able to show the error that’d really help. This, in my experience, really sounds kind of like a “Secure Boot Enabled” issue, at first glance.

@robertkwild I do not know why it’s not booting. It looks like it’s getting the file and trying things, but i’m not sure where it’s failing specifically?

@robertkwild The autoexec.ipxe isn’t a problem at all. It is just saying that the file doesn’t exist. It’s meant as a means to allow the consumer (you) to have other scripts that just “work” dynamically. It is not a required file and not the cause of the “freeze” I suspect you think it is.

@robertkwild Try using snponly.efi instead of snp.efi

@Alan-Lim The boot exit (either bios or efi) are configurable in 2 places, where the level at the host is considered the primary source. If a machine is loaded to your network, but not registered, then it will generally attempt to use the exit from the FOG Settings point you posted in your image.

@Alan-Lim Try setting EFI BOOT EXIT TYPE to EXIT

@robertkwild I’m suspecting there may have been a php module update that FTP was working similarly to a found issue in 1.6 and they finally addressed that. I apologize for not thinking of it sooner and glad it’s working. To my knowledge, we didn’t change anything regarding the Folder/File issue, so much appreciated in letting us know it’s working for you now.

@ReinierG What do you mean “it automatically exits”?

What does? Sorry just trying to understand what issue you’re having.

Are you saying there’s no screen for you to perform any action?

If that’s the case (and I’m only guessing) there is a way to extend the timeout. Again, I don’t have my actual option available but It would fall under FOG Settings -> Pxe Menu Timeout or something like that? I believe the default is 3 seconds.

I’d recommend updating this to 5, then increment it slowly (1 second at a time) so as not to make all your systmes seemingly suddenly slow.

@ReinierG This is a setting of the exit type for the host.

There’s 2 places this can be defined. The first place is global should should be configured under FOG Settings -> Exit Type (I cannot remember if it’s specifically under EFI Exit, but I think it is)

The 2nd place is individually to each host.

I would suggest looking at the host settings and see what it’s efi exit type is configured for. It sounds like it’s configured as rEFInd exit, if you set to EXIT does this fix the issue you’re seeing?

@ReinierG I feel like there’s missing information here.

Is fast-restart enabled?

I believe the command you’d need:
powercfg /h off as an administrator account and you should not have the dirty bit issue.

If this issue still persists, I’d also recommend doing a chkdsk/sfc scan of the disk as well.