Проблема с загрузкой Kubuntu: как выйти из режима аварийного обслуживания?

Проблема с загрузкой компьютера после установки M.2 диска

Вчера я столкнулся с серьезной проблемой в работе своего настольного компьютера: после установки нового диска M.2 устройство перестало загружаться и застряло в «Режиме аварийного обслуживания». Это стало вызовом, так как я стремился восстановить систему и вернуть ее к нормальной работе.

Предварительная настройка и перенос системы

После установки диска M.2 я использовал загрузочный диск Puppy Linux для переноса системы с раздела /dev/sde2 на новый /dev/sdb2 (диск M.2), а также перенес раздел /boot с /dev/sde1 на /dev/sdb1. Все идентификаторы были обновлены в файле /etc/fstab. Однако, несмотря на эти меры, система продолжала загружаться с неправильного диска.

Проблемы с настройками BIOS и системой

Я попробовал настроить BIOS, чтобы убедиться, что он правильно распознает новый диск. Вот несколько наблюдений, которые мне удалось сделать:

• Компьютер продолжал пытаться загрузиться с /dev/sde2, даже несмотря на то что BIOS был настроен на загрузку с /dev/sdb2.
• Сетевая карта была отключена по умолчанию, что требовало ручной активации команды ifconfig и запуска dhcpclient.
• Система запускалась в однопользовательском режиме, но доступ к экрану GNU оставался.
• При запуске некоторых операций, таких как SSHD через systemctl или перезагрузки, система замерзала на длительные промежутки времени.

Эта ситуация позволяла мне предположить, что проблема связана с программным обеспечением, поскольку Puppy Linux загружался без каких-либо проблем.

Попытка исправления с помощью chroot и обновления Grub

Я попробовал войти в новую систему через chroot и выполнить переустановку и обновление Grub. Замена файла /boot/grub/grub.cfg на новый вывод команды grub-mkconfig не принесла желаемого результата, и система все еще переходила в режим аварийного обслуживания.

Каждый раз при запуске меня настигало сообщение о необходимости проверить вывод journalctl -xb. Несмотря на многократные проверки, я не находил очевидных проблем.

Решение: Простые шаги исправления

В конечном итоге мне удалось решить проблему, обнаружив три основных проблемы:

1. Когда я перенес данные из старого раздела /boot, я забыл правильно смонтировать его. Это означало, что Grub не мог найти необходимые файлы. Я переименовал старую папку /boot, установил новый раздел и снова скопировал все обратно. После этого grub-mkconfig начал работать ожидаемо, но я все еще оставался в «режиме аварийного обслуживания».

2. Быстрая проверка с помощью fsck показала, что раздел /boot был поврежден. Я не углублялся в причины, просто отформатировал его и снова скопировал данные.

3. Я продолжал запускаться в режиме аварийного обслуживания. Посмотрев еще раз на логи, я удалил все записи, мешавшие нормальной загрузке системы. В итоге я нашел две проблемы с файлом /etc/fstab: две одинаковые записи UUID для одного устройства и необходимость обновления UUID после форматирования раздела /boot.

Заключение: Возвращение к нормальной работе

После внесения всех необходимых правок система была готова к загрузке. Благодаря моему терпению и последовательному подходу мне удалось восстановить работоспособность компьютера. В данном процессе я не только решил проблему загрузки, но и улучшил общее понимание работы системы. Теперь я готов к любым будущим изменениям и манипуляциям с оборудованием.

Источник