Ошибка загрузки: ядро ​​не находит системное устройство

Обновление . Эта проблема была решена обновлением ядра в декабре 2017 года. Я не мог понять, в чем была проблема, но, оглядываясь назад, исходя из другой проблемы, которая у меня была в то время, она могла возникнуть из-за проблем совместимости при записи пользовательского интерфейса диска. с дефисами или без них: Linux требует дефисов, а GRUB - нет.


Я запускаю Parabola Linux с ядром linux-libre 4.11.9-gnu-1 и Libreboot на моем компьютере.

Проблема : Я недавно обновил свою систему ( pacman -Syu ), и с тех пор мой процесс загрузки не удался. В частности, кажется, что ядро ​​не может найти логический том, на котором находится моя настоящая система.Я получаю сообщение об ошибке ОШИБКА: устройство «/ dev / aether / core /» не найдено. Пропуск fsck.

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

Далее я опишу проблему более подробно, а после этого я опишу, что я сделал до сих пор.


Это моя установка : у меня есть твердый диск с одним полностью зашифрованным разделом, поверх которого у меня есть логический том с именем core в группе томов с именем эфир . Моя система / корневой каталог находится в ядре логического тома . (Диск зашифрован с помощью cryptsetup , логические тома управляются с помощью lvm .)

И вот что происходит, когда я загружаюсь (как я это понимаю).

Фаза загрузчика .

  1. Libreboot успешно загружает GRUB.

  2. GRUB запрашивает у меня парольную фразу для расшифровки зашифрованного раздела.

    а. Я ввожу кодовую фразу.

    б. GRUB успешно расшифровывает зашифрованный раздел.

  3. GRUB успешно загружает образ ядра и файлы initramfs.

Фаза ядра . Происходит следующее:

 …
 :: running early hook [udev]
 …
 :: running early hook [lvm2]
 …
 :: running hook [encrypt]
 Waiting 10 seconds for device /dev/aether/core ...
 [    4.250559] sd 4:0:0:0:  [sdb] No Caching mode page found.
 [    4.250612] sd 4:0:0:0:  [sdb] Assuming drive cache: write through
 ERROR: device '/dev/aether/core/' not found. Skipping fsck.
 :: mounting '/dev/aether/core' on real root
 mount: you must specify the filesystem type
 You are now being dropped into an emergency shell.
 sh: can't access tty; job control turned off
 [rootfs ]#

Я пропустил некоторые сообщения, обозначенные как . Полный журнал находится здесь , но я не думаю, что остальное поможет.

GRUB настроен на прошивке Libreboot. Вот соответствующая часть моего grub.cfg :

  cryptomount -a
  set root=lvm/aether-core
  linux /boot/vmlinuz-linux-libre root=/dev/aether/core cryptdevice=/dev/disk/by-uuid/〈uuid of the encrypted partition〉:core cryptkey=rootfs:/etc/〈keyfile〉
  initrd /boot/initramfs-linux-libre.img

Однако я не думаю, что проблема кроется в самом GRUB.


То, что я сделал . Я успешно вошел в свою систему.Изнутри существует / dev / aether / core . И кодовая фраза, и ключевой файл успешно разблокируют зашифрованный раздел. Я также попытался понизить версию ядра до 4.10. * - (какая-то версия, где я знаю, что могу загрузиться), но безрезультатно: проблема остается.

Этот вопрос касается аналогичной проблемы. Мой отличается тем, что, во-первых, правильное имя устройства указано в моем сообщении об ошибке и так или иначе не найдено; и я могу ввести экстренную оболочку.


В чем проблема? Как я могу это исправить?

0
15.12.2018, 21:26
2 ответа

Как сказано в обновлении:

This issue has been resolved by a kernel update in December 2017. I could not figure out what the problem had been – but in hindsight, coming from another problem I had in the meantime, it might have stemmed from compatibility issues in writing a disk UIID with or without hyphens: Linux wants hyphens, but GRUB doesn’t.

Но более вероятно, что это просто ошибка ядра.

Тем временем у меня была аналогичная проблема. (А может, и точно такой же, не помню. )Решение заключалось в использовании разных UUID в конфигурации GRUB — одного для GRUB и одного для Linux. В частности, в строке

linux /boot/vmlinuz-linux-libre root=/dev/aether/core cryptdevice=/dev/disk/by-uuid/〈uuid of the encrypted partition〉:core cryptkey=rootfs:/etc/〈keyfile〉

⟨uuid of the encrypted partition⟩следует читать как с дефисами , тогда как ⟨uuid of the encrypted partition⟩в

cryptomount -u ⟨uuid of the encrypted partition⟩

следует читать как без дефисов . (Эта строка заменит строку cryptomount -aв исходном вопросе.)

0
28.01.2020, 04:43

Предполагаю, что вы полагаетесь на какое-то имя udev, которого нет в initramfs. т.е. зашифрованный раздел расшифровывается, но не связывается с /dev/aether/core.

Я бы рекомендовал попробовать указать корневой раздел по UUID или имени или использовать имя устройства, которое вы использовали для chroot.

Все это при условии, что вы не используете LVM поверх шифрования.

0
28.01.2020, 04:43

Теги

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