Ubuntu не загружается из-за lvmetad

Question 1

Сегодня я увидел ту же ошибку на ноутбуке под управлением Ubuntu 15.10, которую я всегда обновлял, но не перезагружал в течение месяца, пока не захотел протестировать текущее ядро (т. е. могло произойти недавнее изменение).

В любом случае, я обнаружил, что в моем случае основной причиной был фактически «отсутствующий» раздел подкачки из-за сбоя настройки при выполнении приведенного выше руководства. Если это так и/или вы действительно используете lvm, вы можете пропустить шаг 2 ниже. Конечно, вы также можете увидеть указанное выше сообщение об ошибке в случае, если ваш системный раздел (или вторичный раздел данных) был поврежден или не может быть найден (см. шаг 3).

Шаг 1: Смонтируйте систему, загрузите разделы, следуя вышеупомянутому руководству.

Допустим, ваш загрузочный раздел (ext2) — это /dev/sdX1, ваш (зашифрованный) раздел подкачки — это /dev/sdX2, ваш (зашифрованный) раздел данных — это /dev/sdX3, и вы успешно расшифровали последний с помощью cryptsetup luksOpen /dev/sdX3 data, а затем смонтировали его: mkdir /tmp/data; mount /dev/mapper/data /tmp/data.

Обратите внимание на привязки монтирования в руководстве и обязательно смонтируйте /dev/sdX1, чтобы иметь к нему доступ из каталога /boot вашего системного раздела (это важно, так как нам нужно выполнить update-initramfs).

Далее мы предполагаем, что вы успешно выполнили chroot /tmp/data/@ubuntu1510(или как там называется ваш смонтированный системный раздел)

Шаг 2: Избавьтесь от указанного выше сообщения об ошибке

Я использую btrfs (как вы могли догадаться по названию упомянутого подтома), поэтому lvmetad можно легко отключить следующим образом без потери функциональности:

отредактируйте /etc/lvm/lvm.conf и измените use_lvmetad=1наuse_lvmetad=0
выполнятьupdate-initramfs -k $(uname -r) -u ; sync

Теперь ваша очередьмогперезагрузите компьютер, и сообщение об ошибке должно исчезнуть.Однако,В моем случае следующее сообщение об ошибке[1] указало мне на основную проблему, упомянутую выше, поэтому, раз уж мы об этом заговорили, ...

Шаг 3: Убедитесь, что /etc/crypttab указывает на правильные, неповрежденные разделы.

Сначала запустите sfdisk --list /dev/sdXи проверьте, что ваш зашифрованный раздел подкачки (в моем случае /dev/sdX2) действительно работаетнетотображаются как (обычный) раздел подкачки. Если это так (как в моем случае), это означает, что загрузка, например, с использованием аварийного диска, скорее всего, будет использовать этот доступный раздел подкачки, тем самым перезаписывая ваши метаданные, связанные с cryptsetup (ключевую фразу и UUID).

Далее, взгляните на /dev/disk/by-uuid и сравните соответствующие UUID ваших зашифрованных разделов с теми, которые содержатся в /etc/crypttab. Мое предположение на данный момент: в вашем случае есть несоответствие.

Если выделенный зашифрованный раздел подкачки нигде не находится ниже /dev/disk/by-uuid, это потому, что он в настоящее время используется вашей системой восстановления. В этом случае выполните следующие действия:

обязательно прекратите использование раздела:swapoff -a
переформатировать его: mkfs.ext2 /dev/sdX2(этоключевой, особенно при использовании разделов GPT[2], так как это устраняет глюк, о котором я упоминал ранее. Вероятная причина того, что раздел отображается как тип "swap" в списке sfdisk, заключается в том, что вы/я ошибочно использовали его mkswap /dev/sdX2при настройке раздела в начале.)
следуйте инструкциям, чтобы зашифровать раздел и задать парольную фразу; затем откройте его с помощью cryptsetup и правильно переформатируйтетеперь расшифрованораздел (используя что-то вроде mkswap /dev/mapper/swap)
убедитесь, что sfdisk --list /dev/sdXраздел подкачки не будет идентифицирован как таковой (в этом случае повторите последние шаги)

Теперь еще раз проверьте, что UUID, перечисленные в /etc/crypttab, соответствуют тому, что вы видите ниже /dev/disk/by-uuid для ваших соответствующих зашифрованных разделов.

Опять же, чтобы сделать изменения постоянными, необходимо выполнить действия update-initramfs, показанные выше.

Если вы удовлетворены, убедитесь, что все записано на диск и перезагрузите систему (нет необходимости размонтировать все вручную). После этого ваша проблема должна исчезнуть.

[1] Возможно, я не обратил внимания в первый раз или первое сообщение об ошибке «замаскировало» второе; т. е. только после перезагрузки (с помощью use_lvmetad=0) мне было представлено «Чтение всех физических томов. Это может занять некоторое время..." (повторяется несколько раз), за которым следует "ВНИМАНИЕ! /dev/disk/by-uuid/... не существует.". (Следует отметить, что update-initramfsтакже жаловались на отсутствие раздела.)

[2] поскольку их тип выводится из анализа их содержимого и в конечном итоге не указывается флагом/байтом (именно поэтому нет простого способа, например, изменить тип файловой системы GPT с помощью [g]parted.)

Answer