Системда и Гибернация: непонятки

Маны по systemctl-hibernation читал, не нашел ответа. Может плохо читал, буду благодарен, если ткнете носом

systemd-hibernate-resume-generator(8):

systemd-hibernate-resume-generator is a generator that initiates the procedure to resume the system from hibernation. When resume= kernel command line option or HibernateLocation EFI variable is detected, it enables the systemd-hibernate-resume.service(8) unit, which will instruct the kernel to resume the system from the hibernation image.

откуда оно берет это устройство

/proc/cmdline

как его отключить/убрать/высверлить

Убрать resume= из /proc/cmdline

И что после этого перестанет работать?

Гибернация (точнее, восстановление из неё). Ваш кэп.

Я это всё читал. У меня дракут берет параметры из /etc/kernel/cmdline. То есть в /proc/cmdline запись аналогичная. И там нет ничего про resume.

Вообще не могу найти упоминаний про этот uuid. Откуда он берется - непонятно.

cat /proc/cmdline

fdisk -x

mount

???

говорят еще о переменной HibernateLocation EFI, где она находится?

Вообще не могу найти упоминаний про этот uuid. Откуда он берется - непонятно

ls /sys/firmware/efi/efivars?

ага нашел /sys/firmware/efi/efivars/HibernateLocation-8cf2644b-4b0b-428f-9387-6d876050dc67

Я первым делом проверил имена разделов при помощи blkid, потом посмотрел в fstab на соответветствие. Опции ядра и прочие места, пробежался.

Как бы сразу понятно, что система тупит 2 минуты, потому что раздела нет.

Нашёл HibernateLocation в efivars. Удолить низя.

The resume device node is either passed directly through arguments, or automatically acquired from kernel command line options and/or HibernateLocation EFI variable. The latter will normally be cleared by systemd-hibernate-resume.service on resumption. If a stale variable is detected, it would be cleared by systemd-hibernate-clear.service.

при этом сервиса такого нет в systemd 255.5

systemctl |grep clear пусто

Я, кажется, начинаю подозревать причину. Когда-то форматировал свап и у него сменился uuid. А в hibernatelocation остался прописан старый.

Редактировать/удалять это файл нельзя. Как засунуть в него новый uuid?

проверь как монтируется с rw или нет

mount |grep efi

если что перемонтируй

https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface#Mount_efivarfs

Rw

Попробую с лайв загрузится

https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface#Userspace_tools_are_unable_to_modify_UEFI_variable_data

при этом сервиса такого нет в systemd 255.5

Будет в v256:

$ git rev-list --reverse -1 upstream/main -- units/systemd-hibernate-clear.service.in | xargs git describe --contains
v256-rc1~324^2~1

Редактировать/удалять это файл нельзя

chattr -i попробуй.

Ядро выставляет на всех EFI-переменных immutable по дефолту, чтобы rm -rf / не брикнуло тебе материнку.

Благодарю. Так что, пока переменную вручную удалять?

Вручную, после chattr -i. См. выше.

чтобы rm -rf / не брикнуло тебе материнку

всё файловая система сосоны -> произошла чудовищная ошибка товарищи!

Вопрос, почему такое произошло. Я такие операции неоднократно проводил в прошлом и никогда не было проблем.

Давайте всё свалим на жопооруких системдаунов.

П.С. chattr -i сработало, всем спасибо за участие

Давайте всё свалим на жопооруких системдаунов

Ну это удар ниже пояса, т. к. сабж был писан мной 🙃

Хотя UEFI-переменные туда завезли уже после меня. Наверное, да, проблема именно в том, что она не очищается после использования, хотя семантически это именно одноразовая переменная.

почему такое произошло

Попробовал гибернуться после v254 (с восстановлением или нет — не важно), потом переформатировал своп.

Попробовал гибернуться

Никогда не использовал гибернацию. Ядро самосборное, с кернел.орг. Ноут у меня как переносная замена десктопу.

Видимо умею я в жир ногами.