RHEL ブートプロセスのトラブルシューティング

はじめに

このラボでは、Red Hat Enterprise Linux (RHEL) のブートプロセスをトラブルシューティングおよび修復するための重要な手法を学びます。システムの起動を妨げる一般的な問題を診断・解決するために、ブートシーケンスの各段階でシステムと対話する方法を探ります。これには、systemd ブートターゲットの操作や、システム復旧用に設計された特殊なブートモードの利用が含まれます。

各演習を通じて、systemctl を使用した systemd ターゲットの管理、システムメンテナンスのために GRUB メニューからレスキューモードで起動する方法、および rd.break カーネルパラメータを使用した root パスワードのリセット方法を実践的に学びます。さらに、緊急モードを使用して、破損した /etc/fstab などの重要な設定ファイルのエラーを修復し、起動不能なシステムを運用可能な状態に復旧する方法を習得します。

systemctl を使用した systemd ブートターゲットの管理

このステップでは、systemd ブートターゲットを管理する方法を学びます。systemd における「ターゲット」とは、システムを特定の状態にするために必要なさまざまなサービスやユニットをグループ化した同期ポイントのことです。これは、古い SysV init システムにおける「ランレベル」の現代的な代替手段です。ここでは、現在のデフォルトターゲットの確認、将来の起動に向けたデフォルトターゲットの変更、および一時的なターゲットの切り替え方法を探ります。

まず、このラボの作業ディレクトリに移動します。

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 ターゲットを管理する方法を習得しました。

GRUB メニューからレスキューモードで起動する

このステップでは、システム復旧用に設計された特別な systemd ターゲットである rescue.target について学びます。標準的な RHEL システムでは、再起動してブートローダー (GRUB) を中断し、カーネルのブートオプションにパラメータを追加することでこのモードにアクセスします。これにより、ルートファイルシステムがマウントされ、ほとんどのサービスが無効化されたシングルユーザーシェルが提供され、トラブルシューティングに最適です。

このコンテナ化されたラボ環境では実際の再起動や GRUB メニューへのアクセスはできませんが、レスキューモードの設定を確認することで、その仕組みを理解することは可能です。

まず、rescue.target の systemd ユニットファイルの場所を確認します。これらのファイルは通常 /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 の両方が開始されることを保証します。レスキューサービスはルートメンテナンスシェルを提供します。
After=sysinit.target rescue.service: アクティブ化の順序を指定し、システム初期化とレスキューサービスの後にレスキューモードが開始されるようにします。
AllowIsolate=yes: 実行中のシステムで systemctl isolate rescue.target コマンドを使用して、別のターゲットからこのターゲットに切り替えることを許可します。

レスキューモードが提供する最小限の環境をよりよく理解するために、その依存関係を表示できます。systemctl list-dependencies コマンドは、ターゲットの一部として開始されるすべてのユニットを表示します。この出力も保存しておきましょう。

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

出力にはレスキューモードに必要なユニットがリストされます。最小限のサービスセットが表示され、修復作業用に最適化された環境であることが確認できます。

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 がファイルシステムを読み書き可能でマウントしたルートシェルを提供し、システムの問題を修正できるようにするということです。次のステップでは、同様の原則に基づいた復旧シナリオをシミュレートします。

rd.break と chroot を使用した root パスワードのリセット

このステップでは、RHEL システムで失われた root パスワードをリセットする手順を学びます。これは非常に重要な復旧スキルです。標準的な方法は、rd.break カーネルパラメータを使用してブートプロセスを中断し、システムが完全に起動する前にシェルにアクセスすることです。

物理マシンや仮想マシンでは、再起動して GRUB ブートローダーを中断し、linux カーネル行の末尾に rd.break を追加します。この操作により、systemd が制御を引き継ぐ直前にブートプロセスが停止し、initramfs シェルに移行します。そこからの一般的な手順は以下の通りです。

システムのルートファイルシステム（/sysroot に読み取り専用でマウントされている）を mount -o remount,rw /sysroot コマンドで読み書き可能モードで再マウントする。
chroot /sysroot を実行して /sysroot に chroot ジェイルに入る。これにより、システムの実際のルートファイルシステムが現在の環境となり、システムに影響を与えるコマンドを実行できるようになる。
passwd コマンドを使用してパスワードを変更する。
SELinux コンテキストの問題に対処する。
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.

この復旧環境でパスワードを変更した後、パスワードファイル (/etc/shadow) の SELinux セキュリティコンテキストが不正確になる可能性があります。これを修正するには、次回の起動時にシステム全体の SELinux 再ラベル付けを強制する必要があります。これは、ルート (/) ディレクトリに .autorelabel という空のファイルを作成することで行います。

sudo touch /.autorelabel

ファイルが作成されたことを確認します。

ls -l /.autorelabel

新しく作成されたファイルが表示されるはずです。

-rw-r--r--. 1 root root 0 <日付> <時刻> /.autorelabel

実際のシステムでは、ここで exit を2回入力してシステムを再起動させます。システムは時間のかかる再ラベル付けプロセスを実行し、その後新しいパスワードで通常通り起動します。このラボでは確認のために /.autorelabel ファイルをそのままにしておきます（確認ステップで自動的に削除されます）。

これで root パスワードのリセットシミュレーションは終了です。復旧プロセスの中心となる重要なコマンド (passwd および touch /.autorelabel) を練習しました。

緊急モードを使用した /etc/fstab エラーの修復

このステップでは、/etc/fstab ファイルのエラーを診断および修復する方法を学びます。このファイルは、どのファイルシステムをどこにマウントするかをシステムに指示するため、ブートプロセスにおいて非常に重要です。/etc/fstab に誤ったエントリがあると、システムが起動できなくなり、「緊急モード (emergency mode)」に強制的に移行します。

緊急モードは、システム修復のために可能な限り最小限の環境を提供します。レスキューモードとは異なり、ほとんどのファイルシステムをマウントしたり、多くのサービスを開始したりしようとはしません。重要な点として、さらなる損傷を防ぐために、ルートファイルシステム (/) は読み取り専用 (ro) モードでマウントされます。

このラボでは実際の起動失敗をトリガーすることはできませんが、/etc/fstab エラーを見つけて修正するプロセスをシミュレートします。

まず、意図的に /etc/fstab に誤ったエントリを追加します。sudo を使用した echo コマンドで、存在しないデバイスを参照する行を追記します。

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.

それでは、修復プロセスをシミュレートしましょう。実際の緊急シェルでは、最初のステップは変更を許可するためにルートファイルシステムを読み書き可能モードで再マウントすることです。

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 のブートプロセスをトラブルシューティングするための重要な手法を学びました。systemctl を使用して、現在のデフォルトターゲットの確認や、graphical.target と multi-user.target 間での切り替えなど、systemd ブートターゲットの管理を練習しました。また、ブートシーケンスを中断して特殊な復旧環境にアクセスする方法や、GRUB メニューからレスキューモードで起動してシングルユーザーシェルでシステムメンテナンス作業を行う方法も学びました。

さらに、一般的なシステム障害に対する重要な復旧手順を実行しました。rd.break カーネルパラメータを使用してルートファイルシステムを書き込み権限付きで再マウントし、chroot 環境を使用して新しいパスワードを設定することで、忘れてしまった root パスワードを正常にリセットしました。その際、.autorelabel ファイルを作成して SELinux コンテキストの問題にも対処しました。最後に、緊急モードに入り、問題のあるエントリを特定してコメントアウトすることで、/etc/fstab エラーによる起動失敗を解決し、システムを正常に起動させる方法を学びました。