How to diagnose & fix Arch Linux not waking up from hibernation?

12,340

Solution 1

I had had this issue with Arch Linux-hardened 4.12.5 and Linux 4.12.4. After I went to a huge number of pages full of solutions all of them, I did this:

sudo pacman -Rs acpi
sudo pacman -S acpi
sudo pacman -S linux-lts linux-lts-headers
grub-mkconfig -o /boot/grub/grub.cfg
mkinitcpio -p linux-lts

If the issue has gone after reboot:

sudo pacman -Rs linux-hardened (linux) linux-hardened-headers (linux-headers)
grub-mkconfig -o /boot/grub/grub.cfg
mkinitcpio -p linux-lts

It worked for me.

Solution 2

I had the same issue too. You need to rewrite the grub configs. It might be that yaourt, with which I used to install updates, was not able to update the grub configs. I am checking it.

The manual reconfiguration as explained by Azrael worked for me:

grub-mkconfig -o /boot/grub/grub.cfg
mkinitcpio -p linux-lts
Share:
12,340

Related videos on Youtube

l0b0
Author by

l0b0

Author, The newline Guide to Bash Scripting (https://www.newline.co/courses/newline-guide-to-bash-scripting). Hobby (https://gitlab.com/victor-engmark) & work software developer.

Updated on September 18, 2022

Comments

  • l0b0
    l0b0 almost 2 years

    Some update in the meantime has solved this problem.


    This works again I spoke too soon. It turns out the system only locks up if power is connected. So it's related to power handling, but not in any way I can detect. The workaround is to unplug power, close the lid again, wait for a few seconds, and open the lid again.

    After a successful wake-up the journal looks like this:

    systemd[1]: Started Suspend.
    systemd[1]: sleep.target: Unit not needed anymore. Stopping.
    systemd[1]: Stopped target Sleep.
    systemd[1]: Reached target Suspend.
    systemd[1]: suspend.target: Unit is bound to inactive unit systemd-suspend.service. Stopping, too.
    systemd[1]: Stopped target Suspend.
    systemd-logind[480]: Operation 'sleep' finished.
    

    Recently my laptop has stopped waking up properly after re-opening the lid. The screen backlight comes on, so something is clearly happening, but I don't get the standard slock password "prompt" of a blue screen while typing.

    I've tried "blindly" typing my password, opening a shell and running reboot. I've also tried pressing Ctrl-Alt-F2 to try to change to a virtual terminal, entering my username and password, and running reboot. Neither of these work, so presumably the system hasn't woken up enough to activate the keyboard yet. I have verified that changing to a virtual terminal works while in slock, so the wake-up process can't have reached that state yet. There is no SysRq key on the keyboard.

    journalctl for the relevant --boot simply ends with it hibernating.

    I don't have an external monitor attached.

    This is 100% reproducible.


    I have just tried an alternative tack:

    1. Quit awesome WM.
    2. Ensure xss-lock died with awesome by checking the process list in a VT.
    3. Go back to the awesome WM login screen.
    4. Close the lid.
    5. Open the lid after a few seconds.

    And once again I got the empty screen. Interestingly, after quickly pressing and releasing the power button the login screen showed up again, which it never did in a logged in state. However, neither the keyboard nor the mouse worked (even to change to a VT) so I still had to hard boot. The end of the journal looks like this:

    $ journalctl --boot=-1 | tail -n2 | cut -d' ' -f5-
    systemd[1]: Starting Suspend...
    systemd-sleep[1840]: Suspending system...
    

    My setup is defined in two repos, one for desktop settings and another for the overall system. I regularly (almost every day) update all the software. I am using the i915 video driver. The machine is a Samsung ATIV Book 9 Spin.

    • Admin
      Admin over 7 years
      Did you try it without slock, or even on a tty? What is in the logs: journalctl -xe?
    • Admin
      Admin over 7 years
      Does this only happen when you have an external screen attached by any chance? I had something similar a while ago, where leaving the X server in any way would result in similar symtoms and it turned out to be related to the graphics drivers and how they were dealing with external screens. Are you using the latest versions of your graphics drivers?
    • Admin
      Admin over 7 years
      Most likely it was the kernel upgrade. You could also try removing the intel driver and using native modesetting.
    • Admin
      Admin over 7 years
      @jasonwryan I don't know what "native modesetting" means, and Google + the Arch Linux kernel mode setting page aren't telling. Would you mind expanding on it?
    • Admin
      Admin over 7 years