Автор Тема: Проблема с зашифрованным разделом подкачки  (Прочитано 684 раз)

Оффлайн geher

  • Начинающий
  • *
  • Сообщений: 13
Имеется система, установленная с Alt Workstation 10 на зашифрованные разделы (swap на своем шифрованном разделе) и обновленная до актуального состояния с p10.
После очередного обновления как-то отвалился swap.
Сначала при загрузке система долго думает (полторы минуты), выдавая сообщение о каком-то задании на предмет диска с uuid того самого раздела swap. После загрузки оказывается, что подкачки нет, а в панели висит иконка с предложением смонтировать шифрованный раздел. Попытка включить swap командой swapon с указанием uuid раздела оканчивается неудачей. Если сначала смонтировать раздел при помощи означенной иконки, то команда swapon с тем же uuid срабатывает уже нормально.

Вопрос - как с этим бороться? Что могло отвалиться?

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

Оффлайн kessys

  • Давно тут
  • **
  • Сообщений: 249
lsblk -f
Сравнить UUID по пути в файле /etc/fstab
Если есть отличия то заменить согласно информации из lsblk -f

Оффлайн geher

  • Начинающий
  • *
  • Сообщений: 13
Сравнить UUID по пути в файле /etc/fstab
Проверял. Идентичны. Более того, руками подключается в два этапа.  Выглядит так, будто где-то поломалось подключение зашифрованного раздела со свопом, и оно в результате не может подключиться

Оффлайн geher

  • Начинающий
  • *
  • Сообщений: 13
Пытался найти десять отличий между системой, где шифрованный своп не работает, и такой же системой, где работает. Ничего похожего на правду не нашел.
В crypttab в обоих случаях поминается только раздел с системой. uuid свопа в обоих же случаях фигурирует только в fstab, причем это uuid именно свопа внутри шифрованного раздела, а у шифрованного раздела свой uuid.
Или информация о том, какие шифрованные разделы следует монтировать при загрузке, находится не в /etc, а где-то еще?
Может ли влиять порядок разделов на диске (первым идет своп или системный раздел)?

Оффлайн geher

  • Начинающий
  • *
  • Сообщений: 13
Повтор события отваливания зашифрованного свопа на одной из виртуалок. Теперь уже Simply. Непонятно. Ощущение такое, будто система "забывает", что необходимо при загрузке подключить второй зашифрованный раздел, чтобы с него мог подняться своп.
Собственно страшной проблемы в этом нет. Есть разные решения разной степени костыльности (включая своп в файле на системном шифрованном разделе и даже полный отказ от свопа). Но хотелось бы понять, а почему оно так происходит? Я что-то делаю не так или в системе изначально что-то не то? Потому и не тороплюсь сообщать о проблеме в более официальных каналах.

Оффлайн Антон Мидюков

  • alt linux team
  • ***
  • Сообщений: 4 715
  • antohami@
Скорее всего "потерялся" пароль от LUKS раздела или же на момент монтирования пароль был не доступен. Почитайте, попробуйте:
https://www.altlinux.org/Управление_шифрованными_разделами_LUKS

Оффлайн geher

  • Начинающий
  • *
  • Сообщений: 13
Пароль, однако, никуда не потерялся. В "ручном" режиме своп подключается без проблем.

Кстати, одним из решений проблемы оказалось простое добавление соответствующего шифрованного раздела в /etc/crypttab. Тогда своп с этого раздела автоматически подключается, как и раньше,
Но тогда остается вопрос. А как оно раньше работало, без записи об этом разделе в /etc/crypttab? Какой механизм был задействован для этого сразу после установки? И почему этот механизм отвалился?
На ряде виртуальных и не только машин оно ведь до сих пор работает. И везде один и тот же p10, обновленный до упора, разве что установленный с разных дистрибутивов.

Оффлайн trs

  • Давно тут
  • **
  • Сообщений: 246
Пытался найти десять отличий между системой, где шифрованный своп не работает, и такой же системой, где работает. Ничего похожего на правду не нашел.
Железо не идентичное? Я к тому, что система в целом работает асинхронно, а человек полагает запуск её компонент строго последовательным. То есть нет такого, что запустился сначала один драйвер, потом второй и так далее. Всё это происходит по событиям. Условно говоря, нужный файл переместился в другое место на накопителе, потому считывается на 0,0001 секунд позже, чем раньше - а какая-то служба почему-то решает, что этого файла нет. Если правильно помню, как раз из-за состояния «гонки» при добавлении в systemd сервиса systemd-networkd у кого-то отваливалась сеть после обновления, тогда как у большинства всё прошло гладко. На виртуалках, кстати, такое поймать существенно сложнее, поскольку её диск на деле является файлом на хосте и обращения к нему кешируются.
« Последнее редактирование: 29.08.2022 08:04:35 от trs »