Назад | Перейти на главную страницу

После смены раздела на системном диске система не загружается, переходит в «Dracut Emergency Shell»; как мне заставить его загрузиться?

Задний план

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

Системный диск также имел проблемы с загрузкой в ​​правильную kernel что я не мог исправить (я следил за всеми grub направления, но он просто не загружается правильно kernel по умолчанию, только если вы вручную выбрали правильный). Итак, я решил, что лучше всего просто выполнить новую установку Fedora Server на новый диск, и это решит проблему с загрузкой в ​​процессе.

Что произошло

Новый диск был намного больше, поэтому в процессе установки я разбил его немного иначе. Затем я удалил диск и вставил как новый, так и старый системные диски в другой сервер, который у меня был поблизости. Из излишней осторожности я оставил fstab с нового системного диска, зная, что на нем есть раздел UUIDs.

Есть много способов переместить вещи, и я решил, что мне нужен чистый корневой раздел на новом системном диске. Я полагал dd мог бы сделать это, но я привык использовать его там, где разделы имеют одинаковый размер и был немного не уверен, поэтому вместо этого я просто переформатировал корневой раздел ("/") с gparted. Затем я переместил файлы, используя обычные инструменты ОС. Затем я вырезал и приклеил UUID хлам из новой установки и вставил в очень неродную fstab с сервера, который я исправлял.

Все прошло нормально.

Затем я попытался загрузить систему. Он опубликовал, а затем попал в grub загрузчик, он автоматически выбрал правильное ядро, и все готово! ... Пока этого не произошло!

Он должен был «показать экран загрузки Plymouth» или что-то в этом роде, приостановился, а затем выдал множество предупреждений о тайм-аутах от чего-то, вызывающего себя dracut. Отсюда я сделал снимок экрана со своим телефоном. Он говорит:

Warning: Could not boot.
Starting Dracut Emergency Shell...
Warning: /dev/disk/by-uuid/<a uuid> does not exist
Generating "/run/initramfs/rdsosreport.txt"

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

ACK! Что делать? Я искал все ниже и выше для этого Warning [...] does not exist и dracut emergency shell процитированный выше материал. Нада!

Сообщение:

Warning: /dev/disk/by-uuid/<uuid> does not exist

это главный ключ к разгадке.

Оказывается, что корневой раздел UUID хранится в двух местах в grub2 часть современного сервера Fedora Server /boot раздел. Но в этом сценарии на самом деле есть три UUID проблемы.

Переформатирование корневого раздела ("/") фактически изменило UUID. Итак, новый UUID необходимо сначала обнаружить, а затем поместить в нужные места. Есть много способов найти UUIDs но один инструмент командной строки для этого - blkid - как в этом примере:

# blkid
/dev/sda1: UUID="64bbac09-1a12-4bea-8873-212ffb56f2a8" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="primary" PARTUUID="8a09913a-fdb2-42a0-98e3-6b89e16374d2"

Обратите внимание, что для каждого раздела есть два UUIDs показывается этим инструментом; вы хотите первое из них. Также обратите внимание, что непривилегированные пользователи не могут запускать blkid.

Вот три места корневого раздела UUID должно быть:

  1. В /etc/fstab в строке, где описано монтирование корневого раздела, и;
  2. В /boot/grub2.cfg в строке настройки параметров ядра. Самый быстрый способ найти это - поискать первое. UUID если он у вас еще есть. Или ищи "set kernelopts="root=UUID=", и;
  3. В /boot/grub2/grubenv в строке, которая похожа на строку, указанную в /boot/grub2.cfg файл. Искать: kernelopts=root=UUID=

Не забудьте изменить только один новый UUID, а все остальное оставить как было. Может быть, сделайте резервную копию файла перед редактированием, на всякий случай!