Устранение неполадок в процессе загрузки RHEL

Введение

В этой лабораторной работе вы изучите основные методы устранения неполадок и восстановления процесса загрузки Red Hat Enterprise Linux (RHEL). Вы узнаете, как взаимодействовать с системой на разных этапах последовательности загрузки для диагностики и решения распространенных проблем, которые могут помешать правильному запуску системы. Это включает в себя работу с целями загрузки systemd и использование специальных режимов загрузки, предназначенных для восстановления системы.

В ходе упражнений вы получите практический опыт управления целями systemd с помощью systemctl, загрузки в режим восстановления из меню GRUB для обслуживания системы и сброса пароля root с использованием параметра ядра rd.break. Кроме того, вы узнаете, как использовать аварийный режим (emergency mode) для исправления критических ошибок в файлах конфигурации, таких как поврежденный /etc/fstab, что позволит вам восстановить незагружаемую систему в рабочее состояние.

Управление целями загрузки Systemd с помощью systemctl

На этом шаге вы узнаете, как управлять целями загрузки systemd. В systemd «цель» (target) — это точка синхронизации, которая объединяет различные службы и другие юниты, необходимые для приведения системы в определенное состояние. Это современный эквивалент «уровней запуска» (runlevels) в старых системах SysV init. Мы рассмотрим, как просмотреть текущую цель по умолчанию, изменить цель по умолчанию для будущих загрузок и временно переключиться на другую цель.

Сначала давайте проверим, в какую цель ваша система загружается по умолчанию. graphical.target используется для систем с графической средой, предоставляя графический пользовательский интерфейс (GUI). multi-user.target предназначен только для интерфейса командной строки.

Чтобы увидеть текущую цель по умолчанию, выполните следующую команду:

systemctl get-default

Вы должны увидеть, что цель по умолчанию — графическая.

graphical.target

Теперь давайте изменим цель загрузки по умолчанию на multi-user.target. Это полезно для серверных сред или для устранения неполадок в ситуациях, когда графический интерфейс не нужен или вызывает проблемы. Команда systemctl set-default достигает этого, изменяя символьную ссылку /etc/systemd/system/default.target.

Используйте sudo, чтобы выполнить эту команду с правами администратора.

sudo systemctl set-default multi-user.target

Вывод подтверждает, что символьная ссылка была обновлена.

Removed /etc/systemd/system/default.target.
Created symlink /etc/systemd/system/default.target -> /usr/lib/systemd/system/multi-user.target.

Вы можете убедиться, что значение по умолчанию было изменено, повторно выполнив команду get-default.

systemctl get-default

Вывод теперь показывает новую цель по умолчанию.

multi-user.target

С этой настройкой система загрузится в текстовую консоль после перезагрузки. Для этой лабораторной работы мы хотим сохранить согласованную графическую среду. Давайте вернем цель по умолчанию к graphical.target.

sudo systemctl set-default graphical.target

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

Removed /etc/systemd/system/default.target.
Created symlink /etc/systemd/system/default.target -> /usr/lib/systemd/system/graphical.target.

Выполните окончательную проверку, чтобы убедиться, что цель по умолчанию восстановлена до graphical.target.

systemctl get-default

graphical.target

В дополнение к изменению цели по умолчанию для перезагрузок, вы также можете переключать цели в текущем сеансе, используя systemctl isolate. Эта команда останавливает службы, не связанные с новой целью, и запускает те, которые связаны. Например, выполнение sudo systemctl isolate multi-user.target завершит вашу графическую сессию и переключит вас на консоль только с текстом. Это мощная, но потенциально разрушительная команда, поэтому мы не будем ее выполнять здесь.

Теперь вы успешно использовали systemctl для управления целями systemd.

Загрузка в режим восстановления из меню GRUB

На этом шаге вы узнаете о rescue.target, специальной цели systemd, предназначенной для восстановления системы. В стандартной системе RHEL вы получаете доступ к этому режиму, перезагружая систему, прерывая загрузчик (GRUB) и добавляя параметр в параметры загрузки ядра. Это предоставляет однопользовательскую оболочку с примонтированной корневой файловой системой и отключенным большинством служб, что идеально подходит для устранения неполадок.

Хотя мы не можем выполнить реальную перезагрузку или получить доступ к меню GRUB в этой контейнерной лабораторной среде, мы все равно можем изучить конфигурацию режима восстановления, чтобы понять, как он работает.

Сначала давайте найдем файл юнита systemd для rescue.target. Эти файлы обычно хранятся в каталоге /usr/lib/systemd/system/.

ls -l /usr/lib/systemd/system/rescue.target

Вы увидите файл, перечисленный с его разрешениями и владельцем.

-rw-r--r--. 1 root root 500 Nov  1  2022 /usr/lib/systemd/system/rescue.target

Теперь давайте рассмотрим содержимое этого файла, чтобы понять его конфигурацию. Команда cat отобразит содержимое файла в терминале.

cat /usr/lib/systemd/system/rescue.target

Вывод показывает определение цели.

##  SPDX-License-Identifier: LGPL-2.1-or-later
#
##  This file is part of systemd.
#
##  systemd is free software; you can redistribute it and/or modify it
##  under the terms of the GNU Lesser General Public License as published by
##  the Free Software Foundation; either version 2.1 of the License, or
##  (at your option) any later version.

[Unit]
Description=Rescue Mode
Documentation=man:systemd.special(7)
Requires=sysinit.target rescue.service
After=sysinit.target rescue.service
AllowIsolate=yes

Ключевые директивы в этом файле включают:

• Description=Rescue Mode: удобочитаемое имя для цели.
• Requires=sysinit.target rescue.service: это гарантирует, что и sysinit.target (базовая инициализация системы), и rescue.service запускаются при активации этой цели. Служба восстановления предоставляет оболочку для обслуживания root.
• After=sysinit.target rescue.service: это указывает порядок активации, гарантируя, что режим восстановления запускается после инициализации системы и службы восстановления.
• AllowIsolate=yes: это позволяет вам переключаться на эту цель из другой цели, используя команду systemctl isolate rescue.target в работающей системе.

Чтобы лучше понять минимальную среду, которую предоставляет режим восстановления, вы можете просмотреть его зависимости. Команда systemctl list-dependencies показывает все юниты, которые запускаются как часть цели.

systemctl list-dependencies rescue.target

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

rescue.target
○ ├─rescue.service
○ ├─systemd-update-utmp-runlevel.service
● └─sysinit.target
●   ├─dev-hugepages.mount
●   ├─dev-mqueue.mount
●   ├─dracut-shutdown.service
○   ├─iscsi-onboot.service
○   ├─iscsi-starter.service
●   ├─kmod-static-nodes.service
●   ├─ldconfig.service
●   ├─lvm2-lvmpolld.socket
... (output may vary) ...

Главный вывод заключается в том, что rescue.target предоставляет оболочку root с файловой системой, примонтированной для чтения-записи, что позволяет вам исправлять проблемы с системой. На следующих шагах мы смоделируем сценарии восстановления, которые основаны на аналогичных принципах.

Сброс пароля root с использованием rd.break и chroot

На этом шаге вы узнаете процедуру сброса потерянного пароля root в системе RHEL. Это критический навык восстановления. Стандартный метод включает прерывание процесса загрузки с помощью параметра ядра rd.break, который предоставляет вам доступ к оболочке до полной загрузки системы.

На физической или виртуальной машине вы бы перезагрузили систему, прервали загрузчик GRUB и добавили rd.break в конец строки ядра linux. Это действие останавливает процесс загрузки непосредственно перед тем, как systemd берет на себя управление, помещая вас в оболочку initramfs. Оттуда общие шаги следующие:

1. Перемонтируйте корневую файловую систему системы (которая смонтирована только для чтения в /sysroot) в режиме чтения-записи с помощью команды mount -o remount,rw /sysroot.
2. Войдите в chroot jail в /sysroot с помощью chroot /sysroot. Это делает фактическую корневую файловую систему системы вашей текущей средой, позволяя вам выполнять команды, которые влияют на систему.
3. Измените пароль с помощью команды passwd.
4. Устраните потенциальные проблемы с контекстом SELinux.
5. Выйдите из chroot и оболочки initramfs, чтобы продолжить загрузку.

Хотя мы не можем выполнить реальную перезагрузку и использовать rd.break в этой лабораторной среде, мы смоделируем наиболее важные команды, которые вы бы выполнили после входа в среду chroot.

Сначала давайте смоделируем изменение пароля root. Представьте, что вы успешно вошли в chroot jail. Теперь у вас будет root-доступ для изменения пароля любого пользователя. Мы будем использовать команду sudo passwd root, чтобы изменить пароль пользователя root. При появлении запроса установите новый пароль на redhat.

sudo passwd root

Вам будет предложено ввести и повторно ввести новый пароль (например, labex.io).

Changing password for user root.
New password:
Retype new password:
passwd: all authentication tokens updated successfully.

После изменения пароля в этой среде восстановления контекст безопасности SELinux в файле паролей (/etc/shadow) может стать неверным. Чтобы исправить это, вы должны принудительно выполнить полную перемаркировку SELinux системы при следующей загрузке. Это делается путем создания пустого файла с именем .autorelabel в корневом каталоге (/).

sudo touch /.autorelabel

Давайте проверим, что файл был создан.

ls -l /.autorelabel

Вывод должен показать вновь созданный файл.

-rw-r--r--. 1 root root 0 <date> <time> /.autorelabel

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

sudo rm /.autorelabel

На этом завершается моделирование сброса пароля root. Вы отработали ключевые команды (passwd и touch /.autorelabel), которые являются центральными в процессе восстановления.

Исправление ошибок /etc/fstab с использованием аварийного режима

На этом шаге вы узнаете, как диагностировать и исправлять ошибки в файле /etc/fstab. Этот файл критически важен для процесса загрузки, поскольку он сообщает системе, какие файловые системы монтировать и где. Неправильная запись в /etc/fstab может помешать загрузке системы, принуждая ее к переходу в emergency mode (аварийный режим).

Аварийный режим обеспечивает максимально минимальную среду для восстановления системы. В отличие от режима восстановления, он не пытается смонтировать большинство файловых систем или запустить многие службы. Важно отметить, что корневая файловая система (/) монтируется в режиме только для чтения (ro), чтобы предотвратить дальнейшее повреждение.

Хотя мы не можем вызвать реальный сбой загрузки в этой лаборатории, мы можем смоделировать процесс поиска и исправления ошибки /etc/fstab.

Сначала давайте намеренно добавим ошибочную запись в /etc/fstab. Мы будем использовать команду echo с sudo, чтобы добавить строку, ссылающуюся на несуществующее устройство.

echo '/dev/nonexistent /data xfs defaults 0 0' | sudo tee -a /etc/fstab

Теперь давайте посмотрим содержимое /etc/fstab, чтобы подтвердить, что наша плохая строка была добавлена.

cat /etc/fstab

Вы должны увидеть неправильную строку в конце файла.

#
## /etc/fstab
## Created by anaconda on <date>
#
## Accessible filesystems, by reference, are maintained under '/dev/disk/'.
## See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info.
#
## After editing this file, run 'systemctl daemon-reload' to update systemd
## units generated from this file.
#
/dev/vda4 / xfs defaults 0 0
/dev/vda2 /boot xfs defaults 0 0
/dev/vda1 /boot/efi vfat umask=0077,shortname=winnt 0 0
/dev/vda3 swap swap defaults 0 0
/dev/nonexistent /data xfs defaults 0 0

Далее мы смоделируем диагностический шаг. Команда mount -a пытается смонтировать все файловые системы, перечисленные в /etc/fstab, которые еще не смонтированы. Поскольку наша запись недействительна, эта команда завершится неудачей.

sudo mount -a

Команда выдаст ошибку, четко указывающую на то, что точка монтирования /data не существует. Это похоже на ошибку, которую вы увидите во время неудачной загрузки.

mount: /data: mount point does not exist.

Теперь давайте смоделируем процесс восстановления. В реальной аварийной оболочке первым шагом является перемонтирование корневой файловой системы в режиме чтения-записи, чтобы разрешить внесение изменений.

sudo mount -o remount,rw /

Теперь, когда файловая система доступна для записи, вы можете отредактировать /etc/fstab, чтобы исправить ошибку. Используйте редактор nano, чтобы открыть файл.

sudo nano /etc/fstab

Внутри редактора nano используйте клавиши со стрелками, чтобы перейти к ошибочной строке (/dev/nonexistent /data xfs defaults 0 0) и удалить ее. Вы можете удалить всю строку, нажав Ctrl+k. После удаления строки сохраните файл, нажав Ctrl+x, затем y и, наконец, Enter.

Чтобы подтвердить исправление, снова запустите sudo mount -a.

sudo mount -a

На этот раз команда должна выполниться молча, без вывода, что указывает на то, что все действительные записи в /etc/fstab правильно смонтированы. Вы успешно исправили файл.

Резюме

В этой лабораторной работе вы изучили основные методы устранения неполадок в процессе загрузки Red Hat Enterprise Linux. Вы попрактиковались в управлении целями загрузки systemd, например, в просмотре текущей цели по умолчанию и изменении ее между graphical.target и multi-user.target с помощью systemctl. Вы также узнали, как прервать последовательность загрузки для доступа к специализированным средам восстановления, включая загрузку в режим восстановления из меню GRUB для выполнения задач обслуживания системы в однопользовательской оболочке.

Кроме того, вы выполнили критические процедуры восстановления при распространенных системных сбоях. Вы успешно сбросили забытый пароль root, используя параметр ядра rd.break, перемонтировав корневую файловую систему с разрешениями на запись и используя среду chroot для установки нового пароля, а также решив проблему с контекстом SELinux путем создания файла .autorelabel. Наконец, вы научились устранять сбои загрузки, вызванные ошибками /etc/fstab, войдя в аварийный режим, определив проблемную запись и закомментировав ее, чтобы позволить системе успешно загрузиться.