GNU / Linuxシステムが存在する限り、システム管理者は、ルートファイルシステムの破損、偶発的な構成変更、またはシステムが「通常の」状態で起動できないその他の状況から回復する必要がありました。
Linuxディストリビューションは通常、起動時に（たとえば、GRUBメニューで）1つ以上のメニューオプションを提供し、壊れたシステムを救済するために使用できます。通常、ほとんどのシステムサービスが無効になっているシングルユーザーモードでシステムを起動します。最悪の場合、ユーザーはブートローダーのカーネルコマンドラインを変更して、標準シェルをinit（PID 1）プロセスとして使用する可能性があります。この方法は最も複雑で複雑な問題があり、システムの救助が必要なときにフラストレーションや時間のロスにつながる可能性があります。
その他のLinuxリソース
- Linuxコマンドのチートシート
- 高度なLinuxコマンドのチートシート
- 無料のオンラインコース：RHELの技術概要
- Linuxネットワーキングのチートシート
- SELinuxチートシート
- Linuxの一般的なコマンドのチートシート
- Linuxコンテナとは何ですか？
- 最新のLinux記事
最も重要なことは、これらの方法はすべて、損傷したシステムに何らかの物理コンソールがあることを前提としていますが、これはクラウドコンピューティングの時代にはもはや与えられていません。物理コンソールがない場合、この方法でブートプロセスに影響を与えるオプションは（あるとしても）ほとんどありません。物理的なマシンでさえ、使いやすいコンソールを提供しない小型の組み込みデバイスであり、適切なシリアルポートケーブルとアダプタを見つけてシリアルターミナルエミュレータをセットアップすることで、すべてシリアルコンソールポートを使用して緊急事態は、しばしば複雑です。
別のシステム（同じアーキテクチャで一般的に同様の構成）が利用可能な場合、修復プロセスを簡素化する一般的な手法は、損傷したシステムからストレージデバイスを抽出し、それらをセカンダリデバイスとして稼働中のシステムに接続することです。物理システムの場合、これは通常簡単ですが、ほとんどのクラウドコンピューティングプラットフォームは、損傷したインスタンスのルートストレージボリュームを別のインスタンスにマウントできるため、これもサポートできます。
ルートファイルシステムが別のシステムに接続されると、 fsckを使用してファイルシステムの破損に対処するのは簡単です。 およびその他のツール。構成の間違い、壊れたパッケージ、またはその他の問題への対処は、ファイルシステムをマウントし、正しい構成ファイルまたはデータベースを見つけて変更する必要があるため、より複雑になる可能性があります。
systemdの前 、テキストエディタで構成ファイルを編集することは、構成を修正するための実用的な方法でした。必要なファイルを見つけてその内容を理解することは別の課題である可能性があり、この記事の範囲を超えています。
GNU/Linuxシステムがsystemdを使用する場合 ただし、多くの構成変更は、提供するツールを使用して行うのが最適です。たとえば、サービスを有効または無効にするには、さまざまな場所でシンボリックリンクを作成または削除する必要があります。 systemctl ツールはこれらの変更を行うために使用されますが、それを使用するには systemdが必要です 実行され、リクエストを（D-Busで）リッスンするインスタンス。ルートファイルシステムが追加のファイルシステムとして別のマシンにマウントされている場合、実行中の systemd インスタンスを使用してこれらの変更を行うことはできません。
ターゲットシステムのsystemdを手動で起動する システム上のPID1プロセスとして設計されており、他のすべてのプロセスを管理するように設計されているため、実用的でもありません。これは、修復に使用されるシステムですでに実行されているインスタンスと競合する可能性があります。
ありがたいことに、 systemd コンテナ、独自のPID1を備えた完全にカプセル化されたGNU/ Linuxシステム、およびLinuxカーネルが提供するさまざまな名前空間機能を利用する環境を起動する機能があります。 DockerやRocketなどのツールとは異なり、 systemd コンテナを起動するためにコンテナイメージは必要ありません。既存のファイルシステムの任意の時点でルート化されたものを起動できます。これは、 systemd-nspawnを使用して行われます。 ツール。必要なシステム名前空間を作成し、コンテナーで初期プロセスを起動してから、コンテナーにコンソールを提供します。 chrootとは対照的 、ファイルシステムの見かけのルートのみを変更するこのタイプのコンテナには、別のファイルシステム名前空間があり、適切なファイルシステムが / devにマウントされます。 、 / run 、および / proc 、および個別のプロセス名前空間とIPC名前空間。 systemd-nspawnを参照してください その機能の詳細については、manページを参照してください。
この例では、破損したシステムのルートファイルシステムを含むストレージデバイスが実行中のシステムに接続されており、 / dev / vdcと表示されます。 。デバイス名は、既存のストレージデバイスの数、デバイスのタイプ、およびシステムへの接続に使用される方法によって異なります。ルートファイルシステムは、ストレージデバイス全体を使用することも、デバイス内のパーティションに配置することもできます。最も一般的な（単純な）構成では、ルートファイルシステムがデバイスの最初のパーティションに配置されるため、この例では / dev/vdc1を使用します。 以下のコマンドのデバイス名を、システムの正しいデバイス名に置き換えてください。
破損したルートファイルシステムは、デバイス上の単一のファイルシステムよりも複雑な場合もあります。これは、LVMボリュームセット内のボリューム、またはソフトウェアRAIDデバイスに結合されたデバイスのセット上のボリュームである可能性があります。このような場合、ファイルシステムを保持している論理デバイスを作成してアクティブ化するために必要な手順は、マウントできるようになる前に実行する必要があります。繰り返しますが、これらの手順はこの記事の範囲を超えています。
まず、 systemd-nspawnを確認します ツールがインストールされています—ほとんどのGNU/Linuxディストリビューションはデフォルトでツールをインストールしません。 systemd-containerによって提供されます ほとんどのディストリビューションでパッケージ化されているため、ディストリビューションのパッケージマネージャーを使用してそのパッケージをインストールします。この例の手順はDebian9を使用してテストされていますが、最新のGNU/Linuxディストリビューションでも同様に機能するはずです。
以下のコマンドを使用するには、ほぼ確実にroot権限が必要になるため、rootとしてログインするか、 sudoを使用する必要があります。 ルート権限を持つシェルを取得するか、各コマンドの前に sudoを付けます 。
まず、 fsckを使用します ターゲットファイルシステムの構造とコンテンツを確認するには：
$ fsck /dev/vdc1ファイルシステムに問題が見つかった場合は、質問に適切に答えて修正してください。ファイルシステムが十分に損傷している場合、修復できない可能性があります。その場合、その内容を抽出する他の方法を見つける必要があります。
次に、一時ディレクトリを作成し、ターゲットファイルシステムをそのディレクトリにマウントします。
$ mkdir /tmp/target-rescue
$ mount /dev/vdc1 /tmp/target-rescue
ファイルシステムをマウントした状態で、そのファイルシステムをルートファイルシステムとしてコンテナを起動します。
$ systemd-nspawn --directory /tmp/target-rescue --boot -- --unit rescue.targetコンテナを起動するためのコマンドライン引数は次のとおりです。
- -ディレクトリ/tmp/ target-rescue コンテナのルートファイルシステムのパスを提供します。
- -ブート コンテナのルートファイルシステムで適切なinitプログラムを検索して起動し、コマンドラインからパラメータを渡します。この例では、ターゲットシステムも systemdを使用しています PID 1プロセスとして、残りのパラメータはそれを対象としています。修復するターゲットシステムがPID1プロセスとして他のツールを使用している場合は、それに応じてパラメータを調整する必要があります。
- - systemd-nspawnのパラメータを区切ります コンテナのPID1プロセスを対象としたものから。
- -ユニットrescue.target systemdに通知します コンテナでは、ブートプロセス中に到達しようとするターゲットの名前。ターゲットシステムでのレスキュー操作を簡素化するには、通常のマルチユーザーモードではなく、「レスキュー」モードで起動します。
すべてがうまくいけば、次のような出力が表示されるはずです：
Spawning container target-rescue on /tmp/target-rescue.
Press ^] three times within 1s to kill container.
systemd 232 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN)
Detected virtualization systemd-nspawn.
Detected architecture arm.
Welcome to Debian GNU/Linux 9 (Stretch)!
Set hostname to <test>.
Failed to install release agent, ignoring: No such file or directory
[ OK ] Reached target Swap.
[ OK ] Listening on Journal Socket (/dev/log).
[ OK ] Started Dispatch Password Requests to Console Directory Watch.
[ OK ] Reached target Encrypted Volumes.
[ OK ] Created slice System Slice.
Mounting POSIX Message Queue File System...
[ OK ] Listening on Journal Socket.
Starting Set the console keyboard layout...
Starting Restore / save the current clock...
Starting Journal Service...
Starting Remount Root and Kernel File Systems...
[ OK ] Mounted POSIX Message Queue File System.
[ OK ] Started Journal Service.
[ OK ] Started Remount Root and Kernel File Systems.
Starting Flush Journal to Persistent Storage...
[ OK ] Started Restore / save the current clock.
[ OK ] Started Flush Journal to Persistent Storage.
[ OK ] Started Set the console keyboard layout.
[ OK ] Reached target Local File Systems (Pre).
[ OK ] Reached target Local File Systems.
Starting Create Volatile Files and Directories...
[ OK ] Started Create Volatile Files and Directories.
[ OK ] Reached target System Time Synchronized.
Starting Update UTMP about System Boot/Shutdown...
[ OK ] Started Update UTMP about System Boot/Shutdown.
[ OK ] Reached target System Initialization.
[ OK ] Started Rescue Shell.
[ OK ] Reached target Rescue Mode.
Starting Update UTMP about System Runlevel Changes...
[ OK ] Started Update UTMP about System Runlevel Changes.
You are in rescue mode. After logging in, type "journalctl -xb" to view
system logs, "systemctl reboot" to reboot, "systemctl default" or ^D to
boot into default mode.
Give root password for maintenance
(or press Control-D to continue):
この出力では、 systemdを確認できます。 コンテナ内でinitプロセスとして起動し、コンテナ内で実行されていることを検出して、その動作を適切に調整できるようにします。コンテナを使用可能な状態にするためにさまざまなユニットファイルが開始され、次にターゲットシステムのルートパスワードが要求されます。 root権限を持つシェルプロンプトが必要な場合は、ここにrootパスワードを入力するか、 Ctrl + Dを押すことができます。 起動プロセスを続行できるようにします。これにより、通常のコンソールログインプロンプトが表示されます。
ターゲットシステムに必要な変更を完了したら、 Ctrl +]を押します。 連続して3回;これにより、コンテナが終了し、元のシェルに戻ります。そこから、ターゲットシステムのファイルシステムをアンマウントし、一時ディレクトリを削除することでクリーンアップできます。
$ umount /tmp/target-rescue
$ rmdir /tmp/target-rescue
それでおしまい！これで、ターゲットシステムのストレージデバイスを削除して、ターゲットシステムに戻すことができます。
systemd-nspawnを使用するというアイデア このように、特に-ブートパラメータ 、StackExchangeに投稿された質問から来ました。この質問に役立つ回答を提供してくれたShibumiとkirbyfan64sosに感謝します。