
Я понимаю, что уже было несколько вопросов от людей, у которых возникли проблемы с загрузкой, но я думаю, что мой случай довольно особый, поэтому я публикую еще один вопрос в надежде на решение некоторых новых проблем.
Я восстанавливал процесс загрузки виртуальной машины, в которой были initramfs
( initrd.img
и vmlinuz
файлы /boot
) из ядер, которые больше не были установлены, и пытался по-прежнему загружаться с них.
Я очень близок к завершению, но он продолжает перезагружаться в systemd
's emergency mode
(где написано: )
You are in emergency mode. After logging in, type "journalctl -xb" to view system logs, "systemctl reboot" to reboot, "systemctl default" or "exit" to boot into default mode.
Give root password for maintenance
(or press Control-D to continue):
Я загрузился с Live CD, смонтировал 3 соответствующих раздела в /mnt
, выполнил chroot в /mnt
:
mount /dev/sda3 /mnt
mount /dev/sda2 /mnt/boot
mount /dev/sda1 /mnt/boot/efi
for i in proc dev dev/pts sys tmp run; do mount --bind /$i /mnt/$i; done
chroot /mnt
Сделал ремонт и перезагрузил.
Теперь мой fstab
не монтирует мои разделы. Я думал, что он настроен правильно - UUID копируются напрямую из blkid | grep /dev/sda
. Я не думал, что он что-то упускает.
Вот ошибки, которые я вижу непосредственно перед переходом в аварийный режим:
[FAILED] Failed to mount /boot
See 'systemctl status boot.mount' for details.
[DEPEND] Dependency failed for Local File Systems
[DEPEND] Dependency failed for Unattended Upgrades Shutdown
[DEPEND] Dependency failed for /boot/efi
Итак, конечно, я посмотрел на systemctl status boot.mount
, но он активен (зеленый) и говорит, что загружен, хотя моя /boot
папка пуста, если я не смонтирую его вручную /dev/sda2
.
Выглядит очень странно. Зачем boot.mount
говорить, что это загрузка /boot
раздела, если это явно не так?
решение1
Так что я на самом деле разобрался с проблемой, пока писал вопрос. Как вы можете видеть из того, что я написал в начале, это был очень долгий процесс (я работал над этим около 2 дней, прежде чем дошел до того, что захотел попросить о помощи).
Если посмотреть на самый конец вопроса, то dmesg
во время загрузки я получил следующее сообщение:
[FAILED] Failed to mount /boot
See 'systemctl status boot.mount' for details.
Конечно, я попытался systemctl status boot.mount
посмотреть, что там написано, но там было написано, boot.mount
что он активен (зеленый), загружен и функционирует нормально, хотя /boot
был пуст, пока я не смонтировал его вручную /dev/sda2
(что совершенно противоположно тому, что я ожидал).
Поэтому я начал думать, что что-то не так с сервисом. Я отключил его, boot.mount
хотя онсказалон работал правильно:
systemctl disable --now boot.mount
Я попытался включить его снова, но получил ошибку:
systemctl enable --now boot.mount
Failed to enable unit: Unit /run/systemd/generator/boot.mount is transient or generated
Хорошо, это имеет смысл, это запускается через процесс загрузки и не может быть вызвано через команду пользователя. Поэтому я попытался перемонтировать все устройства с помощью:
mount -a
И увидел, что в файле была ошибка /etc/fstab
:
error: rw,relatime is not a valid file system
(Или что-то в этом роде).
Ключевой момент здесь в том, что если бы я не попытался смонтировать файловую систему вручную, я бы никогда не получил эту обратную связь. Сообщение об ошибке от mount -a
одного, которое получает, когда fstab
содержит неправильный синтаксис, невероятно полезно. Намного полезнее, чем:
[FAILED] Failed to mount /boot
See 'systemctl status boot.mount' for details.
... а затем увидеть «рабочий» модуль systemd, boot.mount
когда /boot
он не монтируется (даже если онделал(в конце концов, приведут меня в нужное место).
Поэтому я отредактировал fstab
и ввел информацию о файловой системе для /boot
раздела, который не удалось смонтировать, затем перезапустил mount -a
(что по сути делает то же самое, что и boot.mount
) и получил положительный ответ.
Теперь после перезагрузки оба раздела монтируются правильно, и все хорошо в стране хрена и мармелада.
Если это не помогло решить ни одну из ваших проблем, вот несколько дополнительных заметок о процессе, который я прошел, прежде чем дошел до пункта выше, где мне нужна была помощь (можете спокойно прекратить чтение, как только доберетесь до своей проблемы):
Первоначальная проблема, с которой я столкнулся два дня назад, заключалась в том, что система пыталась загрузиться с ядер, которых больше нет в системе. Поэтому после загрузки с Live CD я удалил /boot
содержимое папки (где initrd
находятся все файлы).
Я думал, что просто пересоздам initramfs
using update-initramfs -c -k all
из текущих ядер, которые я установил, но потом узнал, что не могу пересоздать файлы или с помощью в config
одиночку . Это оказалось немного сложнее, чем я рассчитывал.System.map
depmod
Я обнаружил, что самый простой способ повторно сгенерировать или получить все эти файлы:
- удалить все содержимое
/boot
, - удалить все файлы
linux-image
, которые я не собирался использовать,linux-header
linux-modules
- удалить все оставшиеся каталоги в
/usr/lib/modules
, а затем - переустановить и файлы
linux-image
, которые я намеревался использовать (самые последние общие две версии)linux-modules
linux-headers
Примечание: Переустановка этих 3 типов файловВсе одновременновот как мне удалось вернуть /boot/System.map
и /boot/config
файлы - раньше только переустановка linux-image
файлов не помогала. Возможно, они включены в modules
(модули имели бы смысл) или headers
пакеты, но это то, что сработало для меня.
- Затем я запустил
update-grub
повторную установку этих файлов и убедился, что/boot
они были заполнены правильно. - Я также запустил
bootctl install
и/etc/kernel/postinst.d/zz-udpate-systemd-boot
, поэтому я быsystemd-boot
установил его в качестве запасного варианта.
В какой-то момент после перезагрузки мне пришлось перенастроить system.target
его multi-user.target
вместо graphical.target
, вероятно, из-за того, что пару дней назад chroot
я ed со всеми этими монтированиями в графическом Live CD для запуска программы, которая требует графики (и я считаю , что и были необходимы для работы):boot-repair
/dev/pts
/tmp
/run
display :0.0
systemctl set-default multi-user.target
Ладно, вот и все. Надеюсь, это кому-то поможет.