web-dev-qa-db-ja.com

/ etc / fstabはブート時にマウントをバインドできませんが、mount -aを実行すると正しく機能します

変更されたWDMyCloud（Gen 1）NAS、Debian 8（Jessie）がインストールされた状態で実行しています。

デバイスのニュアンスが原因で、ルートパーティションのサイズを変更できず、そのスペースに苦労しています。

これを修正するために、/varおよび/usrディレクトリをメインデータパーティションにrsyncしました。

次に、/etc/fstabに次の行を追加しました。

/data/rootfs/var    /var    none    defaults,bind    0    0
/data/rootfs/usr    /usr    none    defaults,bind    0    0

再起動すると、/varディレクトリには成功がマウントされていますが、/usrディレクトリにはされていないです。

その後、mount -aを実行してもエラーは発生せず、/usrディレクトリは正しくマウントされています。

何が問題になっていますか？

debianmountfstabbind-mount
3
Jack_Hu

Systemdを使用している場合、マウントは並列に行われ（ fstabエントリーをマウントユニットに動的に変換することによって ）、システム化前の経験から予想されるように行の順序は保持されません。

自動的に推測されない未知の依存関係があります：/data/をマウントする前に/usrをマウントします。それがないと、競合状態になります。

x-systemd.requires= を使用して、依存関係を疑似マウントオプションとして手動で追加する必要があります。したがって、マウントする必要がある前のマウントポイントが/dataの場合、これで機能するはずです。

/data/rootfs/var    /var    none    x-systemd.requires=/data,bind    0    0
/data/rootfs/usr    /usr    none    x-systemd.requires=/data,bind    0    0

他の誰かがこの質問を見つけたが、ユースケースが/dataがNFSのようなリモートネットワークファイルシステムである場合、疑似マウントオプション_netdev（systemdによって認識されるpre-systemdオプション）はalsoを/data/rootfs/usrエントリに追加して、すべてが正常に機能するようにします。これは、noneがこれを自動的に示唆することができず、次に、x-systemd.requires=の解決を混乱させます。

4
A.B