chroot環境でdev、proc、sysをマウントしますか？

87

カスタム選択パッケージでLinuxイメージを作成しようとしています。
_{私がやろうとしているのは、XOラップトップで使用するパッケージを手作業で作成することです。必要なパッケージをすべてビルドして、 XOへの画像、時間とスペースを節約できます。}

いくつかのパッケージをインストールしようとしたときに、proc、sys、devディレクトリがないために設定に失敗しました。そのため、他の場所から、ホストプロシージャを「マウント」する必要があることを学びました。

私は2つの構文を見ましたが、どちらを使用するかわかりません。

ホストマシンで：

  mount --bind /proc <chroot dir>/proc

および別の構文（chroot環境）：

  mount -t proc none /proc

どちらを使用する必要があり、違いは何ですか？

linux debian chroot

— パトリック
ソース

注意：ディスクデバイスへのアクセスを許可すると、「chroot()」の利点の一部が失われます。特に、気をつけないと、決心した人はファイルシステムのセクション外のファイルを読み取ることができます。

— ジョナサンレフラー

2

@ジョナサンレフラー：それは彼がやっていることの問題のようには聞こえません。

— ジフレ

@rootの@JonathanLefflerは、とにかく常にchrootをエスケープできます。

— -LtWorf

43

とについては/proc、/sysどちらの方法も使用できると思います。どちらも特別なファイルシステムであるため、何度でも再作成できます（バインドマウント方法はホストシステムとまったく同じマウントを使用しますが、他の方法は新しいマウントを使用します）。私はガイドで推奨されているバインドマウントを常に見てきたので、それを使用します。私の知る限り、重要な違いはありません。

ただし、/dev通常はudevによって管理されるtmpfsマウントであるため、ホストマシン上と同じ実際のファイルシステムである必要があります。つまり、バインドマウントメソッドを使用する必要があります。

このchrootがしばらく存在する場合は、これらのエントリを/etc/fstabホストシステムに配置して、物事を単純化できます。

— ジフレ
ソース

ホストから他のマシンにproc / sysをコピー（バインド）するのが理にかなっているかどうかを尋ねたいのですが？なぜ彼らはそのマシンと一致する必要がありますか？

— ランシュ

@ranshは、/ procを$ chrootdir / procにバインドすると、両方のシステムから両方のシステムのproccessおよび/ procの内部で起こっていることを処理できる可能性があります。例：chrootから、ホスト上でプログラムが実行されているかどうかを確認できます...など

— ジョナ

たぶん、sys typeファイルシステムは（今日）もう存在しないように見えますか？

— 174140

111

アーチLinuxのWikiのは、次のコマンドを提案します：

cd /mnt/arch # or where you are preparing the chroot dir
mount -t proc proc proc/
mount --rbind /sys sys/
mount --rbind /dev dev/

— ガクルス
ソース

2

彼らはまた、ubuntuで私のために働いているようです。

— -isaaclw

4

私の場合（Ubuntuも）、「mount -o bind / dev / pts dev / pts」も必要でした。

— トーマス

ソースへのリンクを含めてください。

— 発泡スチロールフライ

@styrofoamflyが追加されました。

— ガクルス

1

2019のとおり、ArchLinuxのwikiは現在ありません--rbindのためにsysとdev。

— Saad Malik

12

Gentooハンドブックは、具体的に再マウントは/ procと/ devのための2つのコマンドを呼び出します。私はそれらを数回使用しています。

mount -t proc none /mnt/chroot/proc
mount -o bind /dev /mnt/chroot/dev

/ sysは単なる通常のフォルダーであるため、ハードリンクを作成できるはずです。

ln /sys /mnt/chroot/sys

— ロバート
ソース

17

/ sysのようにディレクトリをハードリンクすることはできません（通常）。シンボリックリンクを使用すると、chrootするとすぐに壊れてしまいます。

systemdに基づいて、新しいものを追加しました。おそらく、それらを追加することをお勧めします。

— AzP

1

Arch Linuxがarch-chrootスクリプトを作成したことは、このよくある質問で注目に値するかもしれません。ダウンロードarch-install-scripts-15-1-any.pkg.tar.xz

これはArch-LinuxとManjaroの両方でさまざまな関連する問題を処理します。おそらくParabolaのようなより多くのArch 派生物も同様に互換性があります。

chrootセカンダリManjaroインストールへの単純な標準では、実行できません

pacman --sync linux

（システムクラッシュ後の特効薬）、行を

arch-chroot /run/media/*YOURSELF*/manja-disk2

を使用して、セカンダリArch-Derivateインストールを修正できます。

pacman --sync linux

魔法のように。bashスクリプトarch-chrootは/dev /sys /proc、標準で残された多くのことを処理しますchroot。

参照：arch-chrootの使用

— おい
ソース

-1

他の疑似ファイルシステムとtmpfsの場所があります。これはdebianにあります：

/dev/pts 
/run
/run/shm
/proc/sys/fs/binfmt_mist
/var/lib/nfs/rpc_pipefs
/proc/fs/nfsd
/proc/bus/usb

chroot内からusbfs、rpc_pipefsおよびdevpts擬似ファイルシステムをマウントしても問題ありません。カーネルには名前空間の概念があり、実際にはchrootのprocに異なるものを入れることができるため、chrootにバインドしないことをお勧めします。 /proc/proc

更新：このメーリングリストスレッドによると、特にchrootされたプロセスが独自のネットワーク名前空間を使用している場合、/ sysをバインドマウントしないでください。

chrootが独自のpid名前空間を持っている場合、システム/varまたは/runchroot にマウントすることは悪い考えです。

— ブライアン・ミントン
ソース

投機？スーパーユーザー（および他のスタックフォーラム）では、よく分からない場合は、リンク先のソースを調べたり、回答したりすることをお勧めします。これは、誤ったヒントを広めるリスクを回避するためです。失望と幸運をお祈りします！

— サイモンB.

@SimonB。/ sysをバインドマウントすべきではないという考えをサポートするメーリングリストへのリンクを追加しました。

— ブライアンミントン

pid名前空間では、最新のlinuxカーネルで見つけることができるより高度なユーザー名前空間機能（つまり、「コンテナー」に基づく機能）について話しているのに対し、chrootという用語を使用するときは、従来のファイル名前空間の変更（何もありません）。

— ヨハンブール16

-1

最も簡単な方法は、forループを使用することです。

cd /

for i in proc sys dev; do mount -o bind $i /folder/$i; done

— オレベルリン
ソース