I’m confused. You are only looking at the “kernel ring buffer”, so the part that logs before the system fully starts up and standard log tools take over…are you only testing all these on boot-up or something? Can you clarify your methodology?
The Kernel ring buffer stores all events having something to do with system/hardware/driver interaction. Not only at boot, bot afterwards too…
Either in a console you can look at it with sudo dmesg -Tw or sudo journalctl -b -f, then plug/unplug the cable.
If the cable is detected, check for any error message that shows up and google their meaning.
3 Likes
Ahh ok, gotcha. In my linux circles we never refer to it like that, we just say “dmesg”. I guess it goes with the linux idea of finding the shortest command/word possible to convey meaning.
Thing is - what’s in the kernel ring buffer can be called even during a kernel panic → Magic SysRq key - Wikipedia 
This helps a lot to troubleshoot the cause of a crash/hang. And on the console, you always get an result with that.
Is there good reason to update firmware that’s still in BETA? I feel more comfortable waiting for it to be out of beta and not adding the lvfs-testing remote. Is that fine to wait for, or is this an important update to get sooner than later? I don’t really understand firmware enough yet to make an educated decision.
My understanding is that since it was published to the official bios updates page, the update is no longer in beta.
1 Like
running fwupdmgr get-updates though doesn’t yield a bios update, so either it’s still in beta, or the “release” version is still only in the lvfs-testing branch, which I’d still prefer to avoid
It may need some time before it finally lands in the stable lvfs channel. For the beta release they mentioned:
We are waiting for metadata to rebuild in 4 hours
1 Like
Only if it fixes issues that bother you. Otherwise, you might as well wait.
1 Like
I do wish there was more of a concrete, “this is no longer beta” than just Framework’s informing us of the timeline that if no probs within 2 weeks then it’s no longer beta and the stealth removal of Beta from the thread title and stealth posting on the firmware and drivers page.
So is this no longer Beta then? @Kieran_Levin
1 Like
I have tested so many Alpha versions in the open source world, and they usually are way better than the official released versions from a certain other big player.
Beta does not mean “not finished”. It means that they made fixes and it is in testing phase.
Usually when no new errors appear, that Beta becomes the finished “release” version.
But as others already said. If you have no issues, don’t apply/use it. Period. Your choice.
2 Likes
Keeping one or more “charge only” cables can be good, ensuring safety when charging from unknown USB plugs. I’ve heard stories of Laptops being compromised from USB ports while supposedly just charging.
I have had issues connecting to my iPhone 15 pro max even before the firmware update.
I do never plug my devices into an unknown USB port, if possible …
When I do, I monitor by default the process list and the kernel ring buffer.
1 Like
Yep, I tend to just take an AC charger with my carry-on. The small Framework one will be even better.
1 Like
So this is odd, why does LVFS say the version is 0.0.3.3 instead of the 3.03 version you state here?
https://fwupd.org/lvfs/devices/work.frame.Laptop16.Ryzen7040.BIOS.firmware
The esrt field is a 32 bit integer. Every OEM uses it differently.
Day after this released Pop!_OS sent me a notification that a firmware update was available. Sure enough it was this BIOS update and in addition a firmware update for the fingerprint sensor. Change log was even provided. Clicked install, entered root password, laptop rebooted BIOS installed. No issues.
6 Likes
I just upgraded and had hard freezes after the upgrade (couldn’t even switch to other terminals with Ctrl+Alt+F3). After quite some debugging it only happens on my current install of Manjaro KDE /w wayland, but not with X11 and not on Fedora /w wayland (both 39 and 40, upgraded during testing). I’ve booted into btrfs system snapshots from days ago with various prior kernel versions and am still seeing the freeze so I am pretty sure the BIOS upgrade is at fault since that is the only thing I couldn’t roll back.
Can you provide me with the 3.02 BIOS so I can roll back for testing?
And if I can’t find another fix, I’d probably stay on 3.02 for a bit longer as well. Need wayland for the much better multi-monitor fractional scaling support, and although I have Fedora installed, I don’t feel like switching to it (nor Ubuntu for that matter) - don’t have the time for a switch rn even if I wanted to
Thank you!
EDIT: Some more context
The freezes would happen pretty soon after logging in, usually when opening a window or shortly thereafter. But running an all-core stress test on a separate terminal had no effect, survived just as long on the desktop. Usually opening the terminal after waiting a bit was fine (at least for a while), but opening the system monitor or browser, it would crash basically immediately.
I’ve also noticed it would be stuttering for the first couple seconds after login, which wasn’t the case before - e.g. hovering over taskbar icons had 500ms-1000ms delay.
I’d love to be able to revert back to the old BIOS and just maybe I failed to isolate another variable and it’s not a BIOS issue at all, but something that just happened to start at the same time. Because it’d be very odd if wayland + new bios combination would cause that. But X11 on the same system has been stable during work for hours now, so idk.
What SSD’s are you using?