Не могу загрузиться: «mdadm: CREATE групповой диск не найден»

После запуска apt-get upgrade вчера и выключения, я больше не могу загружать Ubuntu 15.

Последние несколько строк, которые я вижу во время загрузки:

Begin: Running /scripts/init-premount ... done.
Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done.

Мой жесткий диск зашифрован, поэтому обычно я получаю приглашение Passphrase здесь. Однако через некоторое время я просто получаю:

mdadm: CREATE group disk not found

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

Я нашел несколько тем об этой ошибке, но пока нет решения. Что я могу сделать, чтобы диагностировать и устранить эту проблему?

Спасибо!

0
задан 23 May 2016 в 02:23

3 ответа

Эта ошибка сгенерирована initramfs сценарием, который находит и монтирует корневую фс.

Я испытал это сообщение прежде, и это оказалось вызванным путем обновления initramfs от живого CD.

Вещь состояла в том, что у меня был зашифрованный корень, и при открытии объема удач от живого CD, я не использовал то же имя, которое было в моем crypttab.

Так, я загрузил живой CD и сделал:

cryptsetup luksOpen /dev/md1 md1
vgchange -ay
mount /dev/vgmain/lvroot /mnt/custom
<... mount dev et. al ...>
chroot /mnt/custom
<... fix something ...>
update-initramfs -u
exit
umount /mnt/custom && vgchange -an && cryptsetup luksClose md1

update-initramfs -u действительно предупреждал о cryptsetup: WARNING: invalid line in /etc/crypttab - но сначала я не считал это важным.

После того, как некоторые неудачные попытки загрузить его поразили меня: мой crypttab имел md1_crypt для объема удач, но когда я обновил initramfs, он видел md1 таким образом, это пошло с этим. Из сценариев начальной загрузки md1 не было доступно как объем удач.

Таким образом, я загрузил свой livecd снова и исправил его:

cryptsetup luksOpen /dev/md1 md1_crypt
vgchange -ay
mount /dev/vgmain/lvroot /mnt/custom
<... mount dev et. al ...>
chroot /mnt/custom
update-initramfs -u
exit
umount /mnt/custom
vgchange -an
cryptsetup luksClose md1_crypt

Я просмотрел сценарии initramfs-инструментов, но я не мог найти точное пятно, где это пошло не так, как надо, таким образом, я предполагаю, что это было просто некоторое странное взаимодействие между cryptsetup, mdadm и lvm.

На другом хосте debian у меня была подобная проблема*, кроме этого времени без crypttools или lvm, включенного, и я смог работать вокруг этого путем изменения моего mdadm.conf от /dev/md/n устройство соединяет каналом к /dev/mdn. На этом ocassion проблема только представила себя, в то время как массив восстанавливал и не, когда все было нормально.

Возможно, кто-то более знакомый с внутренними работами initramfs-инструментов может понять это.

* хост debian также показал сообщение как incrementally starting raid arrays после некоторых CREATE group disk not found.

0
ответ дан 23 May 2016 в 12:23
  • 1
    Спасибо, it' s немного сбивающий с толку и это также зависит от того, если Linux пытается сделать UEFI. Это звучит мне как OP, хочет использовать начальную загрузку Прежней версии и отключить UEFI все вместе. – Kristopher Ives 20 December 2016 в 22:25

Я полагаю, что это имеет отношение к условиям состязания, когда mdadm создает дисковые массивы. Вам, вероятно, придется играть с задержками сценариев перед монтированием, чтобы позволить всем массивам быть созданными. Я настроил вложенный RAID для начальной загрузки/, потому что личинка не может иметь дело с RAID10, и второй RAID1 зеркала уровня обычно не становится созданным mdadm. Таким образом, я должен был поместить mdadm - собирают/dev/md/boot в сценарий перед монтированием.

Ваша ситуация, возможно, отличающаяся, но я думаю, что мой опыт дает ключ к разгадке.

0
ответ дан 23 May 2016 в 12:23
  • 1
    I' m не уверенный в этом. Отключение UEFI немного похоже chmod 777 мне: это работает, но это не может быть лучшее решение в течение длительного срока. Я думаю, что OP должен сначала попробовать, имеют чистую начальную загрузку UEFI с отключенной Защищенной загрузкой. Если это не работает, то попытайтесь отключить UEFI. – Adrien Beau 20 December 2016 в 22:27

ВНП ответ был довольно хорош и определенно указал на меня в правильном направлении (моя проблема была вызвана поврежденным cryptroot установка). Однако не было довольно достаточно отладить проблему)

  1. , Это может произойти из-за cryptsetup не отображающийся зашифрованный том. Это означает, что initramfs не имеет и lvm объем для монтирования, если Вы используете, и зашифрованная lvm физическая группа (значение по умолчанию зашифровало установку человечности)
  2. Для того, чтобы обычно отладить этот вид проблемы, Вы хотите понять initramfs и обновление-initramfs (Google, затем я вставил бы ссылки stackexchange, не позволит мне)
  3. Для получения большей отладочной информации, можно отредактировать параметры загрузки в личинке (путем нажатия e по допустимой опции), необходимо удалить всплеск и тихие опции. Если это не достаточно, можно использовать break=premount, как описано здесь: https://wiki.debian.org/InitramfsDebug, чтобы заскочить в интерактивную оболочку и видеть, что продолжается. Сценарий, который вызывал проблемы здесь, назвали cryptroot.
  4. Для понимания, что продолжается в поколении initramfs сценариев можно посмотреть на файлы в /usr/share/initramfs-tools/hooks и /usr/share/initramfs-tools/scripts, первый выполняется в полной рабочей системе для генерации конфигурации для последнего. Вы могли бы попытаться добавить set -x флаги к этим сценариям для отладки.

В моем особом случае, у меня были проблемы при исправлении этого от загрузочного диска с chroot потому что lvm инструменты, не возвращая корректные результаты в тюрьме. Я должен был смонтироваться во многих вещах работать вокруг этого. Я также должен был удостовериться, что объем удач был отображен с корректным именем (Это должно было совпасть со значением в [1 111], и полезный графический интерфейс выбирал настоящую дурную славу.

cryptsetup luksOpen /dev/md1 md1_crypt
mount --bind /sys /mnt/encrypted-root/sys
mount --bind /dev /mnt/encrypted-root/dev
mount --bind /proc /mnt/encrypted-root/proc
chroot /mnt/encrypted-root
update-inintramfs -c -k all
0
ответ дан 23 May 2016 в 12:23
  • 1
    Я согласовываю it' s просто я don' t думают состояние UEFI, безопасные подписи начальной загрузки для Linux очень хороши, это было главным образом сделано Microsoft, и предварительно загруженные подписи производителями обычно просто Microsoft. – Kristopher Ives 20 December 2016 в 22:34

Другие вопросы по тегам:

Похожие вопросы: