「置換」ディストリビューションにchrootするときに、proc、sysなどのどれをバインドマウントする必要があるか（またはそうでないか）。

別の質問に対するこの回答は、基本的にはchroot、制限が厳しすぎる（ただし置き換えられない）親の代わりに主にそれを使用するために、別のLinuxディストリビューションに取り込むことです。実行前に推奨されるアクション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は明確ですが（ネットワーク/インターネットアクセス）、それについてはわかりませんが、stage3 Gentooシステムにアクセスするmodules場合、これは実際には不要のようchrootでしたね？
• しかし、なぜしているproc、sysとdev/pts代わりにバインド・マウントを使用しての再マウント？この状況の実際の違いは何ですか。「より正確」です。
• このハウツーバインドマウントprocとdev、どちらもdev/ptsもはsysすべてにマウントされています。さらに/etc/{hosts,fstab}、新しいルートにコピーします。それは理にかなっていますか？私も含めるべきではありません/etc/mdadm.confか？

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

/ lib / modulesがコピーされるのは、chrootのセットアップ時に存在する必要のないハードウェアコンポーネントを使用する必要があるためです。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/

（私はこれがこの投稿からコピーされたあなたの行の構文を間違っていると思います：マウントされるdevがマウントポイントの前にあります）

ただし、chrootのUbuntuのマニュアルページには別の話があります。

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

ここで、/ procはバインドマウントされ、再マウントされません。

私は実際に両方のことを試しましたが、短いテストを実行した後、違いに気付くことができませんでした。テストの多くは、確かにありません、そして、私はここで私のケースをここで休憩します。

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

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

  2. /etc/resolv.confchrootの内部からのネットワーキング（より正確にはに依存する通常のアプリケーションからのDNSクエリ）には興味がありません。

• /lib/modules/$(uname -r)-アクティブなカーネル用に追加のモジュールをロードする必要がある場合に備えてください。これがないと、現在実行しているものは何でも手に入るでしょう。したがって、chrootされたシステムを長時間実行する場合は、おそらくそれを実行する必要があります。一方、そのような場合は、おそらくpivot_root代わりに使用する必要があります（これは、通常、寿命の終わりにinitrdが行うことです）。ブートローダーをchrootからインストールするなど、必要なだけの場合は必要ありません（とにかくchrootを実行するには、必要なドライバーをすべてロードする必要があるため）。

• /procそして、/devかなり明白である-これらは、基本的なシステムのインタフェースが含まれています。

• /sysIIRCは2007年にそれほど広く使用されていませんでした。これはSlackware（それ自体はかなり保守的な方法）の日付です。最近では、システムがなんらかの理由で失敗する可能性があります（たとえば、何かが何らかのタイプのハードウェアを列挙しようとした場合など）。

• /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。

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

バインドが双方向の性質を暗示することを考慮するprocと、最善の解決策としてchrootの外部にマウントしないでください。

sys可能ですが、現在実行中のカーネルホストに依存しておりdev、バインドと同じようにマウントする必要があります。

/dev/pts/devはバインドマウントされた状態ですでに利用可能ですが、chrootの一部なので、新しいptsものを再マウントすることをお勧めしmount -t devpts none /mnt/drive/dev/ptsます。