Почему в Debian/Ubuntu/Mint по умолчанию выключена поддержка Hibernate?

Не понял, у меня все с самого начала было включено (Buster), и с самого начала работало через ж… ну вы поняли.

Видимо так работает, что лучше пусть будет отключено.

Судя по описанию решения по второй ссылке корень проблемы в недостаточном размере swap файла. У меня инсталлятор решил, что 2 GB будет достаточно, хотя памяти в 16 раз больше и диск на пол тера.

Windows же ведёт себя более благоразумно.

Каков размер swap файла/раздела в твоей системе, по сравнению с объёмом памяти?

В современных компьютерах (твое древнее гогно к этому отношения не имеет) довольно хорошо починили ACPI и прочие sleep так, что гибернация оказалась ненужной. Да и на холодную ОС стали грузиться на порядок быстрее благодаря SSD.

Как долго хватит на половину заряженного аккумулятора лептопу в режиме sleep? Дня три - четыре протянет? А неделю или две, пока я в отпуске? С чего ты взял, что у меня что-то древнее?

Да, примерно то же самое писали в devel рассылке федоры, когда обсуждали переход на zram с дискового свопа.

Вот конкретно описание ситуации и вороха проблем: https://pagure.io/fedora-workstation/blob/master/f/hibernationstatus.md

Не знал, кстати, что оно не работает с Secure Boot. Впрочем я никогда гибернацией и не пользовался, и даже в винде вырубаю вместе со ее своп файлом

Вот кстати еще интересная инфа

ACPI is a mess of a specification, it's massive and complicated. No single vendor implements all of it, and possibly not single vendor implements portions completely correctly and bug free. ACPI power level S4 is fragile, it doesn't even always work on Windows (or macOS for that matter) . ACPI power level S3 is apparently becoming more fragile, noted by increasing user reports where S3 appears to just be a stub (hardware will enter suspend to RAM, but has variable degrees of recover from not at all to the display or keyboard don't work). Hardware vendors, Microsoft, Apple, and Linux kernel developers have been putting most of their effort into S0 lower power idle because they don't have to depend on ACPI or (logic board) firmware, and on faster boot times, where hibernation is a fallback position.

Там какой-то новый подвид S3 появился на ноутах, который плохо с линуксом дружит

Suspend, который sleep, у меня как раз работает.

Видимо потому что с hibernate не совместимо шифрование диска?

Как долго хватит на половину заряженного аккумулятора лептопу в режиме sleep? Дня три - четыре протянет? А неделю или две, пока я в отпуске? С чего ты взял, что у меня что-то древнее?

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

Полпроцента?

Осталось понять, какое отношение sleep вообще имеет к обсуждаемому вопросу. У меня рабочий лептоп, который я забираю домой или (реже) запираю в тумбочку. Вернуться в офис, или просто к внешнему источнику электричества, лептом может через сутки, через несколько суток или даже через несколько недель. Как мне это делать не обращая внимание на то, сколько процентов заряда аккумулятора осталось и с сохранением текущего состояния?

На мой последний вопрос в предыдущем сообщении ты не ответил.

Видимо потому что с hibernate не совместимо шифрование диска?

Шифрования диска нет.

Система при установке, насколько помню, предлагала где то 1:1. Но это самому можно задать (у меня в 2 раза больше). Все остальное, о чем писалось по ссылкам, было по дефолту включено.

И что, совсем без ошибок? Без правок и ковыряния в системе!? Эхх…

Потому что не таргентовая аудитория.

На серверах, роутерах это не нужно.

Комп, тикай з городу! Тобi винда!

Не сказал бы что в венде просто работает. На тех ноутах и станционарниках в моей семье и у родных что есть, где-то что-то обязательно не работает. То в вине не работает гибернация, то в линуксе, то какие-то проблемы с обычным суспендом.

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

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

И что, совсем без ошибок? Без правок и ковыряния в системе!? Эхх…

Ну я не часто этим пользуюсь. Вот перед написанием того комментария попробовал уйти в sleep и вернуться и оно работало.

Система при установке, насколько помню, предлагала где то 1:1. Но это самому можно задать (у меня в 2 раза больше). Все остальное, о чем писалось по ссылкам, было по дефолту включено.

Наверное Debian всё ещё делает это по-старинке, как это принято при серверном использовании. Но в данном случае речь идёт о лептопе и в моём случае о Linux Mint.

Потому что не таргентовая аудитория.

Для Ubuntu и Mint как раз наоборот.

Комп, тикай з городу! Тобi винда!

תהיה בריא גם אתה

Для Ubuntu - нет. Mint — так васяны

Ubuntu стала популярной как раз за счёт десктопного использования.

Прошедшее время вижу я.

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

Печальнее всего, что в гноме нет нормальной поддержки этой функции, нужно делать всё руками.

Судя по описанию решения по второй ссылке корень проблемы в недостаточном размере swap файла. У меня инсталлятор решил, что 2 GB будет достаточно, хотя памяти в 16 раз больше и диск на пол тера.

Windows же ведёт себя более благоразумно.

Сомнительное благоразумие, 7% места выкинуть на то что может никогда не будет использоваться.

Сомнительное благоразумие, 7% места выкинуть на то что может никогда не будет использоваться.

Там это легко отключить и моментально вернуть эти 7%, что я обычно и делаю на нелептопах. Но в Ubuntu/Mint и прочих это какой-то квест.

Видимо потому что с hibernate не совместимо шифрование диска?

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

Это относится к убунте. Там какие-то проблемы с использованием шифрованного свопа, в детали я не погружался.

Это относится к убунте

Тогда понятно. У них своп-файл, а не своп-раздел, и шифрование ни при чем. Попробуй прописать resume_offset=??? к командной строке ядра. Вопросики брать из filefrag -e /.swapfile (строчка про ext 0, physical offset). Например в примере ниже (правда тут Arch) их надо заменить на 24:

# filefrag -e /.swapfile 
Filesystem type is: 58465342
File size of /.swapfile is 17179869184 (4194304 blocks of 4096 bytes)
 ext:     logical_offset:        physical_offset: length:   expected: flags:
   0:        0.. 2097007:         24..   2097031: 2097008:            
   1:  2097008.. 3145711:    2097032..   3145735: 1048704:            
   2:  3145712.. 4194303:    3145736..   4194327: 1048592:             last,eof
/.swapfile: 1 extent found

Не такое уж прошедшее.

Зачем мне это делать и каким образом оно будет просыпаться из зашифрованного свопа?

У них есть initramfs. Он грузится grub’ом вместе с ядром из незашифрованного /boot, и ядро запускает код (а точнее скрипты) из initramfs. Скрипты спрашивают пароль от зашифрованного LUKS-ом раздела, после чего его разблокируют и, если он там есть, активируют LVM. В итоге появляется блочное устройство, на котором корневая файловая система и в ней swap-файл. До сих пор все дисковые операции были только операциями чтения.

А теперь внимание. Файловую систему на этом этапе монтировать нельзя, поскольку она неконсистентная, а образ из swap’а брать надо. Поэтому разработчики ядра придумали трюк: на этапе просыпания ядро не использует файловую систему, а работает с блочным устройством напрямую. А для этого надо знать, в каком месте устройства находится первый блок swap-файла (а в нем находятся ссылки на продолжение). Собственно, за это и отвечает параметр resume_offset. Если бы swap был не в файле, а в отдельном LVM-томе, как в Ubuntu 16.04, то параметр был бы не нужен.

Стоп, вру. В десктопной ubuntu при выборе LVM по-прежнему swap является lvm-томом. Сейчас сделаю виртуалку и посмотрю, почему у тебя не просыпается.

Потому что RAM нынче столько, что дисковое пространство под нее всю выделять даже жалко.

Ну и глюкодром эта ваша убунта, начиная с инсталлятора. Умеет создавать правильную разбивку диска (диск -> efi + /boot + crypt -> lvm -> root + swap), если не выбирать кастомную разбивку. Вот только swap делает слишком маленький и не дает изменять размер. А вот если выбрать кастомную разбивку, то LVM к ней никак не присобачить.

Ладно, я не настолько жадный, делаю диск -> /boot + crypt -> root -> swap-файл, и дорабатываю руками.

Держи виртуалку (осторожно, почти 8 GB). Ubuntu 20.04, своп зашифрован вместе с корнем. Засыпает и просыпается. Все пароли: password

https://u.pcloud.link/publink/show?code=kZeoj4XZH8jqXQdGybzVJxvgORtl7pagoNak

А этот ваш ацпи умеет будить комп, когда батарейка разряжается до нужного процента?

Например потому, что после выхода из спящего режима, в Linux не все оборудование снова включается. И приходится перезагружаться. Так зачем тогда хибернате нужен?

Судя по описанию решения по второй ссылке корень проблемы в недостаточном размере swap файла. У меня инсталлятор решил, что 2 GB будет достаточно, хотя памяти в 16 раз больше и диск на пол тера.

Windows же ведёт себя более благоразумно.

Сомнительное благоразумие, 7% места выкинуть на то что может никогда не будет использоваться.

В виндус гибернация в отдельный от свопа файл.