При наличии swap-файла не прописывает "resume_offset=" в параметры ядру. https://wiki.archlinux.org/title/Power_management/Suspend_and_hibernate#Acquire_swap_file_offset
https://lists.altlinux.org/pipermail/make-initrd/2024-June/001073.html , но непонятно, зачем туда писать...
(Ответ для Sergey V Turchin на комментарий #1) > https://lists.altlinux.org/pipermail/make-initrd/2024-June/001073.html Я там ни разу не понял, чем идея плохая. Писать на read-only раздел -- да плохая идея, но я не вижу, как это туда относится.
Плохая, потому что необходимо указывать смещение в разделе. * Такую конфигурацию можно легко случайно сломать. * Так как задействована файловая система такая схема с resume_offset= не на всех файловых системах будет работать. Я не уверен будет ли это работать с luks, lvm, некоторыми raid и некоторыми конфигурациями btrfs. * Кроме того, есть ещё вот такое ограничение: Unfortunately, however, it requires the filesystem holding the swap file to be mounted, and if this filesystem is journaled, it cannot be mounted during resume from disk. Поэтому я считаю эту идёю плохой, но вы можете поступать как лучше вам. Параметр resume= и resume_offset= поддерживаются в make-initrd очень давно.
(Ответ для Alexey Gladkov на комментарий #3) > * Такую конфигурацию можно легко случайно сломать. Не страшно. Ну и добавить в нужные места обновление resume_offset= > * Так как задействована файловая система такая схема с resume_offset= не на > всех файловых системах будет работать. Не страшно. Во многих случаях же будет. > * Кроме того, есть ещё вот такое ограничение: > it cannot be mounted during resume from disk. Не могу представить такую ситуацию. По крайней мере, для рабочей станции. > Поэтому я считаю эту идёю плохой, но вы можете поступать как лучше вам. Не слишком удачной -- да, но никак не плохой. > Параметр resume= и resume_offset= поддерживаются в make-initrd очень давно. Это хорошо. P.S. В Ubuntu swap-файл.
(In reply to Sergey V Turchin from comment #4) > > * Так как задействована файловая система такая схема с resume_offset= не на > > всех файловых системах будет работать. > Не страшно. Во многих случаях же будет. Ты скипнул буквально все случаи, где скорее всего будет :) Во многих случаях - это когда раздел со свап-файлом на обычной файловой системе. > > Поэтому я считаю эту идёю плохой, но вы можете поступать как лучше вам. > Не слишком удачной -- да, но никак не плохой. Это моё мнение.
(Ответ для Sergey V Turchin на комментарий #4) > P.S. > В Ubuntu swap-файл.
(Ответ для Sergey V Turchin на комментарий #6) > (Ответ для Sergey V Turchin на комментарий #4) > > P.S. > > В Ubuntu swap-файл. - у них работает спящий режим? - они используют resume_offset=...?
(Ответ для Alexey Gladkov на комментарий #5) > (In reply to Sergey V Turchin from comment #4) > > > * Так как задействована файловая система такая схема с resume_offset= не на > > > всех файловых системах будет работать. > > Не страшно. Во многих случаях же будет. > Ты скипнул буквально все случаи, где скорее всего будет :) Если я тут что-то скипнул, то это не обязательно отразится в установщике. :-) > Во многих случаях - это когда раздел со свап-файлом на обычной файловой системе. У меня по умолчанию swap-файл на нешифрованном BTRFS. Это для меня самые многие случаи. Если с Ext4+LVM заработает -- считай, что полностью удовлетворён.
(Ответ для Антон Мидюков на комментарий #7) > > > В Ubuntu swap-файл. > - у них работает спящий режим? > - они используют resume_offset=...? Не проверял, но это было бы странно, если бы не работал и не использовали. Придётся проверить.
> В Ubuntu swap-файл. Не встречал такой конфигурации. > у них работает спящий режим? Раньше в Ubuntu hibernation был отключен "из коробки", его надо было специально включать. Предлагаю подойти к вопросу как дистибутивостроителям. :-) Конфигурация имеет разные технические ограничения и потенциально может привести к потере данных, плюс в ряде случаев при загрузке это не будет срабатывать, как ожидается. Зачем такое тащить в установщик? Хочет пользователь чего-то странного и опасного -- возможность уже есть, статьи на ВиКи достаточно. Кроме того, в современном мире SSD/NVME грех экономить байты на диске. Если эта область почти не используется для перезаписи, то это очень хорошо отражается на износе и производительности при полном заполнении диска. Так что, я считаю, установщик должен уметь делать SWAP-раздел, а задача пользователя -- определить, нужен ли он ему для hibernatation или нет. Где-то и установщик может сам догадаться. Например, на серверах для hibernation не требуется, но там и авторазметка большая ошибка.
Вот какую фичу в установщике разумно реализовать: если нет раздела SWAP, автоматически отключать systemd hibrnation-target.
(In reply to Sergey V Turchin from comment #4) > > Параметр resume= и resume_offset= поддерживаются в make-initrd очень давно. > Это хорошо. Такая связка предписывает выделить конкретное место на диске от сих до сих. Если возникнет соблазн в какой-то момент освободить место, можно потерять данные, т.к. в рамках файловой системы намного сложнее проконтроллировать, чтобы файл занимал именно это место на диске. А раз он всё равно занимает место, в чём профит, в сравнеии с отдельным разделом? Если нужно в любой момент освободить место без опасений, можно с тем же успехом использовать LVM-том и это на порядок надёжнее.
(Ответ для Leonid Krivoshein на комментарий #12) > > > Параметр resume= и resume_offset= поддерживаются в make-initrd очень давно. > > Это хорошо. > Такая связка предписывает выделить конкретное место на диске от сих до сих. Нет. Только "от сих". Предписывает указать, где начало swap и всё. > Если возникнет соблазн в какой-то момент освободить место, можно потерять > данные, Как можно потерять данные без записи на несмонтированную файловую систему, которая не определилась как swap? > т.к. в рамках файловой системы намного сложнее проконтроллировать, Легко. mount всегда посылает, если не определил указанную файловую систему. Ни разу не виде и даже не слышал, чтоб он ошибочно монтировал. > чтобы файл занимал именно это место на диске. Именно в этом месте на диске конкретно написано, что это swap. Или не написано. > А раз он всё равно занимает место, в чём профит, в сравнеии с отдельным разделом? Не надо шифровать отдельно.
(Ответ для Leonid Krivoshein на комментарий #10) > > В Ubuntu swap-файл. > Не встречал такой конфигурации. Т.е. не устанавливали Ubuntu. В 23.10 /swap.img по умолчанию.
(Ответ для Leonid Krivoshein на комментарий #10) > Раньше в Ubuntu hibernation был отключен "из коробки", его надо было > специально включать. Проверил сейчас 23.10. Да, выключен. И swap-файл по умолчанию.
(In reply to Sergey V Turchin from comment #13) > (Ответ для Leonid Krivoshein на комментарий #12) > > Такая связка предписывает выделить конкретное место на диске от сих до сих. > Нет. Только "от сих". Предписывает указать, где начало swap и всё. Конец определяется по inode, где начинается файл. Так что, фактически и до сих. В любом случае это фиксированное пространство на диске. > > Если возникнет соблазн в какой-то момент освободить место, можно потерять > > данные, > Как можно потерять данные без записи на несмонтированную файловую систему, > которая не определилась как swap? Они будут точно потеряны, если в том месте, где ранее располагался файл для SWAP'а, окажутся какие-то другие данные. Достаточно руками удалить этот файл или дефрагментировать диск, забыв проделать операцию по указанию нового зарезервированного фрагмента. Это мина замедленного действия. > > т.к. в рамках файловой системы намного сложнее проконтроллировать, > Легко. mount всегда посылает, если не определил указанную файловую систему. Не всегда. И речь была не о mount. Речь о том, что нужно следить, чтобы указанный в resume_offcet= параметр соответсвовал началу файла, чтобы этот файл там был, чтобы никто его никуда не удалил, не переместил. > Ни разу не виде и даже не слышал, чтоб он ошибочно монтировал. Две истории. Остаточная информация (недозатёртые сигнатуры) в пропагаторе приводили к его зависанию, т.к. он пытался смонтировать не тот раздел. И ещё пример со сквошом. Обрежь truncate'ом до 1Мб и попробуй его смонтировать. Никакой ругани не будет, но потом узнаешь.) На самом деле mount не обязан контроллировать целостность даже одного суперблока, ему достаточно убедиться, что сигнатуры на месте. И в случае, когда ядро решит отработать hibernation, проверяется сигнатура SWAP'а, всего несколько байт, которые чудом могли сохраниться. Но пространство уже относится к другим (хуже всего -- пользовательским) данным. > > чтобы файл занимал именно это место на диске. > Именно в этом месте на диске конкретно написано, что это swap. Или не > написано. В лучшем случае там не будет этого написано. Но худший тоже не стоит снимать со счетов. > > А раз он всё равно занимает место, в чём профит, в сравнеии с отдельным разделом? > Не надо шифровать отдельно. Отдельно шифровать SWAP не только не проблема, но и хорошая практика, т.к. для SWAP'а часто используется криптобезопасный рандомный ключ, хотя в этом случае о hibernation точно придётся забыть. Ну, тут либо удобство, либо безопасность. Если это единственный профит, то его нет, потому что какая разница, два раздела мы шифруем или один. Что пароли сейчас для каждого отдельно запрашиваются -- проблема установщика, которую надо чинить отдельно, даже make-initrd (инсталлятор отчасти тоже) поддерживает /etc/crypttab. (In reply to Sergey V Turchin from comment #14) > Т.е. не устанавливали Ubuntu. В 23.10 /swap.img по умолчанию. Ставил разные. Сейчас в доступе Ubuntu 22.04.4 LTS. Проверю ещё на свежем LTS. (In reply to Sergey V Turchin from comment #15) > Проверил сейчас 23.10. Да, выключен. > И swap-файл по умолчанию. Такая конфигурация не должна вызывать проблем. Главное, не предлагать потенциальные грабли, на которые кто-нибудь непременно наступит.
(Ответ для Leonid Krivoshein на комментарий #16) > (In reply to Sergey V Turchin from comment #13) > > > А раз он всё равно занимает место, в чём профит, в сравнеии с отдельным разделом? > > Не надо шифровать отдельно. > Отдельно шифровать SWAP не только не проблема, но и хорошая практика, т.к. > для SWAP'а часто используется криптобезопасный рандомный ключ, хотя в этом > случае о hibernation точно придётся забыть. Ну, тут либо удобство, либо > безопасность. Если это единственный профит, то его нет, потому что какая > разница, два раздела мы шифруем или один. Что пароли сейчас для каждого > отдельно запрашиваются -- проблема установщика, которую надо чинить > отдельно, даже make-initrd (инсталлятор отчасти тоже) поддерживает > /etc/crypttab. Инсталлятор не прописывает swap в /etc/crypttab. Поэтому у нас поддержка зашифрованного swap из коробки никогда и не работала.
А пароли при использовании plymouth отдельно для каждого раздела не запрашиваются. Только один раз.
(Ответ для Leonid Krivoshein на комментарий #16) > > > Если возникнет соблазн в какой-то момент освободить место, можно потерять > > > данные, > > Как можно потерять данные без записи на несмонтированную файловую систему, > > которая не определилась как swap? > Они будут точно потеряны, если в том месте, где ранее располагался файл для > SWAP'а, окажутся какие-то другие данные. Кто их потеряет и зачем он это сделает?
(Ответ для Антон Мидюков на комментарий #17) > Инсталлятор не прописывает swap в /etc/crypttab. Поэтому у нас поддержка > зашифрованного swap из коробки никогда и не работала. Теперь поддерживает из коробки. Когда используется plymouth, пароль вводить требуется лишь один раз.
(In reply to Sergey V Turchin from comment #19) > (Ответ для Leonid Krivoshein на комментарий #16) > > Они будут точно потеряны, если в том месте, где ранее располагался файл для > > SWAP'а, окажутся какие-то другие данные. > Кто их потеряет и зачем он это сделает? Главное ни кто и зачем, а когда это произойдёт. Тогда уже встанет вопрос, кто и зачем эти грабли тут поставил. :-)
(In reply to Антон Мидюков from comment #18) > А пароли при использовании plymouth отдельно для каждого раздела не > запрашиваются. Только один раз. Возможно я это давно проверял и как раз на системе, где plymouth был не совсем рабочим. Пароль запрашивался на каждый раздел, и даже ни один раз. Возможно с тех пор уже починили.
(Ответ для Leonid Krivoshein на комментарий #21) > (In reply to Sergey V Turchin from comment #19) > > (Ответ для Leonid Krivoshein на комментарий #16) > > > Они будут точно потеряны, если в том месте, где ранее располагался файл для > > > SWAP'а, окажутся какие-то другие данные. > > Кто их потеряет и зачем он это сделает? > Главное ни кто и зачем, а когда это произойдёт. Когда это произойдёт, кто их потеряет и зачем он это сделает?
*** Bug 51113 has been marked as a duplicate of this bug. ***
