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

はじめに

この実験（Lab）では、Red Hat Enterprise Linux (RHEL) の起動プロセスにおけるトラブルシューティングと修復に不可欠な技術を学びます。システムの起動を妨げる可能性のある一般的な問題を診断し解決するために、起動シーケンスのさまざまな段階でシステムと対話する方法を習得します。これには、systemd の起動ターゲットの操作や、システム復旧用に設計された特殊な起動モードの利用が含まれます。

演習を通して、systemctl を使用した systemd ターゲットの管理、システムメンテナンスのための GRUB メニューからのレスキューモードへの起動、rd.break カーネルパラメータを使用したルートパスワードのリセットなど、実践的な経験を積むことができます。さらに、破損した /etc/fstab のような、重要な設定ファイルの誤りなどを修復するために、エマージェンシーモードを使用する方法を学び、起動不能なシステムを運用可能な状態に復元できるようにします。

systemctl で Systemd 起動ターゲットを管理する

このステップでは、systemd の起動ターゲットを管理する方法を学びます。systemd において、「ターゲット」とは、システムを特定の状態にするために必要なさまざまなサービスや他のユニットをまとめた同期ポイントです。これは、古い SysV init システムにおける「ランレベル」の現代版に相当します。現在のデフォルトターゲットの表示、今後の起動のためのデフォルトターゲットの変更、および別のターゲットへの一時的な切り替えについて説明します。

まず、システムがデフォルトでどのターゲットに起動するかを確認しましょう。graphical.target は、デスクトップ環境を持つシステムで使用され、グラフィカルユーザーインターフェース (GUI) を提供します。multi-user.target は、コマンドラインインターフェースのみに使用されます。

現在のデフォルトターゲットを確認するには、次のコマンドを実行します。

systemctl get-default

デフォルトターゲットが graphical target であることが表示されるはずです。

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

この設定では、システムは再起動後にテキストベースのコンソールに起動します。この実験（Lab）では、一貫したグラフィカル環境を維持したいと考えています。デフォルトターゲットを 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 メニューからレスキューモードで起動する

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

このコンテナ化された実験（Lab）環境では、実際の再起動を実行したり、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 コマンドは、ファイルのコンテンツをターミナルに表示します。

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

rd.break と chroot を使用して root パスワードをリセットする

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

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

1. コマンド mount -o remount,rw /sysroot を使用して、システムのルートファイルシステム (/sysroot に読み取り専用でマウントされています) を読み書きモードで再マウントします。
2. chroot /sysroot を使用して、/sysroot で chroot jail に入ります。これにより、システムの実際のルートファイルシステムが現在の環境になり、システムに影響を与えるコマンドを実行できるようになります。
3. passwd コマンドを使用してパスワードを変更します。
4. 潜在的な SELinux コンテキストの問題に対処します。
5. chroot と initramfs シェルを終了して、起動を続行します。

この実験（Lab）環境では、実際の再起動を実行して rd.break を使用することはできませんが、chroot 環境に入った後に実行する最も重要なコマンドをシミュレートします。

まず、ルートパスワードの変更をシミュレートしましょう。chroot jail に正常に入ったとします。これで、任意のユーザーのパスワードを変更するためのルートアクセス権が得られます。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.

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

sudo touch /.autorelabel

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

ls -l /.autorelabel

出力には、新しく作成されたファイルが表示されます。

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

実際のシステムでは、ここで exit を 2 回入力し、システムを再起動します。長いラベル付けプロセスを実行し、新しいパスワードで正常に起動します。この実験（Lab）ではこれをトリガーしたくないため、作成したファイルを削除してクリーンアップします。

sudo rm /.autorelabel

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

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

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

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

この実験（Lab）では実際の起動障害を発生させることはできませんが、/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 のすべての有効なエントリが正しくマウントされていることを示しています。ファイルは正常に修復されました。

まとめ

この実験（Lab）では、Red Hat Enterprise Linux の起動プロセスのトラブルシューティングに不可欠なテクニックを学びました。systemctl を使用して、現在のデフォルトを表示し、graphical.target と multi-user.target の間で変更するなど、systemd の起動ターゲットの管理を練習しました。また、GRUB メニューからレスキューモードで起動してシングルユーザーシェルでシステムメンテナンスタスクを実行するなど、特殊な復旧環境にアクセスするために起動シーケンスを中断する方法も学びました。

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