Modifying the hibernation mode
Hi, I've experienced a couple of problems with the default "platform" kernel hibernation mode on my laptop (basically, sometimes the hibernation image fails to resume, leading to a reboot), so I've been testing the steps shown here . In fact, changing to "shutdown" mode does work. There is a way to force systemd to use a specific mode/state configuration by means of creating
/etc/systemd/sleep.conf according to
man systemd-sleep.conf. I'd add this to the wiki, but I'm not sure which is the most appropriate section to add this information, whether Power management#systemd or Power management#Troubleshooting. --Eugenio M. Vigo (talk) 16:41, 28 March 2016 (UTC)
- I think you can put it under Power_management#Power_management_with_systemd, since sleep.conf isn't mentioned at all in the article yet, and the new section could be expanded and generalized. In any case we're always in time to move it somewhere else if needed. — Kynikos (talk) 07:07, 30 March 2016 (UTC)
Suspend on LynxPoint
I had to disable SLPB and JMC2 too, to avoid instantaneous wakeups from suspend. Should we add this to the list of acpi devices in the "Suspend on LynxPoint" section? Dervomsee (talk) 11:54, 5 March 2017 (UTC)
Is the introduction too long?
- Admittedly the introduction is quite lengthy but nevertheless descriptive and it provides the necessary information to understand the following chapters. IMHO I would keep it as it is. -- Edh (talk) 19:13, 15 November 2017 (UTC)
- Right, I already assumed, that you were just intending to move stuff around without changing the content. Nevertheless I still think that the current introduction is the way to go since it is essential for understanding the following content. However feel free to disregard my opinion. I do not feel to strongly about it. -- Edh (talk) 20:59, 16 November 2017 (UTC)
Suspend then hibernate
To be honest, I find this article somewhat underwhelming when it comes to dealing with modern suspend/hibernation methods.
1. I have personally set up my system to use Intel Rapid Start Technology (IRST), which works great for my purposes, on my machine. Unfortunately it seems that there is virtually no information on IRST on the Arch Wiki.
2. Other than IRST, this page does not make any mention of configuring suspend-then-hibernate (briefly mentioned here).
Both suspend-then-hibernate methods are better than "suspend to both", IMO, since there will be a much shorter delay before going to sleep, and the system will always hibernate after the timeout is reached, rather than when the battery is nearly depleted. This means that you can close your laptop lid, and leave it for a few days yet always be certain that you have a fairly decent amount of battery power left once you resume your system.
Is there a reason this wiki article does not include information on either method, or would it be appreciated if I put time into adding instructions on how to enable them?
Or, in the case of IRST, we should perhaps create a separate page for it? It can then include a list of laptops verified to work with it, since it seems to depend on firmware/BIOS support.
- Just because some information is not there does not mean that it is missing.
systemctl suspend-then-hibernateshould work out of the box assuming that suspend as well as hibernate, both of which are fairly well documented, actually work. The action that should happen when you close the lid can be configured as described in Power management#ACPI events which also includes
suspend-then-hibernate. -- Lahwaacz (talk) 09:39, 17 February 2019 (UTC)
- Note that IRST does not encrypt the contents of the RAM before saving them to disk. The recommended way to achieve disk encryption with IRST is to use ATA disk encryption which is not considered as secure as software based solutions. Lucaspiller (talk) 08:38, 11 March 2019 (UTC)
- On suspend-then-hibernate, I've found in this forum that the only effective way to set it up is using a symlink...
# ln -s /usr/lib/systemd/system/systemd-suspend-then-hibernate.service /etc/systemd/system/systemd-suspend.service. I've tried the following in
/etc/systemd/sleep.confwith no success:
SuspendState=suspend-then-hibernate suspension is not enabled.
Being curious I tried
SuspendState=mem standby freeze suspend-then-hibernate, but it only leads to suspension in memory and never trying hibernation.
Although the man page
man systemd-sleep.conf mentions
SuspendMode=, HibernateMode=, HybridSleepMode= The string to be written to /sys/power/disk by, respectively, systemd- suspend.service(8), systemd-hibernate.service(8), systemd-hybrid- sleep.service(8), or systemd-suspend-then-hibernate.service(8). More than one value can be specified by separating multiple values with whitespace. They will be tried in turn, until one is written without error. If neither succeeds, the operation will be aborted.
SuspendState=, HibernateState=, HybridSleepState= The string to be written to /sys/power/state by, respectively, systemd- suspend.service(8), systemd-hibernate.service(8), systemd-hybrid- sleep.service(8), or systemd-suspend-then-hibernate.service(8). More than one value can be specified by separating multiple values with whitespace. They will be tried in turn, until one is written without error. If neither succeeds, the operation will be aborted.
systemctl suspend-then-hibernatenot work for you? Systemd supports the actions
suspend-then-hibernate, but it does not support one action to replace another. Hence, suspend will always suspend and not suspend-then-hibernate. If you want to suspend-then-hibernate, you need to suspend-then-hibernate. Or if you use some kind of GUI or power manager which supports only suspend, you need to extend it to support suspend-then-hibernate. Or stop using it and use systemd directly. -- Lahwaacz (talk) 17:19, 10 November 2019 (UTC)
- You're totally right, I've found that out too late. Either
suspendis called, or
suspendis not supposed to call later the hibernation itself. KDE/Plasma/PowerDevil has not yet implemented the corresponding call to
suspend-then-hibernate. The aforementioned forum mentions that KDE should show a new option for Suspend then hibernate for PowerDevil 5.17, but as of 9-Nov-19 and v5.17.2, it is still not available. Nicoadamo (talk) 18:52, 10 November 2019 (UTC)
- On a new install (February 2020), I'm having trouble setting up suspend-then-hibernate following the instructions here.
sudo systemctl suspend-then-hibernateworks unproblematically, after setting up hibernate as described in that section. But if I add the line
SuspendMode=suspend-then-hibernateor try setting the Gnome suspend function to suspend-then-hibernate with
gsettings set org.gnome.settings-daemon.plugins.power sleep-inactive-ac-type suspend-then-hibernateI get an error along the lines of
Failed to suspend system via logind: Sleep verb "suspend" not supported. I suspect that the documentation is incorrect somewhere but am not sure what to do about it. All packages are up to date as of Feb 24, 2020. titaniumbones
- ah, I was misunderstanding your previous post. Does this mean that I should be able to use
HibernateDelaySec=1800in /etc/systemd/logind.conf, instead? That also is not currently working for me, though maybe it is being overridden by Gnome. I'm a little uncertain what level I need to be working at to address this issue. —This unsigned comment is by Titaniumbones (talk) 22:32, 24 February 2020. Please sign your posts with ~~~~!
- ah, I was misunderstanding your previous post. Does this mean that I should be able to use
Suspend/hibernate does not work, or does not work consistently
The article is right: using
linux-lts and an empty
/etc/mkinitcpio.conf, awaking from hibernation is successful. But if using radeon drivers for video and SDDM,
/etc/mkinitcpio.conf is mandatory for the initial boot since some update back in September, 2019. Consequently, this results in a loop... Was anyone successful to set hibernation with radeon and SDDM? Nicoadamo (talk) 16:09, 10 November 2019 (UTC)
- I confirm that using AMDGPU hibernation works fine on a quite old AMD A10 7300 (Radeon R7 M265 codenamed Sea Islands). Nicoadamo (talk) 12:57, 17 November 2019 (UTC)
systemd-tmpfiles for setting image_size permanently
In section "About swap partition/file size", it says "See systemd#systemd-tmpfiles - temporary files to make this change persistent." However, the article about systemd-tmpfiles linked warns "Note: This method may not work to set options in /sys since the systemd-tmpfiles-setup service may run before the appropriate device modules are loaded." If it is the case that systemd-tmpfiles will always work for writing to the /sys/power/image_size file, it would be nice if the aforementioned section clearly says so and thus eases any potential worry. If it is the case that systemd-tmpfiles won't always work for writing to the /sys/power/image_size file, it would be nice if the aforementioned section recommends a different way to make the change permanent or at least clearly says that the systemd-tmpfiles method may only work sometimes. Does anyone know if systemd-tmpfiles will always set the value of /sys/power/image_size correctly? Ricardo (talk) 04:47, 8 February 2022 (UTC)