web-dev-qa-db-ja.com

Xubuntu 16.04は起動しません。 fsckの後にハングする

Xubuntu 16.04LTSをWindows 7とのデュアルブートとしてDell Inspiron Miniにインストールしました。

昨日初めて起動したとき、うまくいきました。しかし、今日、私は以下を見ます:

/dev/sda5: recovering journal
/dev/sda5: clean, 174140/6045696 files, 1444115/24179712 blocks

16.04 ltsの起動時の問題?すべての起動時にUbuntuがfsckを実行している 、および 起動後にLinuxがハングアップする)など、他の複数の質問を参考にしました。 fsck 。これは、fsckがすべてのブートで実行されているか、ドライバーが不足していることを示していますが、どれもまったく同じ問題ではありませんでした。

ただし、fsckに関する問題では、単に刺激的な遅延があります。ここでは、私が知る限り、この画面に無期限に固定されています。私は今かなり長い間待っていましたが、変化はありませんでした。

可能な解決策はありますか?ありがとう。

3
Jonathan Lam

GRUBブートローダーにアクセスするには、Right-Shiftを押します。詳細オプションに移動し、回復モードを開始します。リカバリモードメニューが開いたら、通常の起動を続行することを選択します。 ログインする場合ターミナルを開いてSudo nano /etc/default/grubと入力します

これは私がやったことです。

  1. "splash quiet"パートを"nomodeset radeon.modeset=0 systemd.recover_state=0"に変更しました。nomodesetが正しい場合は、Intelまたはnvidiaカードを扱い、ATIでも動作します。私は古いATIカードを持っているので、radeon.modeset=0は正しいように見えましたが、確かにこれらのカードで遊んでいませんでした。

  2. ctrl+oを押してnanoにファイルを保存し、ctrl+xを終了します

  3. ターミナルに戻ってSudo update-grubを再度実行します

Sudo rebootで通常の再起動を試み、システムが正常に起動するかどうかを確認してください。

追伸だから多分問題はディスプレイドライバにありますか??

3
xSamle

ArchLinuxフォーラムでこのソリューションを見つけた後、ついにLubuntuでブートするようになりました(しかし、Xubuntuを使用することになりそうです)。

(どちらのテキストエディターでも、picoを使用しました)を使用して、カーネルブートパラメーターを編集します。

Sudo pico /etc/default/grub

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"と書かれている箇所

systemd.restore_state=0を追加すると、次のようになります。

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash systemd.restore_state=0"

私のソースは https://bbs.archlinux.org/viewtopic.php?id=201523&p=2

および https://bugzilla.redhat.com/show_bug.cgi?id=125352

archlinux wikiで「バックライト」に関するこれに関連するドキュメントを見つけました。十分な担当者がいないため、リンクできません:(リンクは2つまでしかリンクできません。

*編集:多分十分な担当者がいますか?だからこれは私が情報を見た場所です: https://bbs.archlinux.org/viewtopic.php?id=201523&p=2

そして

https://bugzilla.redhat.com/show_bug.cgi?id=125352

これがあなたのために働くことを願って、それを理解するのに1ヶ月かかりました!

どうやら長い話:起動時に、システムはキーボードのバックライトを制御しようとしていますが、このラップトップにはありません。したがって、ライトをオンまたはオフにして起動するかどうかの存在しないブートアップパラメーターをチェックすることはできません。

1
Aaron Chen

同じ問題がありました。カーネルパラメーターを設定するloglevel=7フリーズは、「ジャーナルを永続ストレージにフラッシュする」操作が原因で終了しないことがわかりました。フォルダ/var/log/journal全体を削除することを解決しました。私はこれが正しい解決策ではないと信じていますが、それは私のために働いた唯一のものです。

0
RobotMan