ステップEXECの/ bin / plymouthの生成に失敗しました（Debianテスト）

16

dist-upgradeDebianテスト（Jessie）インスタンスでを実行した後、起動できなくなりました。私はコマンドプロンプトに失望しています：

Welcome to emergency mode! After logging in, type "journalctl -xb" to view system logs

次のエラーが表示されます。

root@debian:~# journalctl -xb
debian systemd[222]: Failed at step EXEC spawning /bin/plymouth: No such file or directory

驚いたことに、Googleは支援しておらず、私が目にする小さなスレッドはArch用であり（検索に+ debianを追加しても）、私には意味がありません。

これから回復する方法についてのポインタはありますか？

# uname -a
Linux debian 3.16.0-4-amd64 #1 SMP Debian 3.16.7-2 (2014-11-06) x84_64 GNU/Linux

debian upgrade plymouth

— あなたの
ソース

おそらく、これはJessie / stableなどでSystemD以来「確認」されているため、見出しからテストを削除するために変更する必要があります。（

— Hvisage

20

また、今日、debian wheezyからjessieへのアップグレードの結果として、この正確なエラーが発生しました。

「apt-get dist-upgrade」からのエラーがないにもかかわらず、システムは再起動に失敗しました。「journalctl -xb」（または「-xd」）を介した最終的なエラー出力は、「plymouth」（聞いたこともないアプリケーション）に関連付けられていました。しかし、リブートに失敗するとプリマスとは関係なく、むしろ/ etc / fstabの下にある補助エントリの下の小さな異常：cdromデバイスの「auto」を「noauto」に変更します（NFSとは関係ありません） systemdは起動を許可します。これはwheezyの下で機能するfstab行であり、ジェシーの下で再起動を許可するために静かに失敗します。

fstabに関連付けられたjournalctlを介したエラーはありませんでした。このあいまいなソリューションに私を導いたのは幸運なウェブ検索でした。

— テオフラストス
ソース

4

正しい。プリマスエラーが目を引き、実際の原因を見落としていました。

— youri

はい、で私の場合、それはすでにました絶対にちょうどことにsystemd <追加-フランス語-選択ワード> ... NOAUTOが、「余分な追加されたディスクの原因「が」ありませんでしたファイルシステムだったの実装を吸うためにファイルシステム...それは実際にあるべきバグにsystemdに対してレポート...しかし、マウントファイルシステムについての以前の経験からLPを知って、それは無視されます。将来的にはsystemdに関連するトラブルの解決に（すべてのベスト

— Hvisage

fstabの行をコメントアウトする代わりにnofail、すべての重要ではないファイルシステムのオプションを追加します。このオプションは、マウント中にエラーを無視し、通常のブートプロセスを続行するようにsystemdに指示します。

— Marki555

11

前の回答を組み合わせると、この問題は/ etc / fstabの無効なエントリが原因であるように見えます。

私の場合、virtualbox内で実行しており、問題の原因は起動時に自動マウントするように設定した共有フォルダーでした。他の2つの答えでは、問題はNFSまたはCD-ROMデバイスの設定でした。

トラブルシューティングを行うには、/ etc / fstabにある重要でない行をすべてコメントアウトしてから、問題を再現するまで1行ずつ追加し直すことをお勧めします。

その後、問題のある行を診断して修正できます。distのアップグレード中に、Vbox共有フォルダー、ネットワーク共有、またはその他の特殊なファイルシステムなどが正しくアップグレードされなかった可能性があります。

— クリス・ノルダス
ソース

はい！！！！！他の回答の私のコメントを参照

— Hvisage

3

今日は正確なエラーがありました。

プリマスをインストールしましたが、結果は変わりませんでした。

これは、/ etc / fstabの誤ったnfsエントリが原因でした。そのエントリを削除すると、エラーは消えました。この恐ろしい動作は、愚かなsystemdによるものだと思います。

— 缶カヴァクリオル
ソース

2

fstabの問題であることを確認します。fstabの内部に移動して、最後に作成した行を削除すると、すべてが以前のようになり、システムが起動します。VirtualBox 5 / debian 8での共有に自動マウントの問題があります。Virtualbox4 / debian 7では問題ありません。

— レイロン
ソース

0

この時点でこれはかなり古いスレッドであることがわかります...しかし、私は今日この問題も経験しました。

/etc/fstabシステムが「緊急モード」で起動しないように、この行をコメントアウトする必要がありました。

#UUID=0x0000x0-0x00-0000-xx00-0000xxx00000 /boot           ext2    defaults        0       2
/dev/mapper/Ubuntu16043LTSVM--vg-swap_1 none            swap    sw              0       0

*（UUIDは意図的に難読化されています）

更新：

この問題のUUID行に/etc/fstab問題があるようです。奇数。このスレッドでこの問題に関する詳細を読んだ後、根本的な原因に関する決定的な答えにはまだ近づきませんでしたが、少なくともSWAPは現在構成されています。

誰もがこの問題を完全に解決できましたか？または根本原因を見つけますか？

— カニドライブ
ソース