web-dev-qa-db-ja.com

「緊急モードへようこそ!」 fsckの問題だと思う

enter image description here

journalctl -xbスニペット(私が間違っていると思うこと、少なくとも赤でした):

-- Unit systemd-fsckd.service has begun starting up.
juli 09 15:40:16 kim-SSD-Sationary systemd-fsck[414]: /dev/sdb1 contains a file system with errors, check forced.
juli 09 15:40:16 kim-SSD-Sationary systemd-fsck[414]: /dev/sdb1: Inodes that were part of a corrupted Orphan linked list found.
juli 09 15:40:16 kim-SSD-Sationary systemd-fsck[414]: /dev/sdb1: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
juli 09 15:40:16 kim-SSD-Sationary systemd-fsck[414]: (i.e., without -a or -p options)
juli 09 15:40:16 kim-SSD-Sationary systemd-fsck[414]: fsck failed with error code 4.
juli 09 15:40:16 kim-SSD-Sationary systemd-fsck[414]: Running request emergency.target/start/replace
juli 09 15:40:16 kim-SSD-Sationary systemd[1]: systemd-fsck-root.service: main process exited, code=exited, status=1/FAILURE
juli 09 15:40:16 kim-SSD-Sationary systemd[1]: Failed to start File System Check on Root Device.
-- Subject: Unit systemd-fsck-root.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit systemd-fsck-root.service has failed.
-- 
-- The result is failed.
juli 09 15:40:16 kim-SSD-Sationary systemd[1]: Unit systemd-fsck-root.service entered failed state.
juli 09 15:40:16 kim-SSD-Sationary systemd[1]: systemd-fsck-root.service failed.
juli 09 15:40:16 kim-SSD-Sationary systemd[1]: Starting Remount Root and Kernel File Systems...
-- Subject: Unit systemd-remount-fs.service has begun start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel

ACPI PCCプローブが失敗したなどのその他のエラーを無視しました。

編集:を押してPCにアクセスできます Ctrl+D 、しかし迷惑です。

70
Kim André

Ubuntu Liveからfsckを実行できます。

  1. コンピューターの電源を入れます。 Ubuntu Live DVD/USBを起動します(インストールせずに試してください)。
  2. ロードした後、を押してターミナルを開きます Ctrl+Alt+T
  3. ターミナルで、次を実行します。

    Sudo -i
    fdisk -l
    

    fdiskは、パーティション/(ルート)の名前を通知します。この質問では、/dev/sdb1です。

    次に、次を実行して続行する必要があります。

    umount /dev/sdb1
    fsck -y /dev/sdb1
    poweroff
    

    umountコマンドがsdb1が「マウントされていない」と文句を言う場合、それは問題ではありません。 「マウントされていない」ことを望んでいました:)。

  4. DVD/USBを取り出します。 SSDから起動するには、コンピューターの電源を再度入れます。

50
kyodake

あなたが問題を解決したかどうかわかりません。私がしたことは:

Sudo nano /etc/fstab

次に、sdb1に追加したものを削除してから実行します。

Sudo systemctl reboot

破損していると言われているので、それについてはわかりませんが、Linuxを実行できない人の助けになることを願っています。

35
Akuma

緊急モードの場合がありました。私の状況では、/etc/fstabのマウントポイントのオプションのいくつかを編集することを提案するインストールチュートリアルに従いました。余分なオプションを削除すると、サーバーは問題なく再起動しました。

26
Steffen Nielsen

Windows 10とUbuntu 16.Xのデュアルブートシステムを使用しています。

NTFSパーティションの1つをマウントできず、エラーはWindowsのシャットダウン/休止状態に関連していました。 Sudo ntfsfix /dev/sda3を使用して問題を修正しました。 NTFSパーティションsda3をマウントできましたが、再起動時にUbuntuは緊急モードで起動していました。
この問題を修正するには、Windowsで次のコマンドを実行します

shutdown /s /t 5

これにより、Ubuntu緊急起動の問題が修正されます。

16
Khushboo Rani

Khushboo Rani および Cagan Arslan による回答は、私を永続的な解決策に導きました。

Windows 10には fast boot と呼ばれる機能がデフォルトで有効になっており、ユーザーがコンピューターの「シャットダウン」ボタンまたは電源ボタンを使用して通常シャットダウンすると、実行中のカーネルと他のいくつかを実際に保存しますログオフ後の休止状態に類似したハードドライブへのシステムスタッフ。また、偶発的または悪意のあるデータの破損を防ぐために、Windowsが何らかの方法でパーティションを「ロック」します。これは、Ubuntuが起動時にWindowsパーティションをマウントできないことを意味します。

私の場合、/ etc/fstabにWindowsパーティションのエントリがあるため、Ubuntuが起動できなくなりました。

解決策は、Windowsを起動し、「高速起動」を無効にしてから、正常にシャットダウンすることです。これで問題は永久に解決されるはずです!

前に共有したリンクから、Windowsで次のように高速ブートを無効にします。

  1. コントロールパネルを起動します
  2. 「ハードウェアとサウンド」設定に移動します
  3. 「電源オプション」に移動します
  4. 「電源ボタンの機能を選択する」をクリックします
  5. [現在利用できない設定を変更する]をクリックして、UACアクセスを許可します。
  6. [高速起動を有効にする(推奨)]設定のチェックボックスをオフにします
13
Ben

私の場合(デュアルブートWindows 10)、次のコマンドでWindowsを適切にシャットダウンする必要がありました(Windowsで):

shutdown /s /t 5

再起動すると、Ubuntuは問題なくロードされます。

5
Cagan Arslan

これがVirtualBox VMで発生する場合、/etc/fstabのいずれかのパーティションのマウントに失敗している可能性があります。残念ながら、「緊急モードへようこそ!」で失敗します。クリティカルパーティションではない場合でも-vboxsfを使用してファイルシステムをマウントしようとする不正なエントリを追加した場合、システム全体がブートに失敗し、これがメインであることが明確になりません問題。

とにかく問題を解決するには、/etc/fstabの問題のあるエントリをコメントアウトするか、mountが満足するように修正する必要があります。

2
Pierz

USBフラッシュドライブからUbuntu LTS 16.04を起動すると、まったく同じ問題が発生しました。 sysctl defaultを実行しても修正されませんでした。fsckはスキャンの進行状況メッセージですぐに点滅し、その後同じプロンプトが表示されます。これがうまくいったものです:

fsck -y /dev/sda1
reboot
2
Jimmy Falcon

他のいくつかの答えと同様に、私にとっての秘theは、オプションのLVMパーティションの/etc/fstabのエントリをコメントアウトすることでした。数日前にUbuntu 17.10がLVMパーティションを見つけられなくなったと不平を言い始めた理由も、これがシステムを「緊急」モードで起動させたのか、私にはわかりません。

エントリが/etc/fstabでコメントアウトされると、デスクトップを正常に再起動しました。いくつかのチュートリアルを見ると、いくつかのLVMコマンドが欠落していることに気づいたので、Sudo apt-get install lvm2を実行して問題を修正したようです。

私のように、LVMパーティションが問題の原因だと思うなら、私が実行したコマンドの完全なセットは次のとおりでした。

Sudo lvmdiskscan
Sudo apt-get install lvm2
Sudo lvmdiskscan
Sudo lvdisplay
Sudo vi /etc/fstab
Sudo vgchange -a y
Sudo mount -a

これらすべてが必要かどうかわからない-apt-get install lvm2がシステムを再起動するための鍵だったと思う。

1
Stéphane

したがって、ここには多くの良い答えがあります-情報に追加するだけで、私の問題は、サーバーを保護するために/ etc/fstabに追加した行でtmpfsをtempfsとして間違っている

0
user3728501

同じ問題がありました。/etc/fstabから手動で追加されたntfsパーティションをコメント化しましたシステムは正常に起動しました。 ntfsfixコマンドを使用して、これらのntfsパーティションに起因するジャーナリングの問題を修正します。例:Sudo ntfsfix/Dev/ntfsパーティション/ etc/fstab Rebootに再マウント

0
Binoy

私はちょうど同じ問題を抱えていたので、私の場合は、grubパーティションを再作成したばかりだったため、最後のgrubパーティションとは異なるUUIDがありました。 ubuntuを起動したとき、システムはUUIDを確認できません。この問題を解決するために、私はやった:

Sudo nano /etc/fstab

次に、変更したばかりのパーティションからUUIDを含む行をコメント化します。

次にrebootを押して変更を適用します。

0
Gabriel Ziegler

コマンドfsckを実行した後、同じ問題が発生しましたが、しばらくしてからコンピューターが再び緊急モードになったため、ハードディスクからデータ全体を削除し、新しいOSをインストールしました。それは私の問題を解決しました。 Ubuntu 15.0の鮮やかなバージョンに問題があったので、14.0バージョンをインストールしたと思います。それでもまだ問題はありません。

0