☰

「代替」ディストリビューションにルートを切り替えるときは、どのproc、sysなどをバンドルしてマウントする必要がありますか（バンドルでマウントしないでください）。

tag-icon • tag-icon mount chroot proc sysfs
「代替」ディストリビューションにルートを切り替えるときは、どのproc、sysなどをバンドルしてマウントする必要がありますか（バンドルでマウントしないでください）。

これは他の質問に対する答えですデフォルトでは、他のLinuxディストリビューションに帰結するため、主に過度に制限されているがchroot置き換えられない親ディストリビューションを置き換えるために使用できます。chroot実行する前に推奨されるアクションが何であるかをよりよく理解したいと思います。

cp /etc/resolv.conf etc/resolv.conf
cp -a /lib/modules/$(uname -r) lib/modules
mount -t proc archproc proc
mount -t sysfs archsys sys
mount -o bind /dev dev
mount -t devpts archdevpts dev/pts
  • resolv.confわかりませんが、レプリケーションは明確です（ネットワーク/インターネットアクセス）。modulesこれは実際にstage3 Gentooシステムに入るときは不要に見えます。そうですか？chroot
  • しかし、procバインドインストールを使用する代わりに再インストールするのはなぜですか？何ですかsysdev/pts実際この場合、「より正確な」ものは何ですか？
  • この動作方法マウントprocとをバインドするdevが、マウントがまったくないdev/ptsか。sysまた、/etc/{hosts,fstab}新しいルートディレクトリにコピーされます。馬になる？私も/etc/mdadm.conf含めてはいけないのか？

答え1

DNS を失わないようにするには、/etc/resolv.conf をコピーします。

chroot を設定するときに、不要なハードウェアコンポーネントの一部を使用する必要があるため、/lib/modules がコピーされます。 OPで述べた元の質問は、NAS OSをArch Linuxに置き換えることに関連していることを覚えておく必要があります。そのため、イーサネット、ワイヤレス、さまざまなUSBコンポーネントなどのドライバが必要です。 /lib/modules フォルダをコピーすると、新しい環境が将来のタスクを処理できるようになります。

再インストールとバインドのインストールについて実際には正しいです。これchrootのArch Linux Wikiページ引用した投稿に対する回答に基づいて指定したように、再インストールとバインドマウントを使用します。

cd /mnt/arch
mount -t proc proc proc/
mount -t sysfs sys sys/
mount -o bind /dev dev/
mount -t devpts pts dev/pts/

（私の考えでは、これは次からコピーした行の構文を示すようです。この投稿、間違っています：マウントする開発者がマウントポイントの前にあります。

しかし、chrootのUbuntuのマニュアルページ他の話を聞きます：

sudo mount -o bind /proc /var/chroot/proc

ここで、/proc は再マウントされずにバインドマウントされます。

実際に両方の方法を試してみましたが、短いテストの実行後に何の違いも見つかりませんでした。もちろん、これはあまり大きなテストではないので、大きな影響を与えないので、ここでは私の意見を控えておきます。

答え2

  • /etc/resolv.conf- DNS要求を解決するにはこのファイルが必要です。場合によっては必要ありません。

    1. DHCPクライアントはchrootで利用可能で実行され、DHCPサーバーは適切な情報を返します（通常はそうです）。

    2. /etc/resolv.confchroot内のネットワーク（またはより正確にはそれに依存する一般的なアプリケーションのDNSクエリ）には興味がありません。

  • /lib/modules/$(uname -r)- アクティブカーネル用に別のモジュールをロードする必要がある場合に適しています。これがないと、現在実行中のジョブを続行できません。したがって、長期間にわたってルートが指定されたシステムを実行したい場合は、これを行う必要があります。一方、おそらくこの場合はこれを使用する必要がありますpivot_root（通常、initrdがライフサイクルの最後に実行する作業です）。 chrootからブートローダをインストールするなど、これだけを行う必要がある場合はこれは必要ありません（chroot自体を実行するには、必要なすべてのドライバをロードする必要があるため）。

  • /procそして/devそれは非常に明白です。基本的なシステムインターフェイスが含まれています。

  • /sysIIRCではないですか？それ2007年から広く使用されており、ここでSlackware（自体は非常に保守的）How-toが役に立たなくなりました。最近、これがないと、システムが何らかの方法で失敗する可能性が高くなります（たとえば、特定の種類のハードウェアを列挙しようとする場合など）。

  • /dev/pts-/dev木を扱う方法において長年にわたって若干の変化がありました。ある時点で、デバイスは/dev/pts次のもので構成されます。devfs- 例をご覧ください。このLKMLスレッド発生する可能性のある問題について説明します。

  • マウントバインド - マウントバインドにはいくつかの興味深い側面があります（mount(8)マンページでよく説明されています）。たとえば、次のような場合があります。

    /some/device on /x/a (rw)
/x/a/A on /x/b (rw)

    その後、/x/a読み取り専用で再インストールすると変更できません/x/B。これは理解できますが、最初は驚くかもしれません。もう一つの良い質問は、/x/b上記の例を使用したときに何が起こるかですumount /x/a。私にとっては、その下の木にまだアクセスできることは明らかではありません。そのため、バンドルの設置が難しい場合があります。機能的には、ファイルシステム全体で使用しても同じです。

  • 追加コンテンツ/etc/- 便利な関連設定をコピーすることをお勧めします。たとえば/etc/passwd、/etc/shadow​/etc/groups 可能サーバーキーも同じですsshd。

答え3

/procプロセスを管理し、sysカーネルパラメータを変更するか、現在のカーネルに関する情報にアクセスします。

今考えてみると製本双方向性を意味するので、procchrootの外にインストールしないことをお勧めします。

sysはい、しかし、現在実行中のカーネルホストによって異なり、dev同じホストへのバインディングとしてマウントする必要があります。

/dev/ptsすでに/devバインドインストールとして使用できますが、chrootの一部であるため、新規ptsインストールすることをお勧めしますmount -t devpts none /mnt/drive/dev/pts。

関連情報