hibernate, write-error on swap-device

Ты используешь в качестве свопа «zram + физический раздел диска»?

Обычно, кто так же делает, регулируют порядок работы выставлением приоритета и считают, что все ок. Но, видно, все же не все ok и лучше юзать zswap, если хочется задействовать физические разделы для свопа.

Это мысли в слух. На самом деле, я не знаю причины сбоя.

Выглядит так, как будто он не может усыпиться на zram. Но нет, быть не может чтобы этот вопрос не был уже решён... Не верю!

Но кстати проверить можно одним swapoff'ом.

Если бы он не мог это сделать вообще он бы всегда сыпал эти ошибки. Но гибернация иногда работает, иногда нет. Вот два дня назад её делал (аптайм был 10 дней) - всё норм получилось, сегодня сделал - пришлось ребутаться.

Усыпляться на zram конечно нельзя, но у меня есть настоящий свап-раздел же, 16гб при том что памяти 8гб. И, кажется, пока было 4гб памяти + 8гб (а может 4 - не помню) свапа, тоже с zram-ом - ни разу такого не случалось.

Поэкспериментируй с zramом и приоритетами разделов. Ну и может диск что ли проверить?

Или вот этот приоритет -2 что должен значить? Это же не 0 - использовать в последнюю очередь.

-2 это значит использовать когда закончатся те у кого 0 и -1.

Экспериментировать особо негде, это придётся вывести ноут из работы и посвятить время попыткам повторить эти сбои специально.

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

Попробую zram убрать, посмотрю что будет. Всё равно он уже не особо актуален, делал его когда 4гб памяти было.

Арчвики пишет, что при использовании «zram+свопфайл», systemd само игнорирует zram при переходе в спящий режим.

Но у тебя-то нет systemd. )

systemd тут ни при чём, гибернацию делает ядро.

Там четко написано, что systemd игнорирует блочные устройства zram при гибернации, дополнительное вмешательство не требуется. systemd предоставляет высокоуровневый интерфейс управления сном.

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

При запуске pm-hibernate

А зачем ты его запускаешь? systemctl hibernate же.

Там четко написано, что systemd игнорирует блочные устройства zram

Повторю ещё раз, системг гибернацией не занимается, всё что он может сделать - отправить соответствующую команду ядру.

А зачем ты его запускаешь? systemctl hibernate же.

Затем что это штатная команда дебиана для гибернации (она, разумеется, тоже отправляет команду ядру для этого, а перед этим выполняет разные хуки). И она работает, как минимум если её запускать с маленьким аптаймом, да и с не маленьким она тоже иногда работает. А раньше работала всегда (в рамках того же самого debian 11 который и сейчас стоит).