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

Введение

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

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

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

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

Сначала перейдите в рабочую директорию для этой лабораторной работы.

cd /home/labex/project

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

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

systemctl get-default | tee step1-initial-target.txt

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

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 | tee step1-multi-user-target.txt

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

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 | tee step1-final-target.txt

graphical.target

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

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

Загрузка в режим Rescue из меню GRUB

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

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

Сначала найдем файл модуля 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 отобразит содержимое файла в терминале, а tee сохранит копию в вашей рабочей директории.

cat /usr/lib/systemd/system/rescue.target | tee /home/labex/project/rescue-target.txt

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

##  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. Служба rescue предоставляет корневую оболочку обслуживания.
• After=sysinit.target rescue.service: Определяет порядок активации, гарантируя, что режим rescue запускается после инициализации системы и службы rescue.
• AllowIsolate=yes: Позволяет переключаться на эту цель из другой цели с помощью команды systemctl isolate rescue.target в работающей системе.

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

systemctl list-dependencies rescue.target | tee /home/labex/project/rescue-dependencies.txt

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

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
... (вывод может отличаться) ...

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

Сброс пароля root с помощью rd.break и chroot

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

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

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

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

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

sudo passwd root

Вам будет предложено ввести и повторно ввести новый пароль. Установите его как redhat.

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 <дата> <время> /.autorelabel

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

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

Исправление ошибок /etc/fstab с помощью режима Emergency

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

Режим emergency предоставляет максимально минимальную среду для восстановления системы. В отличие от режима rescue, он не пытается монтировать большинство файловых систем или запускать многие службы. Важно отметить, что корневая файловая система (/) монтируется в режиме только для чтения (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 | tee /home/labex/project/step4-fstab-before.txt

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

#
## /etc/fstab
## Created by anaconda on <дата>
#
## 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 2>&1 | tee /home/labex/project/step4-mount-error.txt

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

mount: /data: fsconfig system call failed: /dev/nonexistent: Can't lookup blockdev.
       dmesg(1) may have more information after failed mount system call.

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

sudo mount -o remount,rw /

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

sudo vi /etc/fstab

Внутри редактора перейдите к ошибочной строке (/dev/nonexistent /data xfs defaults 0 0), удалите её и сохраните файл.

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

sudo mount -a

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

Резюме

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

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