Не загрузится (спад busybox) после обновления ядра (с зашифрованными дисками)
У меня есть две системы - 14.04.03 LTS и 16.04 LTS, оба из которых не загружаются после недавних обновлений ядра. Любая справка ценилась бы - я не эксперт, но это кажется мне как новое ядро, просто не видит зашифрованные файловые системы во время начальной загрузки.
Для обеих систем я использовал установщик для шифрования загрузочного диска. Позже, я добавил второй диск, зашифрованное использование LUKS, автосмонтированный во время начальной загрузки с помощью файла ключей. Я (примерно - был сделан после системы, был установлен и загрузился), следовал инструкциям здесь:
Вот еще некоторые детали систем:
Для 16.04 систем LTS:
Аппаратные средства являются mSATA SSD на /dev/sdb, который Ubuntu была установлена при использовании автоматической установки раздела (/ и подкачка). Sata на 500 ГБ продолжает путь /dev/sda используется для /data - после того, как система была в порядке, раздел удач был создан и установлен на автоматическое монтирование на начальной загрузке с файлом ключей.
$ uname -a
Linux <hostname> 4.4.0-21-generic #37-Ubuntu SMP Mon Apr 18 18:33:37 UTC 2016 x86_64 X86_64 GNU/Linux
$ cat /etc/fstab
# <file system> <mount point> <type> <options> <dump> <pass>
/dev/mapper/ubuntu--vg-root / ext4 errors=remount-ro 0 1
# /boot was on /dev/sdb2 during installation
UUID=5039XXXX-XXXX-XXXX-XXXX-d2b4XXXXXXXX /boot ext2 defaults 0 2
# /boot/efi was on /dev/sdb1 during installation
UUID=1DXX-XX4D /boot/efi vfat umask=0077 0 1
/dev/mapper/ubuntu--vg-swap_1 none swap sw 0 0
# encrypted disk /data (unlocked with keyfile
/dev/mapper/data_crypt /data ext4 errors=remount-ro 0 1
$ cat /etc/crypttab
sdb3_crypt UUID=0bg9rz-XXXX-XXXX-XXXX-XXXX-XXXX-XXqvBH none luks
data_crypt UUID=453cXXXX-XXXX-XXXX-XXXX-6926XXXXXXXX /root/<keyfile> luks
Когда 4.4.0-21 выбран из личинки, подсказка пароля для разблокирования sdb3_crypt немедленно подходит. Система затем зависает при подсказке запуска человечности. Нажатие удаляет, показывает следующее сообщение об ошибке. После нескольких минут система на самом деле загружается, и data_crypt смонтирован на /data как ожидалось
[ 2.091698] [drm:intel_set_pch_fifo_underrun_reporting [i915]] ERROR uncleared pch fifo underrun on pch transcoder a
[ 2.091735] [drm:intel_pch_fifo_underrun_irq_handler [i915]] ERROR PCH transcoder A FIFO underrun
lvmetad is not active yet, using direct activation during sysinit
Volume group "ubuntu-vg" not found
cannot process volume group ubuntu-vg
/run/lvm/lvmetad.socket: connect failed: no such file or directory:
Reading all physical volumes. This may take a while...
Found volume group "ubuntu-vg" using metadata type lvm2
/run/lvm/lvmetad.socket: connect failed: no such file or directory:
WARNING: failed to connect to lvmetad. Falling back to internal scanning.
2 logical volume(s) in volume group "ubuntu-vg" now active
/dev/mapper/ubuntu--vg-root: clean 488960/6750209 files, 11825728/26996736 blocks
[ ***] A start job is running for dev-disk-by\x2duuid-0bg9rZ\X2deNSE\x2d1E8u\x2XXXXX\x2XXXXX\x2XXXX\x2dZpqvBH.device (xxS / 1min 30s)
Из меню Grub, выбирая или 4.4.0-22 или 4.4.0-24 и затем нажатие удаляют, показывает следующую (записанную) информацию:
[ 2.091698] [drm:intel_set_pch_fifo_underrun_reporting [i915]] ERROR uncleared pch fifo underrun on pch transcoder a
[ 2.091735] [drm:intel_pch_fifo_underrun_irq_handler [i915]] ERROR PCH transcoder A FIFO underrun
lvmetad is not active yet, using direct activation during sysinit
Volume group "ubuntu-vg" not found
cannot process volume group ubuntu-vg
/run/lvm/lvmetad.socket: connect failed: no such file or directory:
WARNING: failed to connect to lvmetad. Falling back to internal scanning.
Reading all physical volumes. This may take a while.
Последние 3 строки повторяются, возможно, 30 раз, и после спадов нескольких минут до оболочки busybox. Вручную выполнение cryptsetup luksOpen /dev/sdb3 sdb3_crypt (и ввод пароля), в порядке, но затем я не могу смонтировать это (вероятно, потому что это находится в initramfs, и я не знаю то, что я делаю там).
Удаление строк, касающихся data_crypt от /etc/fstab и /etc/crypttab не имеет никакого значения, таким образом, я не думаю, что это связано с автомонтированием этого дискового порождения проблемы.
Я также попытался воссоздать initramfs для этих ядер, который не имел никакого значения.
Я также испытываю подобную проблему в 14.04.03 системах LTS, как описано ниже, но не могу предоставить точную подробную информацию (это - система, я отправляю это от).
Для 14.04.03 систем LTS:
Аппаратными средствами является SSD NVMe для / и подкачка и диск SATA на 1 ТБ для /data. Снова, Ubuntu была установлена на SSD, и затем позже диск SATA был подключен, настроен как зашифрованный раздел с помощью удач, затем добавил, чтобы автосмонтироваться при начальной загрузке с файлом ключей.
пакеты для гостеприимного ядра были установлены:
linux-generic-lts-xeniallinux-headers-generic-lts-xeniallinux-image-generic-lts-xenial
Команда произвела:
Linux hostname 4.2.0-36-generic #42~14.04.1-Ubuntu SMP Fri May 13 17:27:22 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
$ cat /etc/fstab
# <file system> <mount point> <type> <options> <dump> <pass>
/dev/mapper/ubuntu--vg-root / ext4 errors=remount-ro 0 1
# /boot was on /dev/nvme0n1p2 during installation
UUID=0657XXXX-XXXX-XXXX-XXXX-1be3XXXXXXXX /boot ext2 defaults 0 2
# /boot/efi was on /dev/nvme0n1p1 during installation
UUID=AEXX-XX66 /boot/efi vfat defaults 0 1
/dev/mapper/ubuntu--vg-swap_1 none swap sw 0 0
# encrypted disk /data (unlocked with keyfile
/dev/mapper/data_crypt /data ext4 errors=remount-ro 0 1
$ cat /etc/crypttab
nvme0n1p3_crypt UUID=61235695-XXXX-XXXX-XXXX-962cXXXXXXXX none luks,discard
data_crypt UUID=2e92XXXX-XX57-XXXX-XXXX-af9fXXXXXXXX /root/<keyfile> luks
Любому из 4,4 серийных ядер не удается загрузиться. 4,2 последовательных прекрасные начальных загрузки ядра все же.
2 ответа
Хорошо, понятый это.
UUID sdb3_crypt (где / и подкачка расположены) так или иначе не был правильным в/etc/crypttab. Я проверил это путем сравнения UUID, перечисленных в/etc/crypttab с перечисленными в/dev/disk/by-uuid/. Никакая идея, как это поняло превратно, но у меня должен быть жир, перебирал его где-нибудь по пути.
Я исправил/etc/crypttab с корректным UUID/dev/sdb3, затем обновил initramfs ($update-initramfs-c-k 4.4.0-24-универсальный). Перезагрузка и теперь это работает хорошо.
У меня была подобная проблема кроме моего /etc/crypttab было абсолютно недостающим. Недавно я обновил свой механический жесткий диск до SSD. На обоих у меня есть все, но /boot зашифрованный, и процесс начальной загрузки работал просто великолепно. Кроме того, я проверил резервное копирование с нескольких предшествующих недель, и crypttab был там затем.
Я следовал ответу на это сообщение для решения моей проблемы.
Переустановите к существующим зашифрованным разделам
Отметьте ре комментария три из монтирования. Они являются неправильными и должны быть:
# mount --bind /dev /mnt/ubuntu/dev
# mount --bind /sys /mnt/ubuntu/sys
# mount -t proc none /mnt/ubuntu/proc
Кроме того, обратите внимание, что UUID в crypttab должен быть для контейнера, который содержит объем LUKS (в моем случае /dev/sda5), не для объема LUKS после, дешифрован. (Это говорит это, но я пропустил его в первый раз вокруг, таким образом, я думал, что укажу на это.)
Заключительное примечание, должен сказать, что это плохое поведение со стороны updater - рендеринг незагрузочного компьютера - является видом проблемы, которая мешает Linux получать более широкую аудиторию среди типичных настольных пользователей.