私はsystemdこれがDebianが行っている方向であるように見えるので、適応しようとしています。
chrootネットワークを使用する代わりに、ハードウェアでXorgを実行したい（そんな気がするsystemdこれは、ホストシステムにXサーバーをインストールしたくないため、コンテナでこれを行う正式な方法です。私はホストが合理化され、メンテナンスの少ないオペレーティングシステムになりたいです。
これは私のものです。理解するしたがって、仮想化はsystemd-nspawnハードウェア/devへのアクセスを許可しません。
標準を実行するのはchroot実際にはかなりうまくいくようですが、それに微妙な問題があるかどうかはわかりません。
ハードウェアに直接アクセスできるゲストに加えて、システムシステムで「実際の」chrootを実行するのは悪い考えです。？それでは、どのような問題が発生しますか？
その場合はいsystemd-nspawn悪い習慣です。 「安全でない」フラグのようにこれを行う方法はありますか？ページでは見つかりませんがman、このページ、フラグがあります--share-system。これは私にとってはうまくいきません。
ベストアンサー1
nspawnsystemd開発者は、実際のハードウェアへのアクセスを許可することに非常に反対します。ペトリン説明する：
まあ、私たちはコンテナが実際に仮想化された環境にアクセスするためにのみ使用されると信じています。つまり、/devはほとんど空でなければならず（モジュロ/dev/null、/dev/randomなど）、コンテナは実際に物理環境にアクセスしてはいけません。ハードウェア。もちろん、これはコンテナ内でXサーバーを実行することを許可しません。
他のコンテナソリューションはホストからコンテナへのハードウェア配信をサポートしていますが、nspawnなどの単純なツールには焦点が少し合わず、そのままにしておく必要があると思います。
Arch Linuxの「標準」インストールはsystemdに基づいています。ウィキペディアchroot伝統が悪いという言葉はありません。 Traditionalが非システムの要件をchroot満たしていると仮定すると、systemdシステムに問題はないはずですsystemd。場合によっては、追加の「仮想化」がnspawn役に立つかもしれませんが、限定的なケースもあります。