Framework i5 DIY edition. I kept the laptop plugged into power during the whole process. I installed the drivers and ran into a minor issues where Malware bytes quarantined the fingerprint driver. I disabled Malware bytes, restarted, reinstalled the drivers. I suspended bit locker. Backed up recovery Key. I then installed the bios update. After that I turned on Malware bytes. I adjusted the bios battery limit to 80 and disabled hyper threading. Last I ran a scan to make sure it was not going to interfere with the new drivers. During the scan I noticed Battery was at 81%. Probably got to that charge before I changed the bios settings.
After update notes:
Fingerprint seems to be working fine.
If I discharge the battery below 80% (such as 40) and charge it back up it seems to stop at 81%
I followed the EFI instructions to update to the 3.07 BIOS on my laptop (i5 version running Fedora 35). Everything went fine, and the system seems to be running as usual.
Couldn’t hold out, the under clock issue got annoying to deal with. Followed the EFI instructions and it worked without and issue, on PopOS
Edit: 2 hours later, oh snap, battery life has improved dramatically. Usually needed to top up my laptop at the 2 hour mark with a max of 4-5 hours of battery life. I’m seeing an estimated max of 7+ hours. Discharge is much more respectable
Yeah I don’t see anything obvious on here that would indicate what, maybe the fix to the locked clockspeed? I also did not change any of the default settings for the charging behavior or performance settings in the OS.
I find that sleep/hibernate are way more consistent now with 3.07. Battery time is better. It feels way more intelligent about when to power down on its own.
Hi, reporting in from Windows 11 with no major visible issues. I’ve set the battery charge limit to 80% and the only issue with it is it visibly presenting as 81%, but this has been reported before already. Battery life seems to be better as well when unplugged when compared to 3.07 BIOS and the previous driver bundle.
Installed 3.07 by EFI startup.nsh, up and running without immediately noticeable loss of function.
As other users have noted, my GRUB bootloader was lost by the firmware after the install.
Unlike the above, I avoided chroot (since that risks a mess and I prefer to be on my actual system when I can):
boot to recovery medium with a UEFI shell (e.g. Ubuntu install image; note that this appears to be necessary since the shell doesn’t seem to be available through the BIOS interface)
locate your ESP partition among the initial output of the shell
type FS0: or FS1: or FSx: where x is the partition number of your ESP and FS is whatever disk it’s on, then ls/cd to your grubx64.efi file and execute it
once back in your usual Linux environment, reinstall the bootloader (see erock’s post quoted above for that, or GRUB - ArchWiki, or force-reinstall grub and hope your distro’s install hooks work right)
Similarly unexpected experience: starting from a charge (100%) above the set charge limit (80%) resulted in battery discharge over time on Linux (Arch; was cursorily looked at on Ubuntu 20.04.3 LTS but not rigorously) and upower reporting discharge while the laptop was idle and connected to the stock charger.
The set-charge-limit-at 80% → see 81% appears to be likely an OS issue, at least on Linux. upower reports 80% on the dot while all my other indicators show 81%. It’s possible that upower is idiosyncratic, though.
I’ve seen some bizarre behavior in the side indicator lights’ blinkiness. Context is provided below; weird bits are in bold.
Notation:
< : my action
> : result from the laptop
< set charge limit 80%, run laptop from 100%
> laptop discharges to 80%, showing some forgotten indicator light pattern
< run laptop at 80% (seeing 81%)
> laptop blinks amber
< unplug laptop, run to 75%
< set charge limit 100%, run laptop charging to 82%
> laptop solid amber charge
< reboot, set charge limit 80%, run laptop
> laptop keeps charging from 82% to 85%
< disconnect laptop, reboot several times, run discharge to 80%
< plug laptop in, run laptop at 80%
> laptop shows solid amber light
Debian 11, batch 4, full disk LUKS encrypted. After upgrading via EFI/USB, the laptop doesn’t find the NVME drive anymore (WD SN850 black). I upgraded the drive firmware, still didn’t boot. It seems EFI on the NVME was zapped, I was able to restore it by following the GRUB EFI reinstall guide at the Debian Wiki with some variations. See this thread for more details.
Wait, so the system couldn’t find the NVME drive at all, or it could but the UEFI boot information was dropped from the firmware and Grub needed to be reinstalled/reconfigured?
Addendum:
After leaving my laptop plugged in for <1m whilst shutdown, the light returned to blinking amber from solid, but my charge increased from reported 80%/81% (upower report/everything-else) to reported 81%/82% while powered off and plugged in (over a longer period than 1m, following the blinkiness change).
The charge limit wasn’t respected while the laptop was powered off (for a short time after charging start).
Can anyone confirm if this will work if I have an a bootable OS on my expansion card? I’d like to just remove my main drive and I don’t have another nvme.
Stoked that we have charge limits already. I just don’t want to mess with my fedora 35 install if possible.
BIOS would show NVME but BIOS boot options didn’t find it so I assume UEFI boot information was overwritten/deleted somehow, yes. I don’t know enough about UEFI. Yes I had to reinstall GRUB.
I don’t think the update actually modifies any EFI partitions, only wipes the part of NVRAM which stores the registered bootloaders, which is why so many had to reinstall. My bootloader (systemd-boot) appears to both register itself with the EFI and copy itself to the fallback EFI path on the EFI partition (\EFI\BOOT\BOOTX64.efi), so I never noticed until I looked at the EFI boot entries to see that it was booting the drive rather than a named entry (which was restored the next time I ran bootctl install).
Reading the Arch Wiki for GRUB, you have to pass --removable to do get the same behavior:
Tip: If you use the option --removable then GRUB will be installed to esp/EFI/BOOT/BOOTX64.EFI (or esp/EFI/BOOT/BOOTIA32.EFI for the i386-efi target) and you will have the additional ability of being able to boot from the drive in case EFI variables are reset or you move the drive to another computer.
Windows also makes a copy of its bootloader there (in addition to its folder in \EFI\BOOT).
This probably explains the experiences of people in this thread having to reinstall GRUB (but nobody on Windows or systemd-boot are chiming in).
Strange thing happened to me. I upgraded my bios last week and also ran the driver bundle for Windows 11. I have Intel’s driver update tool and it told me there was a WiFi and Bluetooth driver update. Installed both and now like others above my Bluetooth stopped working.
I’ll do some more testing to see if I can figure out the problem. Just thought I would mention it.
Edit: Similarly to a post by @pvp above, Re-installing Bios 3.0.7 seems to have fixed it. I did have Private Internet Access and OpenVPN clients installed. Removed them before doing the Bios re-install so I can’t say that affected anything. Either way it seems strange to me that a Bluetooth driver would affect the firmware this way. Potential bug?
As mentioned last week, I removed my internal SSD prior to running the EFI shell from a USB stick. The update went fine, and I had no problems booting into Linux after I put the SSD back in. I have no storage expansion card.
