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
I am curious to know which feature or fix in the BIOS changelog improved the battery life dramatically.
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.
Great stuff 
Now about that fn lock indicator…
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):
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 itSimilarly 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
I haven’t attempted to reproduce this yet.
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?
Context:
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
--removablethen GRUB will be installed toesp/EFI/BOOT/BOOTX64.EFI(oresp/EFI/BOOT/BOOTIA32.EFIfor thei386-efitarget) 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).
Getting an error when installing via a usb drive with EFI.
My machine is the Intel i7-1185G7
Arch Linux, about a week post-update via USB. Everything is running smoothly on my end.
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.
If his worked for you, then the theory from @RandomUser that that the BIOS update requires space on an internal drive can’t be right. So either the EFI script doesn’t need an internal drive but will corrupt it if present OR @Jake_Bailey is correct and its simply the NVRAM being cleared and only partitions with an EFI fallback will survive the firmware update without rescue. If the later diagnosis is correct removing the nvme drive won’t help me because success will depend upon how Fedora 35 configured my EFI.
If the later diagnosis is correct removing the nvme drive won’t help me because success will depend upon how Fedora 35 configured my EFI.
@patch If you are worried about this, you could always verify what’s on your EFI partition (it should be mounted, otherwise dnf couldn’t rerun grub or systemd-boot), and copy the bootloader to the backup location if it’s not already present. That’d put you in the same position as me, where I used a flash drive to run the update and was able to boot into it. I will say that there’s a suspicious folder \EFI\Insyde on my SSD’s UEFI partition, which is the company that supplied the BIOS/flasher, so that’s not good, but clearly people are able to update without their main drives installed too.
Of course, it’d be best if BIOS updates didn’t wipe the EFI part of NVRAM (I’ve never had a system that wiped this on update), but…
Good point.
# tree /boot/efi
/boot/efi
├── EFI
│ ├── BOOT
│ │ ├── BOOTIA32.EFI
│ │ ├── BOOTX64.EFI
│ │ ├── fbia32.efi
│ │ └── fbx64.efi
│ └── fedora
│ ├── BOOTIA32.CSV
│ ├── BOOTX64.CSV
│ ├── gcdia32.efi
│ ├── gcdx64.efi
│ ├── grub.cfg
│ ├── grubia32.efi
│ ├── grubx64.efi
│ ├── mmia32.efi
│ ├── mmx64.efi
│ ├── shim.efi
│ ├── shimia32.efi
│ └── shimx64.efi
Looks like I should have a bootable OS after the update. Weird that the flasher does end up writing to the EFI partition though. I’ll give the update a whirl with my drive removed anyway then.
I’m still a little confused about what is being stored in nvme that is necessary here and how that interacts with the boot process, but I think I need to do more reading on how EFI booting works.
Update: Success.
Ok, so I took out all bootable things (nvme, 1tb expansion) and only had the usb drive in. Then it worked.
It seems the EFI USB stuff is using a hard coded location for something… maybe?
