TURNKEYGNU / LINUX
日本語

ドキュメント

方法:ライブCD / ISOまたは代替Linuxシステムを介して壊れたシステムにChroot

時々、壊れた/unbootable TurnKeyサーバーを救う必要があるかもしれません。 ハードウェアの故障が起きているか、それとも何かを誤って壊れているか、壊れたバグ修正をインストールしたのか?

これらの問題は、機能(Linux)システムから壊れたシステムに「chrooting」で固定することができ、問題の解決に必要な手順を講じます(grubを再インストールします。 カーネルを再インストールし、initramfs を再構築するなど)。 明らかに壊れたシステムを修正する手順は、実際に壊れたシステムに依存します。 わからない場合は、新しいスレッドを新しいスレッドで起動するのが最善でしょう。 フォーラム (新しいスレッドを開始するには、無料のウェブサイトのユーザーアカウントが必要です)ので、問題の診断をお手伝いします。

このドキュメントでは、chroot を入力すると、特定の問題の解決方法の詳細に進むまで、私はちょうどアドバイスします(ただし、もし/私は取得するとき おそらく、私は、最もよくある問題のいくつかのためにドキュメントページを書いていますか?!)。

注意:: このガイドでは、rootユーザアカウントでログインしていると仮定します。もしそうでなければ、chroot以外のコマンドは'sudo'で前向きにする必要があるかもしれません。 sudo で chroot を入力すると、chroot 内では一度は必要とされないはずです。

まずは、少し背景を上回って。もし、もし、そうなら、まっすぐにジャンプしてみたい。 chroot の設定お気軽にお問い合わせ下さい。

"chroot" とは

ウィキペディアによると、 chroot の:

現在の実行プロセスとその子のルートディレクトリを変更します。 そのような環境で実行されるプログラムは、指定されたディレクトリツリーの外に名前(そしてそれ故に通常アクセスできません)ファイルの名前をつけません。

Linux ユーザとして、遭遇するchroot の 2 種類があります。"標準" chroot を呼び出すと、"chroot jail" も表示されます。

chroot の目的は、ディレクトリツリーの特定の部分内のユーザまたはプロセスをロックする。例えば プログラムは、ファイルシステムの残りの部分にアクセスしないように、独自のディレクトリ(たとえば、postfix は、このように設定されます)に "chrooted" されるかもしれません。 または、限られたユーザが、ホームディレクトリに "chrooted" である可能性があるため、SFTP を使うことができますが、ファイルシステム全体を参照することはできません。

起動できないシステムを調査し、修理するために「標準」のchrootを使用することができます。また、新しいLinuxシステムを構築するのに一般的に使用されています。 例えば、TurnKey は "標準" chroot を使用します (on) 寸法: TKLDev) TurnKey アプライアンス をビルドします。 これは、ここでドキュメントするchrootのソートです。

chroot の設定

準備方法

最初に行うことは、システムが壊れたシステムからアクセス可能であることを確認することです。 ベアメタルインストールやVMの場合、これはライブCD / USB / ISOから起動するのが最も簡単な方法です。 一般的なルールとして、壊れたシステムが何であるかと同じOSを使用するのが最善です。 TurnKeyの場合、あなたは使用することができます コアコア (またはその他のサーバー; コアは最小限です) 同じメジャーバージョンの。例えば、v15.0コアは、v15.x アプライアンスを修正するために使用するのが良いです。 オプションでない場合、Debian Liveシステムも良いオプションです。 ケースのシナリオを心配すると、マッチングバージョンのTurnKey(またはDebian)が優先されているにもかかわらず、比較的最近のLinuxのdistroで逃げることができます。

どんなことでも NOT の 壊れたシステムの上にインストール! 回復不可能になります!

ディスク(物理または仮想)を別の(動作)マシン(TurnKey/Debian/etc を上回る)に移動することもできます。 必要なのも本質的にAWSサーバーのために(つまり、壊れたシステムから一次ボリュームを分離し、作業システムに再添付する)。

マウントする正しいボリュームを見つける

作業システムに分割した主体積を取り付けた後、次のステップをマウントします。 マウントするには、きれいなマウント位置を持っていることを確実にする必要があります。また、マウントする必要があるディスク/ボリューム/パーティションを動作させる必要があります。

きれいなマウント位置が使えるようにする簡単な方法が1つあります。

mkdir /rescue

正しいドライブ/ボリューム/パーティション(s)が少しトリッキーであることができることを確認するが、使用できるツールは fdisk です。 添付したすべてのボリュームを表示するには、次のコマンドを実行します。

fdisk -l

現在、AWSサーバで出力している。/dev/xvdf,として、デフォルトのルートボリューム(つまり、別のサーバーのルートボリューム)を/dev/xvdf,として付けた二次ドライブ(別のサーバーのルートボリューム)があります。 作業サーバーのルートボリュームは、/dev/xvda. です。(AWS にいると同じでしょう) あなたのために異なるかもしれません。ここでは、フル出力です。

root@core ~# fdisk -l
Disk /dev/xvda: 10 GiB, 10737418240 bytes, 20971520 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 6183BC26-31B1-41F2-9AB9-319B7C4A85B0

Device     Start      End  Sectors Size Type
/dev/xvda1  2048     6143     4096   2M BIOS boot
/dev/xvda2  6144 20969471 20963328  10G Linux filesystem

Disk /dev/xvdf: 10 GiB, 10737418240 bytes, 20971520 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 0029AB38-4BE5-4009-B163-9A7B4F597FE4

Device     Start      End  Sectors Size Type
/dev/xvdf1  2048     6143     4096   2M BIOS boot
/dev/xvdf2  6144 20969471 20963328  10G Linux filesystem

どのボリュームが1つであるのかわからない場合は、既にどのボリュームがマウントされているかを確認してください。 このようにしてください。

 mount | grep ^/dev

つまり、私のケースで/dev.から始まるマウント出力からすべての行をチェックします。これは私が既に知っているものを確認します、私が既にマウントしたボームは/dev/xvda:です

root@core ~# mount | grep ^/dev
/dev/xvda2 on / type ext4 (rw,relatime,data=ordered)
/dev/xvda2 on /tmp type ext4 (rw,relatime,data=ordered)
/dev/xvda2 on /var/cache/tklbam type ext4 (rw,relatime,data=ordered)

chroot に準備ができた壊れたシステムを取付けて下さい

そこで、どのパーティションをマウントする必要があるかを調べた。それはかなり簡単です。私の場合、マウントする必要があるパーティションは/dev/xvdf2です(つまり、マウントする必要がある。 上記で/dev/xvf).の2番目のパーティションは、fdiskから出力されたとき、/dev/xvdf1が「BIOS boot」と/dev/xvdf2が「Linux filesystem」になっていることがわかります。 このように簡単にマウントするには:

mount /dev/xvdf2 /rescue

/rescue (つまり、ls /rescue), でチェックすると、次のようなものが表示されます。

root@core ~# ls -l /rescue
total 92
drwxr-xr-x   2 root root  4096 Apr 16 02:49 bin
drwxr-xr-x   3 root root  4096 Apr 16 02:50 boot
drwxr-xr-x   5 root root  4096 Oct  3  2018 dev
drwxr-xr-x 100 root root  4096 Apr 16 02:50 etc
drwxr-xr-x   3 root root  4096 Oct  3  2018 home
lrwxrwxrwx   1 root root    29 Oct  3  2018 initrd.img -> boot/initrd.img-4.9.0-8-amd64
lrwxrwxrwx   1 root root    29 Oct  3  2018 initrd.img.old -> boot/initrd.img-4.9.0-8-amd64
drwxr-xr-x  18 root root  4096 Oct  3  2018 lib
drwxr-xr-x   2 root root  4096 Mar 11  2018 lib64
drwx------   2 root root 16384 Oct  3  2018 lost+found
drwxr-xr-x   2 root root  4096 Mar 11  2018 media
drwxr-xr-x   4 root root  4096 Apr 16 02:49 mnt
drwxr-xr-x   2 root root  4096 Mar 11  2018 opt
drwxr-xr-x   2 root root  4096 Feb 23  2018 proc
drwx------   5 root root  4096 Oct  3  2018 root
drwxr-xr-x  12 root root  4096 Oct  3  2018 run
drwxr-xr-x   2 root root  4096 Apr 16 02:49 sbin
drwxr-xr-x   2 root root  4096 Mar 11  2018 srv
drwxr-xr-x   2 root root  4096 Feb 12  2017 sys
drwxrwxrwt   7 root root  4096 Apr 16 02:51 tmp
drwxr-xr-x  10 root root  4096 Mar 11  2018 usr
drwxr-xr-x  13 root root  4096 Oct  3  2018 var
lrwxrwxrwx   1 root root    26 Oct  3  2018 vmlinuz -> boot/vmlinuz-4.9.0-8-amd64
lrwxrwxrwx   1 root root    26 Oct  3  2018 vmlinuz.old -> boot/vmlinuz-4.9.0-8-amd64

明らかに日付は異なりますが、それ以外の場合は、システムが期待通りにマウントされていることを示しています。 TurnKeyのすべての現在のビルドには、/bootパーティションが含まれているが、一部の古いリリースでは、インストールがLVMを使用している場合は、/bootパーティションを別々にマウントする必要があります。 その場合、メインOSがマウントされた後、ブートディレクトリをマウントします。 このように何か(スーツに合わせるのは簡単です):

mount /dev/sdXN /rescue/boot

/dev/sdXN がブート情報を取り除いたパーティションです。

しかし、もっと待って...!メインOSがマウントされたら、chrootが正しく機能するように、ホストからいくつかの特別なディレクトリをマウントする必要があります。 主にこれらは/dev, /procと/sys. /dev/ptsも実装価値があります。 経験の中で、取り付けなしで逃げることができますが、誤りがよくなりますので、騒音を抑えるのは、取り付ける価値があります。

mount -t proc proc /rescue/proc
mount -t sysfs sys /rescue/sys
mount -o bind /dev /rescue/dev
mount -t devpts pts /rescue/dev/pts

チェルートイン

単に chroot を chroot に chroot する という 必要が あります。 このようにして います:

chroot /rescue

こんな感じで簡単! :)

システムの修正に必要なものは何でも行います。 満足したら(または単にテストの準備が整った)、このようにchrootを終了できます。

exit

後方を拭き取る

壊れたドライブを取除くためにサーバーを停止する必要がある場合は、クリーンアップは必要ありません。 コンポーネントは、シャットダウンプロセスの一部として自動アンマウントされるべきです。 サーバーを停止する必要がない場合、再起動は、chroot をクリーンアップするための最も簡単な方法です。 しかし、使用しているサーバーを停止しない場合、または何らかの理由でchrootの設定を解除したい場合は、chrootを終了した後、chrootを終了した後、chrootを終了したら、chrootを退出する必要があります。 上記のコマンドのバックトラック。 マウントではなくumountを使用し、マウントされた逆の順番にそれらをアンマウントします。 すなわち:

umount /rescue/dev/pts
umount /rescue/dev
umount /rescue/sys
umount /rescue/proc

別のブートパーティションをマウントすると、その次のアンマウント。 私は「umount /rescue/boot'.」のその後、最後に、メインボリューム:

umount /rescue