That command does work, so I guess it is definitely a system related problem?
If there's any output from the command please post it here. Also
right after issuing the command.
I'm confused, I thought we only cared about the systemctl hibernate command if the laptop didn't hibernate on that command? There was no output to that command, and it worked perfectly. Should I be doing the journalctl command with the lid close/suspend button that doesn't work?
Sorry, by reading the last part of the above sentence I missed the "does work" part. If that command works, than it isn't a system problem. The problem lies in your DE. I'm not experienced with Gnome. You can set the behavior you want using shortcuts or rules and overriding Gnome settings. But maybe someone more knowledgeable about Gnome can help you on this.
EDIT: reproduce the failed hibernation using Gnome and then post the output of
journalctl -xe -p3 -b
Update: We've determined that this issue is related to Bluetooth being enabled, and it persists across two completely different laptops models in our office (see original post, which I've updated).
This seems like a Gnome or Manjaro bug.
You will need to unload the Bluetooth modules before suspending, and then load the Bluetooth modules after resume. This can be done by creating systemd unit files and scripts to load/ unload your Bluetooth modules. Substitute your Bluetooth modules for the wifi modules in the example scripts in the following thread:
You may also find this can be cured by testing different kernels, good luck.
Eeek.. thanks, @tbg.
In that link, it doesn't mention how to write the start script. Do you mind sharing the differences to get the script to load the module on resume? Or a link that explains that?
EDIT: Also, and idea which is the correct bluetooth module to unload? I tried:
modprobe -r bluetooth
which led to no change in the behavior. Laptop is still resuming immediately upon suspend.
The script is simply the relevant modprobe commands that work to unload/load your bluetooth modules.
I don't know which bluetooth modules your laptops use. I would assume "btusb".
sudo modprobe -r btusb
sudo modprobe btusb
Run each command before suspend & then after resume to test if it works correctly.
To find which bluetooth modules are loaded run an "lsmod" command. Any modules with "bt" in the name are likely involved. Try adding them to your modprobe commands until it works for you.
Make sure you do this^^
So... progress. The unloading part is working with btusb, and it is successfully suspending. However, the loading of the module after resume isn't working and I can't figure out why...
Here are my two resume related files:
#!/bin/bash modprobe btusb
[Unit] Description=Bluetooth module suspend helper Before=sleep.target [Service] Type=simple ExecStart=-/usr/bin/bluetooth-resume.sh [Install] WantedBy=sleep.target
I also ran the following commands after creating those two resume scripts:
[brad@merlin-xiaomi-1 ~]$ sudo chown root:root /usr/bin/bluetooth-resume.sh [brad@merlin-xiaomi-1 ~]$ sudo chmod +x /usr/bin/bluetooth-resume.sh [brad@merlin-xiaomi-1 ~]$ sudo systemctl enable bluetooth-resume.service Created symlink /etc/systemd/system/sleep.target.wants/bluetooth-resume.service → /etc/systemd/system/bluetooth-resume.service. [brad@merlin-xiaomi-1 ~]$ sudo systemctl start bluetooth-resume.service [brad@merlin-xiaomi-1 ~]$ sudo chown root:root /etc/systemd/system/bluetooth-resume.service [brad@merlin-xiaomi-1 ~]$ sudo chmod +x /etc/systemd/system/bluetooth-resume.service [brad@merlin-xiaomi-1 ~]$ sudo systemctl enable bluetooth-resume.service [brad@merlin-xiaomi-1 ~]$ sudo systemctl start bluetooth-resume.service
After resuming, modprobe btusb does bring back my bluetooth when run manually.
As for the kernel side of it... I've already tried 4.14, 4.16, and 4.17 with no dice
Other bluetooth related modules may be required to be loaded before btusb. Check your lsmod output as I stated earlier.
ps. nicely done on not requiring hand holding creating the required files.
I'm on my phone. Hard to read complicated outputs. It looks like you forgot to make the resume script executable.
(edit) Sorry, bad vision.
Does the resume script work if called via sudo from the terminal.
systemctl status bluetooth-resume.service
Script works if run manually from the terminal. I've tried unloaded and reloading with it several times successfully.
[brad@merlin-xiaomi-1 ~]$ systemctl status bluetooth-resume.service ● bluetooth-resume.service - Bluetooth module suspend helper Loaded: loaded (/etc/systemd/system/bluetooth-resume.service; enabled; vendo> Active: inactive (dead) Aug 02 17:55:21 merlin-xiaomi-1 systemd: Started Bluetooth module suspend he> lines 1-5/5 (END)
Perhaps change script to:
wait 10; modprobe btusb
Interesting... wait 10; did not work, but wait 15 seems to work inconsistently. I'm going to try tweaking that to find the magic number and make sure that wasn't a fluke.
Sigh... I really don't understand what is going on here. Even if I set wait to 50, it seems to work very inconsistently (maybe 30% of the time?). I can't understand why it works some times and not others...
Hm, I don't get it either. That's very strange. Perhaps others have some idea why. At least a manual modprobe works if the auto resume fails. So at least the main problem is mostly resolved.
I'll see if I can come up with any other ideas.
Your systemd resume unit is wrong.You reused the suspend file. Doublecheck all.
See Part 2 in the original post I linked.
On my phone, it's hard for me to catch details properly.
Hope i'm not butting in the way this reads to me bluetooth is set to resume the laptop state, that is normally a bios setting the same as resume from keyboard,or resume from usb. a quick check of the motherboard settings may help you.
If not I butted in for nothing.