Гибернация в раздел SWAP в KDE neon 5.x / Ubuntu 18.04

Сочувствую. В последнее время в линукс завезли уже даже саспенд с последующей гибернацией (когда батарейка на исходе), но у меня за всю жизнь удачно гибернуть (и обратно разбудить) линукс удалось всего несколько раз. Ковырял когда-то этот вопрос, но прилетает апдейт и опять не работает. Или просто само по себе перестаёт работать. Долго-долго хрустит хардом, а потом тупо загружает новую сессию. Грустно с гибернацией в линуксе.

Да вот же, sudo pm-hibernate заработало, только SDDM пароль не просит, и вообще какое-то оно корявое. Хотя, может, оно такое и должно быть...

завезли уже даже саспенд с последующей гибернацией

Это еще интереснее. Но тут хотябы с systemctl hibernate разобраться, для начала.

sudo systemctl hibernate как не работало, так и не работает. Вообще, работать пытается, что-то на диск пишет, но при включении после идет просто загрузка.

Скорее всего память сбрасывается в своп, но при просыпании ядро не считывает его.

В ядре включено Hibernation (aka 'suspend to disk') ? См. https://wiki.gentoo.org/wiki/Suspend_and_hibernate

В GRUB_CMDLINE_LINUX_DEFAULT дописано RESUME=UUID=[uuid своп-раздела]

А ты после этого применил изменение? Что выдает cat /proc/cmdline ?

pm-hibernate работает.

Оно просыпается? Или как и при sudo systemctl hibernate идет загрузка.?

Да, и самое главное: в Grub есть несколько пунктов или только один?

Скорее всего память сбрасывается в своп, но при просыпании ядро не считывает его.

На то и похоже.

В ядре включено Hibernation (aka 'suspend to disk') ?

А как это проверить, если ядро обычное, убунтовское? Вобщем-то↓

~$ cat /sys/power/state
freeze mem disk

Оно просыпается?

Да. Еще и пишет, что образ запиывается. При загрузке пишет, что образ считывается. Запускается сразу в то состояние, минуя SDDM. И терминал с sudo pm-hibernate на первом плане.

применил изменение? Что выдает cat /proc/cmdline ?

Применил.

cat /proc/cmdline
BOOT_IMAGE=/@/boot/vmlinuz-5.0.0-37-generic root=UUID=92e34375-fa9c-44a8-8a97-ed7b3c11333d ro rootflags=subvol=@ mitigations=off RESUME=UUID=df5879c2-c07b-4d4d-8a20-418870fd1742

в Grub есть несколько пунктов или только один?

Четыре.

Загрузка со свежим ядром

Загрузка со свежим ядром в режиме восстановления

Загрузка с прошлым ядром

Загрузка с прошлым ядром в режиме восстановления

Запускается сразу в то состояние, минуя SDDM. И терминал с sudo pm-hibernate на первом плане.

То есть у тебя он засыпает, просыпается, но после просыпания экран не заблокирован; в этом проблема?

Работает ли у тебя вообще блокировка экрана? System Menu > Leave > Lock (рядом с Shutdown, Restart...)?

Включена ли настройка в настройках KDE System Settings > Desktop Behaviour > Screen Locking > tab [Activation], [ * ] Lock screen on resume?

в Grub есть несколько пунктов или только один?

Четыре.
Загрузка со свежим ядром
Загрузка со свежим ядром в режиме восстановления
Загрузка с прошлым ядром
Загрузка с прошлым ядром в режиме восстановления

Я расскажу после чего я перестал пользоваться гибернацией:

Если загрузиться, увести систему в гибернацию, потом загрузиться в «другой пункт», который не поддерживает выход из гибернации, потом перегрузиться и восстановиться из гибернации, то с большой долей вероятности повредятся данные на диске. Связано это с тем, что при гибернации сохраняются кеши, а когда ты временно перегрузился в другое окружение, состояние файловой системы изменилось; получается что данные в кешах (которые хранятся в образе созданном при гибернации) уже не соответствуют реальным данным на диске. Вероятность и величина повреждения, как можно понять, очень варьируются.

По идее от этого можно уйти; например, добавив в каждую загрузку очистку флага о том, что можно восстановиться из образа. Я не копал детально. Но суть моего сообщения в том, что на это следует обратить внимание, и поинтересоваться/проверить.

То есть у тебя он засыпает, просыпается, но после просыпания экран не заблокирован; в этом проблема?

Это неаккуратность, с которой можно было бы смириться, ибо в BIOS есть пароль на запуск. Проблема - pm-hibernate с KDE никак не подружилось, а подружилось с KDE не pm-hibernate, а systemctl hibernate, которое не работает. Или даже что-то другое.

Работает ли у тебя вообще блокировка экрана? System Menu > Leave > Lock (рядом с Shutdown, Restart...)?

Да.

Включена ли настройка в настройках KDE System Settings > Desktop Behaviour > Screen Locking > tab [Activation], [ * ] Lock screen on resume?

Да.

при гибернации сохраняются кеши, а когда ты временно перегрузился в другое окружение, состояние файловой системы изменилось; получается что данные в кешах (которые хранятся в образе созданном при гибернации) уже не соответствуют реальным данным на диске.

на это следует обратить внимание, и поинтересоваться/проверить.

Спасибо за предупреждение, но... мне пока далеко. Да и выбор у меня если есть, то не в грубе, а в SDDM, и не DE то, или DE это, а KDE на иксах, или KDE на вяленьком.

Это неаккуратность, с которой можно было бы смириться, ибо в BIOS есть пароль на запуск. Проблема - pm-hibernate с KDE никак не подружилось, а подружилось с KDE не pm-hibernate, а systemctl hibernate, которое не работает. Или даже что-то другое.

Ну так тогда нужно решить проблему с systemctl hibernate, тогда автоматически решится проблема с блокировкой экрана.

Вот начинай здесь:
https://wiki.archlinux.org/index.php/Power_management/Suspend_and_hibernate#s...
Как минимум там есть раздел Troubleshooting с весьма правдоподобными вариантами, начиная от watchdog'а, заканчивая /etc/systemd/sleep.conf.d/hibernatemode.conf .

Кроме того, если у тебя всё-таки один из вариантов работает, то в systemd можно сменить backend, или как минимум посмотреть что он сейчас использует: https://wiki.archlinux.org/index.php/Uswsusp#With_systemd

Если не получится, говори что пробовал, будет разбираться дальше.

файл подчкачки то есть по размеру ОЗУ?

нужно решить проблему с systemctl hibernate

Именно.

Вот начинай здесь: https://wiki.archlinux.org

Емнип, оттуда и начинал. Может, что-то упустил. Перечитаю, много подумаю, вечером.

Вот начинай здесь: https://wiki.archlinux.org

Емнип, оттуда и начинал. Может, что-то упустил. Перечитаю, много подумаю, вечером.

Я тебе дал более конкретные адреса, плюс подсказал посмотреть troubleshooting и конфиг бекенда. По идее, если у тебя pаботает pm-hibernate, ты можешь заставить systemd использовать его в качестве бекенда.

Перечитаю, много подумаю, вечером.

Ладно, не такой уж я и тормоз. И вообще, я же не уточнил, каким вечером:))

По идее, если у тебя pаботает pm-hibernate, ты можешь заставить systemd использовать его в качестве бекенда.

Ходил по ссылкам, сам еще гуглил, в итоге так и сделал.

Вот тут https://help.ubuntu.ru/wiki/спящий_режим , в самом низу страницы.

Теперь pm-hibernate работает с кнопок KDE. По прежнему настораживает то, что пробуждение происходит минуя SDDM. Ну и ладно.

Спасибо за помощь!

Показ SDDM с запросом пароля «починился сам собой».

Всплыло другое.

Пункт Завешение работы → Спящий режим в меню KDE работает. Иксы тухнут, на tty показывает, как s2disk делает снапшот и пишет образ на диск, проценты бегут, добегают до 100, ноутбук выключается.

В настройках KDE указываю, что критический уровень заряда 10%, что при критическом уровне спящий режим. Батарея разряжается до 10%, показыает уведомление, что через 60 секунд будет спать. Через 60 секунд иксы тухнут, на tty показывает, как s2disk делает снапшот и пытается писать образ на диск, проценты стоят на нуле.

Пробую обойти. Фиг с ним, с критическим уровнем. В настройках KDE указываю, что при низком (а не критическом) уровне надо просто перейти в спящий режим через минуту (меньше минуты там нельзя). Просто вообще ничего. Система работает, батарея продолжает разряжаться.

А основная-то хотелка была, чтобы не было плохо, если я оставлю ноутбук на батарейке без присмотра.

Поставь критический уровень 20% (подбери оптимальное значение большее 10%)

Попробовал. Если установить критический уровень 20%, запись начинается, но останавливается на 7%. Если критический уровень поставить 25%, то всё получается, однако, запись идет заметно медленнее, чем при ручном вызове. Колдунство какое-то. Не удивлюсь, если это еще может (не)срабатывать в зависимости от заполнения RAM.

Есть UPower. Емнип, в настройках KDE не так давно было предупреждение, что дополнительные настройки управления питанием трогать не надо, и они вообще скоро будут выпилены, а для этого надо что-то другое. У соседей, в Гноме, этих настроек и нет. Арчвики рекомеднует им прямо править UPower.conf. Возможно, для KDE это тоже хорошо?.. Вообще отлично, если UPower будет отрабатывать даже если в KDE управление питанием отключено.

Вот что в /etc/UPower/UPower.conf сейчас↓

# Only the system vendor should modify this file, ordinary users
# should not have to change anything.

[UPower]

# Enable the Watts Up Pro device.
#
# The Watts Up Pro contains a generic FTDI USB device without a specific
# vendor and product ID. When we probe for WUP devices, we can cause
# the user to get a perplexing "Device or resource busy" error when
# attempting to use their non-WUP device.
#
# The generic FTDI device is known to also be used on:
#
# - Sparkfun FT232 breakout board
# - Parallax Propeller
#
# default=false
EnableWattsUpPro=false

# Don't poll the kernel for battery level changes.
#
# Some hardware will send us battery level changes through
# events, rather than us having to poll for it. This option
# allows disabling polling for hardware that sends out events.
#
# default=false
NoPollBatteries=false

# Do we ignore the lid state
#
# Some laptops are broken. The lid state is either inverted, or stuck
# on or off. We can't do much to fix these problems, but this is a way
# for users to make the laptop panel vanish, a state that might be used
# by a couple of user-space daemons. On Linux systems, see also
# logind.conf(5).
#
# default=false
IgnoreLid=false

# Policy for warnings and action based on battery levels
#
# Whether battery percentage based policy should be used. The default
# is to use the time left, change to true to use the percentage, which
# should work around broken firmwares. It is also more reliable than
# the time left (frantically saving all your files is going to use more
# battery than letting it rest for example).
# default=true
UsePercentageForPolicy=true

# When UsePercentageForPolicy is true, the levels at which UPower will
# consider the battery low, critical, or take action for the critical
# battery level.
#
# This will also be used for batteries which don't have time information
# such as that of peripherals.
#
# If any value is invalid, or not in descending order, the defaults
# will be used.
#
# Defaults:
# PercentageLow=10
# PercentageCritical=3
# PercentageAction=2
PercentageLow=10
PercentageCritical=3
PercentageAction=2

# When UsePercentageForPolicy is false, the time remaining at which UPower
# will consider the battery low, critical, or take action for the critical
# battery level.
#
# If any value is invalid, or not in descending order, the defaults
# will be used.
#
# Defaults:
# TimeLow=1200
# TimeCritical=300
# TimeAction=120
TimeLow=1200
TimeCritical=300
TimeAction=120

# The action to take when "TimeAction" or "PercentageAction" above has been
# reached for the batteries (UPS or laptop batteries) supplying the computer
#
# Possible values are:
# PowerOff
# Hibernate
# HybridSleep
#
# If HybridSleep isn't available, Hibernate will be used
# If Hibernate isn't available, PowerOff will be used
CriticalPowerAction=HybridSleep

Возможно, сто́ит попробовать поменять значения процентов и сделать CriticalPowerAction=Hibernate ...

Блин. Пробовать надо, батарейку разряжать... Очень не хочется эту батарейку самостоятельно прибить. Неделю пережила, надеюсь, и год теперь проживет.

По KDE и UPower не подскажу. Судя по Вашему изложению батарейка довольно быстро разряжается при работе. Я использую Suspend (сон в памяти) не от хорошей жизни: аккумулятор практически мгновенно разряжается до критического значения — до перехода в Hihernate он не дотянет. В то же время «во сне» он держится 2..12 часов (смотря, как ноут «уснул»). Этого обычно хватает, чтобы добраться «до розетки».

Судя по Вашему изложению батарейка довольно быстро разряжается при работе.

Это новая батарея. Её хватает на 3-4-5 часов, в зависимости от работы. Всё это я затеял для случая, когда я выработаю батарейку и забуду нормально выключиться.

По KDE и UPower не подскажу.

А я уже сам попробовал. В настройках KDE поставил низкий и критический уровень по нулям, и чтобы при критическом уровне вообще ничего не делать - т.е., чтобы Кеды просто этим не занимались. UPower.conf поправил так↓

...

PercentageLow=15
PercentageCritical=12
PercentageAction=10

...

TimeCritical=2
TimeAction=1

...

CriticalPowerAction=Hibernate

Таким образом гибернация не просто срабатывает при разряде до 10%. Если в KDE отключить управление питанием, гибернация тоже срабатывает.

Вобщем, пока хорошо. Некоторым образом, даже лучше, чем предполагалось.

------------

Я даже уже разбаловался и начал следующую мысль думать. Когда в BIOS включена «долгая жизнь батареи», то батарея заряжается до 80%. Зарядка прекращается, лампочка на ноутбуке зеленеет. А вот Кеды показывают, что 80%, что заряжается, еще и время до полного заряда показывают. Хорошо бы Кеды научить определять, когда 80% - это уже всё заряжено, а не ещё заряжается. Но это, наверное, уже другая тема.

+1

Месяц почти система прожила с этим pm-hibernate. За это время (под настроение) успел попробовать в разных ситуациях. Часто при попытке гибернации процент записи замерзает с разными значениями. Закономерности не заметил.

Чтобы всё же сберечь батарейку, сделал в UPower.conf

... 
PercentageAction=9
...
CriticalPowerAction=PowerOff

Возможно, от того в Убунтах гибернация и не включена из коробки. Всё, вроде как, для неё есть... А в целом - не рабочее.