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

10

Я следил за этим руководством для установки Ubuntu 15.10:

Ссылка

После перезагрузки моего компьютера я попал в меню grub и выбрал Ubuntu. Вскоре после этого я получил эту ошибку:

/run/lvm/lvmetad.socket: connect failed: No such file or directory
WARNING: Failed to connect to lvmetad. Falling back to internal scanning.

Эти сообщения постоянно сбрасываются на черный экран каждую секунду. Через некоторое время я получаю доступ к консоли initramfs ash.

что я делаю неправильно?

    
задан Mac Dre 12.03.2016 в 19:46
источник

2 ответа

5

Сегодня я видел ту же самую ошибку на ноутбуке под управлением 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 .

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

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

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

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

  • отредактируйте /etc/lvm/lvm.conf и измените use_lvmetad=1 на use_lvmetad=0
  • выполнить update-initramfs -k *KERNEL_VERSION* -u ; sync

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

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

Сначала запустите sfdisk --list /dev/sdX и убедитесь, что ваш зашифрованный раздел подкачки (в моем случае, / dev / sdX2) фактически not отображается как (обычный) раздел подкачки. Если бы это было так (как в моем случае), это означало, что загрузка, например, с помощью аварийного диска, скорее всего, будет использовать этот доступный раздел подкачки, тем самым перезаписывая ваши метаданные, связанные с cryptsetup (keyphrase и 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 ) мне было представлено « Чтение всех физических томов. Это может занять некоторое время ... » (повторяется несколько раз), а затем « ALERT! / Dev / disk / by-uuid / ... не существует. ". (Следует отметить, что update-initramfs также жаловался на недостающий раздел.)

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

    
ответ дан Markus Ueberall 31.03.2016 в 13:19
-1

У меня возникла эта проблема после установки Gnome на Ubuntu 17 и выбора GDM в качестве менеджера отображения по умолчанию. Следующие шаги, которые я собрал вместе из других ответов, работали для меня:

  • При загрузке, прежде чем вы увидите логотип Ubuntu, нажмите клавишу Shift, чтобы получить меню загрузки GRUB.
  • Выберите режим восстановления из меню загрузки
  • Выберите бросить в корневую оболочку из появившегося меню
  • Перезагрузите корневую файловую систему, чтобы вы могли вносить изменения в систему, набрав:

    mount -o rw, remount /

  • Выполните следующее:

    dpkg-reconfigure lightdm

  • Выберите lightdm в качестве диспетчера дисплея, а не gdm

  • Reboot
ответ дан jimkeller 29.04.2017 в 15:12