web-dev-qa-db-ja.com

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

別の質問に対するこの回答 基本的には、chrootingを別の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
  • modulesについては確信がありませんが、resolv.confのコピーは明確です（ネットワーク/インターネットアクセス）-chrootingをstage3 Gentooシステムにコピーする場合、これは実際には不要に見えましたね？
  • しかし、なぜproc、sysおよびdev/ptsが、バインドマウントを使用する代わりに再マウントされるのですか？この状況での実際の違いは何ですか。これは「より正確」です。
  • This HowTo bind-mounts procおよびdev、ただしdev/ptsもsysもマウントされていません。さらに、/etc/{hosts,fstab}を新しいルートにコピーします。それは理にかなっていますか？ /etc/mdadm.confも含めるべきではありませんか？
mountchrootprocsysfs
9
Tobias Kienzler

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

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

ただし、 chrootのUbuntuのマニュアルページ は別の話です。

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

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

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

9
MariusMatutiae

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

bindは双方向の性質を暗示することを考慮して、procを外部にマウントしないでください最良のソリューションとしてchroot。

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

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

0
PICCORO Lenz McKAY