Обновление . Эта проблема была решена обновлением ядра в декабре 2017 года. Я не мог понять, в чем была проблема, но, оглядываясь назад, исходя из другой проблемы, которая у меня была в то время, она могла возникнуть из-за проблем совместимости при записи пользовательского интерфейса диска. с дефисами или без них: Linux требует дефисов, а GRUB - нет.
Я запускаю Parabola Linux с ядром linux-libre 4.11.9-gnu-1
и Libreboot на моем компьютере.
Проблема : Я недавно обновил свою систему (
pacman -Syu
), и с тех пор мой процесс загрузки не удался. В частности, кажется, что ядро не может найти логический том, на котором находится моя настоящая система.Я получаю сообщение об ошибкеОШИБКА: устройство «/ dev / aether / core /» не найдено. Пропуск fsck.
Мы будем благодарны за любую помощь в устранении или диагностике этой проблемы. Мое понимание слишком мало, чтобы исправить это сам, и я в отчаянии.
Далее я опишу проблему более подробно, а после этого я опишу, что я сделал до сих пор.
Это моя установка : у меня есть твердый диск с одним полностью зашифрованным разделом, поверх которого у меня есть логический том с именем core
в группе томов с именем эфир
. Моя система / корневой каталог находится в ядре логического тома
. (Диск зашифрован с помощью cryptsetup
, логические тома управляются с помощью lvm
.)
И вот что происходит, когда я загружаюсь (как я это понимаю).
Фаза загрузчика .
Libreboot успешно загружает GRUB.
GRUB запрашивает у меня парольную фразу для расшифровки зашифрованного раздела.
а. Я ввожу кодовую фразу.
б. GRUB успешно расшифровывает зашифрованный раздел.
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. * -
(какая-то версия, где я знаю, что могу загрузиться), но безрезультатно: проблема остается.
Этот вопрос касается аналогичной проблемы. Мой отличается тем, что, во-первых, правильное имя устройства указано в моем сообщении об ошибке и так или иначе не найдено; и я могу ввести экстренную оболочку.
В чем проблема? Как я могу это исправить?
Как сказано в обновлении:
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
в исходном вопросе.)
Предполагаю, что вы полагаетесь на какое-то имя udev, которого нет в initramfs. т.е. зашифрованный раздел расшифровывается, но не связывается с /dev/aether/core.
Я бы рекомендовал попробовать указать корневой раздел по UUID или имени или использовать имя устройства, которое вы использовали для chroot.
Все это при условии, что вы не используете LVM поверх шифрования.