chroot環境に関して「mount-t ...」と「mount-obind ...」の違いは何ですか？
だから私はproc、sys、devフォルダーが必要なchrootを設定しています。
私はそれらを次のようにマウントする必要があることを読みました：
mount -t proc /proc /mnt/chroot/proc
mount -t sysfs /sys /mnt/chroot/sys
mount -o bind /dev /mnt/chroot/dev
ここから得られた回答： mount-dev-proc-sys-in-a-chroot-environment
しかし、違いがどこに説明されているのかわかりませんでした。それらがどのように大きく異なる可能性があるのかわかりません...
/devはtmpfsバリアント（devtmpfs）です。カーネルはデバイスノードを入力しますが、内容は柔軟であり、devユーザースペースデーモンはパーミッションを調整し、シンボリックリンク（/ dev/disk/by- *など）を作成します。
Udevによって行われた変更を引き継ぐために、既存のインスタンスをバインドする必要があります。 新しいインスタンスをマウントしようとすると、カーネルが提供するノードだけで、udevリンクがない新しいtmpfsが得られます。 どうやら現在のカーネルdoは、通常のtmpfsではなく、devtmpfsを単一インスタンスとして扱います。つまり、2回マウントしても、どちらの場合も同じ内容になります。
ただし、同じ理由が当てはまると思います。/devをバインドすることをお勧めします。これは、従来のtmpfsと同じように機能するという、私が（正しくかどうかにかかわらず）行ってきたのと同じ仮定をしているためです。
さらに、ごく最近まで、/ dev was実際には、ユーザースペース（udevなど）によって作成されたeverythingを含む従来のtmpfsです。 devtmpfsを追加する前にシステムを操作する場合、/ devのバインドは依然として必要でした。
/procおよび/sysは完全に仮想のファイルシステム（procfsとsysfs）です。カーネルはall操作を制御し、厳密な構造を定義します。
同じ名前空間内の複数のprocfsまたはsysfsマウントは完全に同一であり、それらはすべてファイルシステムの同じインスタンスを参照します。したがって、通常のchrootの新しいインスタンスをマウントすることと、既存のインスタンスをバインドすることの間に違いはありません。
（プロセス名前空間やネットワーク名前空間などのコンテナーを操作すると、違いが現れ始めます。コンテナー内に新しいprocfsインスタンスをマウントすると、それ自体のプロセスのみが表示されます。ホストのprocfsをバインドすると、コンテナーはすべてのプロセスを表示できます。 ）