デフォルトでは、systemdはわずかなエラーが発生すると緊急シェルに入ります。たとえば、fstabのマウントの1つが何らかの理由で失敗した場合、システムはすぐに起動しません。私は何十もの異なる生産システムを管理していますが、これらの行動は非常に破壊的だと思います。 （実際、これは重大なデザインの失敗だと思いますが、これは個人的な意見です。）
システム起動弾力性を向上させたい。最良のシナリオは、ドライバ、マウントなどが不足しているため、システムを常に起動する必要があることです。特定のエラーが原因でコンソールログインが絶対に不可能でない限り、緊急シェルを破棄しないでください（警告のみが表示されます）。走ることができれば走らなければならない。
私はsystemdが/ etc / fstabから* .mountファイルを自動的に生成することを知っており、より小さなx-systemd.deviceタイムアウトでnofailオプションを使用できます（または関連する.mountファイルを直接定義できます）。しかし、これは私の問題を解決しません。システムをより弾力的にしたいです。毎回fstabを「パッチ」することはあまり便利ではなく、私のシステムに問題を引き起こす可能性がある他の可能な「問題」がどれだけあるのかわかりません。 system どこかの開発者はこれが十分に重要だと思うので始めることができません。
ある意味、私はシステムがブートプロセスを妨げるのに十分な深刻な問題を判断することなく、私のコンピュータのコントロールを再び取得したいと思います。可能ですか？
ベストアンサー1
文字通りインストールが失敗しただけで、変更が必要なすべてです。
したがって、あなたの要求の手紙に答えるのは簡単です。埋め込みファイルを作成します。
# /etc/systemd/system/local-fs.target.d/nofail.conf
# Clear OnFailure= (set it to nothing)
[Unit]
OnFailure=
私はこれがLinux sysvinitがすでに部分的な失敗条件を許可することによって経験している問題に新しい問題を追加しないと信じています。
ところで、あなたも方法を指摘しました。長いsystemdは、指定されたブロックデバイスが利用可能になるまで待つ必要があります。完全なfstabジェネレータを置き換えなくてもこれを設定する方法はありません。https://www.freedesktop.org/software/systemd/man/systemd.generator.html
広く使われていない大量のコードがここに捨てられると、システムの弾力性が向上しそうではありません。最も近い解決策は、既存のfstabジェネレータをパッチすることだと思います。それは複雑ではなく、あなたがそれを抜け出すか、主な変更に従うことができるかどうか疑われます。
技術的には、ディストリビューションにスタンドアロンのmountallsysvinitスクリプトがある場合は、それらをリンクしてみてください。ただし、これにより起動プロセスが大幅に変更されます。もっとフォークの。私はこのアプローチをお勧めしません。
https://unix.stackexchange.com/a/393711/29483
ユニットファイルを検索する場合は、
emergency.targetブートを.mount。local-fs.targetまたは、initramfsがsystemdを使用している場合initramfsがルートファイルシステムをマウントできない場合。
local-fs.target持っていますOnFailure=emergency.target。ローカルファイルシステムの単位がlocal-fs.targetのRequiresリストに自動的に追加されるため、失敗します（存在しない限りDefaultDependencies=no）。$ systemctl show --property Requires local-fs.target Requires=-.mount home.mount boot.mount boot-efi.mount