Battery drains completely while in suspend mode (Lenovo Yoga 7i)

Hi there,

I have been using Zorin 16 Pro on my Levono 7i that I bought about two months ago. One thing I've noticed is that my battery drains incredibly fast with the lid closed and the computer suspended. I often find the battery go from nearly 100% full to completely dead just by leaving my computer in suspend mode overnight. Incredibly frustrating!

I have tried to resolve this issue by following the advice in some other threads (tried TLP, slimbook battery, etc) but nothing has worked.

After doing some more research I learned from a reddit thread that this is likely related to the fact that my laptop does not support Ubuntu deep sleep S3 state. I confirmed this by entering

cat /sys/power/mem_sleep
into terminal and getting this output:

I then found this thread for another Lenovo laptop where someone gives instructions for enabling S3 for that model. I was wondering if anyone might be able to help me figure out if these instructions could be applied to the Yoga 7i running Zorin 16, or if this will damage my computer.

Or if anyone had any other advice, that would be appreciated too. My computer is barely usable in this state and if I can't fix this I'd consider myself out of $700.

This will not damage your computer or battery. The worst that may happen is that you won't see an improvement.
I recommend that you calibrate the battery after making the configuration change.
Calibration is done by not using the charger while using the computer and letting it run until the battery fully dies. Then charging it fully without using it.
A full cycle or two of this will calibrate.


Thank you so much for the helpful reply! I will give this a shot and report back.

1 Like

I read that Thread a few times. So I can figure out that in this case, the thread of another Lenovo and bat-drains in sleep, the terminal commands "solved" the issue.
Well .... I really must say upfront I am not too keen on writing howto's in the blind and out of context or reverse of the things you are about to do. So please do not shoot me if things go wrong, I will NOT test this on my 100% good working Dell lol.
Here we go (please think 3 or more times before you just implement unreliable data from an unreliable source !!!! )

sudo apt update

sudo apt install sysfsutils

sudo echo "power/mem_sleep = deep" > /etc/sysfs.d/99-deep-sleep.conf

These 3 commands should be copied/ pasted in the terminal 1 by 1 .
For the last command I don't know if a reverse of the command is really possible, maybe some other experts can help a little here. But I 'think' it cannot be reversed. Anyhow ..... you can always do a fresh new installation and that brings me to a small tip: try a newer kernel from Ubuntu's mainline source.

Read all about in this little howto I made (click here)

1 Like

Almost anything can be reversed.:wink:

You could try
echo deep | sudo tee -a /sys/power/mem_sleep

You also can use your file manager and text editor to undo a change.
Navigate to /sys/power and right click mem_sleep and select open in Text Editor.
It should show:

s2idle [deep]

You can change that to shallow, for example:

s2idle [shallow]

Note: Changing to to shallow would result in higher battery use than the setting as Deep would.

Another option would be to enable and configure Hibernation on your build of Zorin OS, including a Swap Partition. Hibernation defaults to deep sleep as well.

hahahaha !!! Of course, but I got a little confused when the Terminal showed me this as 'Map or File does not exists' (red line in my screenshot = in Dutch my native language)
Schermafdruk van 2023-02-08 21-26-22

As said .... I get goosebumps when giving tips or howto's I am not sure if my system understands them or ..... give errors on a first check. So apt install sysfsutils is not a really innocent terminal command. I recon you can purge it .... but I don't like this kind of working in a good running Linux. Lol ....... But thank you for shining the extra light on the subject. It is a Zorin Pro after all. @Aravisian

Completely understandable - especially as Battery, sleep, suspend are all tricky anyway.
I assume the O.P. has already ensured BIOS Updated - it is an important factor.


Remember the old style of Notebook batteries that had to be cycled before first use? Do that with a brand new Lithium-ion battery and watch it die! This happened when the service I worked for purchased new batteries for a Toshiba notebook.

Chris Titus Tech has done a great YouTube video on how to prolong battery life on a GNU/Linux notebook for up to 12 hours!

Sorry for the delayed reply and thanks everyone for your input!

So this method doesn't seem to work with my model, unfortunately. There must be something deeper here but I have no idea how I would go about fixing this. Entering the suggested command returns:

# echo deep >/sys/power/mem_sleep
bash: echo: write error: Invalid argument

I'm relatively new to Linux, but I assume this is my computer's way of telling me it doesn't know what I'm asking. After spending an hour reading about the new "modern standby" technology (which I guess isn't actually "suspend" so that the computer continues to drain battery as if it were in use) it boggles my mind why Lenovo or anyone else would implement this, or at least why they would make it involuntary.

Any idea how I might go about reversing this, enabling the "deep" or S3 function?

Thanks again!

I came across this guide trying to find more information that may be helpful:

It is comprehensive and detailed. And unsurprising... I already knew that Lenovo dislikes Linux...


Oh nice find, thanks! Gonna dive in right now...

1 Like

I followed the instructions, rebooted, and it didn't work. Not sure where I went wrong. Most of the commands seem to have gone through (or so I assume since there was no error or even any output in most cases).

The only exception might be the very last step at the end (the "Overriding the DSDT" section). The command sudo update-initramfs -k all -u returned the following:

update-initramfs: Generating /boot/initrd.img-6.0.9-060009-generic
W: Possible missing firmware /lib/firmware/i915/tgl_guc_69.0.3.bin for module i915
W: Possible missing firmware /lib/firmware/i915/adlp_guc_69.0.3.bin for module i915
W: Possible missing firmware /lib/firmware/i915/skl_guc_70.1.1.bin for module i915
W: Possible missing firmware /lib/firmware/i915/bxt_guc_70.1.1.bin for module i915
W: Possible missing firmware /lib/firmware/i915/kbl_guc_70.1.1.bin for module i915
W: Possible missing firmware /lib/firmware/i915/glk_guc_70.1.1.bin for module i915
W: Possible missing firmware /lib/firmware/i915/kbl_guc_70.1.1.bin for module i915
W: Possible missing firmware /lib/firmware/i915/kbl_guc_70.1.1.bin for module i915
W: Possible missing firmware /lib/firmware/i915/cml_guc_70.1.1.bin for module i915
W: Possible missing firmware /lib/firmware/i915/icl_guc_70.1.1.bin for module i915
W: Possible missing firmware /lib/firmware/i915/ehl_guc_70.1.1.bin for module i915
W: Possible missing firmware /lib/firmware/i915/ehl_guc_70.1.1.bin for module i915
W: Possible missing firmware /lib/firmware/i915/tgl_guc_70.1.1.bin for module i915
W: Possible missing firmware /lib/firmware/i915/tgl_guc_70.1.1.bin for module i915
W: Possible missing firmware /lib/firmware/i915/dg1_guc_70.1.1.bin for module i915
W: Possible missing firmware /lib/firmware/i915/tgl_guc_70.1.1.bin for module i915
W: Possible missing firmware /lib/firmware/i915/adlp_guc_70.1.1.bin for module i915
W: Possible missing firmware /lib/firmware/i915/dg2_guc_70.1.2.bin for module i915
W: Possible missing firmware /lib/firmware/i915/adlp_dmc_ver2_16.bin for module i915
W: Possible missing firmware /lib/firmware/i915/dg2_dmc_ver2_06.bin for module i915
update-initramfs: Generating /boot/initrd.img-5.15.0-58-generic
update-initramfs: Generating /boot/initrd.img-5.15.0-56-generic

Edit: I should note I also didn't complete the last part
"patching the kernel" since I don't think I use one?

This is a normal warning and only means that there is a "placeholder" in the kernel for firmware additions for the future. Since they are not yet actually present, the system concludes that it is possible that some firmware is missing. Please see here:

There is no need ; you are not using a manually patched kernel.

Hmmm... I am stumped. Let's keep looking...

1 Like

It is not really on purpose lol. But Lenovo is pure aiming for the Asian market, China mostly. So that means like other brands such as, Acer, Packard Bell and some exotic Brands from Taiwan are not really aiming at all for being compatible with Linux on the Western market (such as Europe and America/ Canada).
So besides the Golden Standard Lenovo has with the Thinkpads everything else is actually Windows, Microsoft only. Consumer series of Lenovo are much away from the industrial standards IBM has set up years ago.
You know the drill: cheaper, exclusiveness, and so on ......
Sadly they prompt these computers as well in the West, but the real intentions behind it is aiming for the Chinese, Taiwan, ...., market.

I've heard that the most recent Thinkpads are now as well off industrial standard.
But this is a rumour.

1 Like

The link suggests that 5.8 kernel works while 5.11 does not. It does not mention 5.15... so, just in case:

sudo apt install linux-headers-5.8.0-63-generic linux-modules-5.8.0-63-generic linux-modules-extra-5.8.0-63-generic linux-image-5.8.0-63-generic

Reboot > Advanced Options > Select to boot from the 5.8 Kernel
The 5.8 kernel can be tested to see if you get better results on it.

Strangely, my trackpad/mouse is completely unresponsive when I boot into 5.8, and there's also no way to connect to WiFi. (Not that I would be able to click on it anyway, but the network settings icon disappears from the taskbar.) Unfortunately I don't have a way to try connecting via cable, so I can't run any upgrades or even install net-tools from terminal.

Seems like my only route would be to try the unlock BIOS method. Or is this a bad idea?

Perhaps a safer option would be this tool which apparently allows you to boot an alternative BIOS from a flash drive. It was suggested here in the "issues" section of the yoga-bios-unlock github linked to in the post above.

Edit: Just realized both these methods (the BIOS unlocking you linked to and the boot-from-USB method) are specified for the Yoga AMD models. My model is Intel Evo. Not sure if that matters?

Edit #2: Okay, tried the boot-from-USB method. I was able to boot the main BIOS menu, but the "Device Manager" screen doesn't show any devices. Makes sense, I suppose... there are no AMD devices here to be found, after all. Should I assume the other unlock BIOS method you linked to would also not work for Intel?

i agree with this. I was actually not even looking at the BIOS unlock method, but rather:

Re execute the command, there is a typo.
Put a space after > or it won't work, after you correct the typo reboot, you'll solve that.
At least with my cousin's laptop it did.

1 Like

Well spotted, eagle eye.