Попадание в аварийное приглашение systemd после длительного процесса восстановления загрузки. Проблема: Отсутствует FS в файле fstab

Попадание в аварийное приглашение systemd после длительного процесса восстановления загрузки. Проблема: Отсутствует FS в файле fstab

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

Я восстанавливал процесс загрузки виртуальной машины, в которой были 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находятся все файлы).

Я думал, что просто пересоздам initramfsusing update-initramfs -c -k allиз текущих ядер, которые я установил, но потом узнал, что не могу пересоздать файлы или с помощью в configодиночку . Это оказалось немного сложнее, чем я рассчитывал.System.mapdepmod

Я обнаружил, что самый простой способ повторно сгенерировать или получить все эти файлы:

  1. удалить все содержимое /boot,
  2. удалить все файлы linux-image, которые я не собирался использовать,linux-headerlinux-modules
  3. удалить все оставшиеся каталоги в /usr/lib/modules, а затем
  4. переустановить и файлы linux-image, которые я намеревался использовать (самые последние общие две версии)linux-moduleslinux-headers

Примечание: Переустановка этих 3 типов файловВсе одновременновот как мне удалось вернуть /boot/System.mapи /boot/configфайлы - раньше только переустановка linux-imageфайлов не помогала. Возможно, они включены в modules(модули имели бы смысл) или headersпакеты, но это то, что сработало для меня.

  1. Затем я запустил update-grubповторную установку этих файлов и убедился, что /bootони были заполнены правильно.
  2. Я также запустил 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/rundisplay :0.0

systemctl set-default multi-user.target

Ладно, вот и все. Надеюсь, это кому-то поможет.

Связанный контент