Linux Mint 18がシャットダウン時にハングする

10

悪名高いシャットダウンハング/フリーズエラーで困っています。mintをシャットダウンすると、スプラッシュスクリーンの最初のドットだけが緑色になり、その後フリーズします。Ubuntu 16.04にもこの問題がありました。ゲームにLinuxを使用するつもりです。これが私のシステム仕様です-

           Desktop: Cinnamon 3.0.7 (Gtk 3.18.9-1ubuntu3.1)
           Distro: Linux Mint 18 Sarah
Machine:   Mobo: Intel model: DG33FB v: AAD81072-307
           Bios: Intel v: DPP3510J.86A.0407.2008.0218.0923 date: 02/18/2008
CPU:       Quad core Intel Core2 Quad Q6600 (-MCP-) cache: 4096 KB
           flags: (lm nx sse sse2 sse3 ssse3 vmx) bmips: 19199
           clock speeds: max: 2394 MHz 1: 1596 MHz 2: 1596 MHz 3: 2128 MHz
           4: 1862 MHz
Graphics:  Card: NVIDIA GT218 [GeForce 210] bus-ID: 01:00.0
           Display Server: X.Org 1.18.4 drivers: nouveau (unloaded: fbdev,vesa)
           Resolution: 1024x768@60.00hz
           GLX Renderer: Gallium 0.4 on NVA8
           GLX Version: 3.0 Mesa 11.2.0 Direct Rendering: Yes
Audio:     Card-1 NVIDIA High Definition Audio Controller
           driver: snd_hda_intel bus-ID: 01:00.1
           Card-2 Intel 82801I (ICH9 Family) HD Audio Controller
           driver: snd_hda_intel bus-ID: 00:1b.0
           Sound: Advanced Linux Sound Architecture v: k4.4.0-21-generic
Network:   Card: Intel 82566DC-2 Gigabit Network Connection
           driver: e1000e v: 3.2.6-k port: 30e0 bus-ID: 00:19.0
           IF: enp0s25 state: up speed: 100 Mbps duplex: full mac: <filter>
Drives:    HDD Total Size: 160.0GB (4.9% used)
           ID-1: /dev/sda model: Hitachi_HDS72101 size: 160.0GB
Partition: ID-1: / size: 17G used: 5.4G (35%) fs: ext4 dev: /dev/sda5
           ID-2: swap-1 size: 2.13GB used: 0.00GB (0%) fs: swap dev: /dev/sda6
RAID:      No RAID devices: /proc/mdstat, md_mod kernel module present
Sensors:   System Temperatures: cpu: 47.0C mobo: N/A
           Fan Speeds (in rpm): cpu: N/A
Info:      Processes: 178 Uptime: 6 min Memory: 646.8/1990.4MB
           Init: systemd runlevel: 5 Gcc sys: 5.4.0
           Client: Shell (bash 4.3.421) inxi: 2.2.35

シャットダウンする前にネットワークをオフにしても違いはありません。リモートサーバーにアクセスできないことが原因ではありません。

再起動は正常に機能します。

journalctl --boot -1 -e --fullの結果

Specifying boot ID has no effect, no persistent journal was found

冗長ブートにはフェイルラインがあり、カーネルモジュールをロードできないことについて何か言っていました。

冗長シャットダウンの結果（最後の2行）：

[OK] Reached target shutdown.
[54.278173] reboot: power down

の結果 systemctl status

● lol-desktop
    State: degraded
     Jobs: 0 queued
   Failed: 1 units
    Since: Thu 2016-11-17 18:35:37 IST; 5min ago

PS私はWindows 7でそれをデュアルブートします。

linux-mint shutdown

— シボディット・ギル
ソース

を実行しjournalctl --boot -1 -e --full、質問を編集して、関連する出力をそこに配置します。これは、systemdがその時点で何をしていたかを人々に示します。

— JdeBP 2016年

編集が完了しました。

— Shivodit Gill 2016

みんな、返信してください、この問題は本当にイライラします

— Shivodit Gill

ジャーナルは、何が起こっていたかを人々に伝えるものです。「それは一種のフリーズです。」ではない。残念ながら、ジャーナルを永続的に/var/log/journalに保存するのではなく、シャットダウンするたびにジャーナルを破棄するようにシステムを設定しているため、ジャーナルに記録された内容を世界に伝えることができず、人々はその結果から（または可能性が高い）何が起こっているのかを診断できません違う。

— JdeBP

それで、どうやってそれを有効にするのですか？詳細なシャットダウンを行う必要がありますか？

— Shivodit Gill 2016

7

私は、Dell 5577ラップトップ（Nvidia 1050）上のLinux Mint 18.3システムで2日間戦った。シャットダウンまたは再起動時に画面が黒くなり、何も起こりませんでした。

以下のどれも役に立たなかった:(

grubの変更（GRUB_CMDLINE_LINUX = "apm = power_off"、 "acpi = force"などを追加）
EuPの無効化（スイッチがオフになっているコンピューターのUSBポートへの電力供給）

何が役に立ったか:)

メニュー->管理->ドライバー管理-> novideauの代わりにnvidiaドライバーを選択します。しばらく続くため、しばらくお待ちください。最初の再起動またはシャットダウンは失敗しますが、再起動後、最終的には正常に機能します。:)

検索：Linux Mintがシャットダウンまたは再起動しない、linux ubuntuがシャットダウンまたは再起動しない、linux mintがシャットダウンまたは再起動しない、linux ubuntuがシャットダウンまたは再起動しない

— ジャクブ
ソース

1

Dell XPS 15の場合もまったく同じです。残念ながら、Nvidiaドライバーは全画面ビデオを見るだけではファンを動かしきれず、実際には何も聞こえません。これは、PrimeがNvidiaまたはIntelグラフィックに設定されている場合に発生します。

— ニュートリノ

伝説、これはHP Zbook Studio G3で私のために働いた。

— Sean Missingham、2018年

Asus Zenbook Pro UX550で働いていました。トンありがとう!!

— ether_joe 2018

Nvidia NVS 5400Mを搭載したLenovo T430での超低速の再起動とシャットダウンは、nouveauではなくNvidiaドライバーを選択することで解決しました。ありがとう！

— Jaxian、

3

Gentoo linux（カーネル4.17.5）でこの問題を解決するために私のために働いたのは、以下のnouveauドライバーのオプションとして追加することでした：

vram_pushbuf=1

（nouveau.vram_pushbuf=1nouveauがカーネルに挿入されている場合）。

停止プロセスの最後のエラーメッセージからこれを発見しました。私のnvidia GPUでこのオプションを使用せずに完全にシャットダウンするための最後の手段としてビデオをシャットダウンしようとすると、システムがハングしました。

— ミケル
ソース

1

この問題は私にとっても現実的なものでした。最も興味深いのは、最初に手動でユーザーセッションを閉じてからシステムをシャットダウンしたとき、遅延なくすべてがスムーズに進んだことです。今日、私は問題を解決するために少し時間を費やし、そしてここにいくつかの結果があります。問題が発生するのは、システムがシャットダウン時に待機しているためです。まさにそれは個々のケースごとに個別です。私の場合、私が見つけた2つの問題でさえありました。システムは存在しないハードドライブを探していました。どうして？Linuxの他のバージョンをいくつか試し、すべてのバージョンで同じドライブデバイスをスワップとして選択したからです。2番目のLinuxのインストール中に、UUIDデバイスの変更されましたが、最初のLinuxのシステムファイルでは変更されませんでした。しかし、再び、それは私の問題でした、あなたの問題はまったく同じではないかもしれません。上記の問題を解決した後も、別の問題がありました。私は希望を失い、力ずくで問題を解決する誘惑に身を任せました。私は変更/etc/systemd/user.confして/etc/systemd/system.confパラメータをファイルDefaultTimeoutStopSecから90 secondsに5 seconds。行のコメントを解除することを忘れないでください（#パラメーターを使用して行の先頭の記号を削除するためDefaultTimeoutStopSec）。

これで問題なく動作し、システムは非常に速くシャットダウンします。

— ドンファン
ソース

1

別の考えられる解決策-特に（U）EFIを使用する新しいハードウェアの場合-は、ブートパラメーターを追加することapm=power_offです。GRUB_CMDLINE_LINUX_DEFAULTin の定義に/etc/default/grub追加したり、まだ存在しない場合は行を追加したりできます。

GRUB_CMDLINE_LINUX_DEFAULT="apm=power_off"

次に、オペレーティングシステムのマニュアルに従って、grubのインストールを更新します。例：

update-grub # Debian/Ubuntu
grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg # EFI on Fedora etc
grub2-mkconfig -o /boot/grub2/grub.cfg # BIOS

— セビックス
ソース

0

54秒後にシステムの電源がオフになると思いますか？プロセスがハングしている可能性があります。シャットダウン時に多くのディスクアクティビティがある場合は、ファイルの/ var / lib / systemd / coredump /をチェックして、コアダンプをオフにすることができます（ルートソリューションではなく回避策として）

— ニコラス
ソース

0

電源を切るUSB 3.0 legacy modeかusb3.0 configuration in pre-osでBIOSを、私のために働きました。

— ExillustX
ソース

0

Linux Mint 18.1：

私の問題は、新しいPCがシャットダウン/電源オフの非体系的な瞬間にハングしたことでした。オン/オフボタンを数秒間押す必要がありました（機械的な電源もオフになっています）。

UEFI / BIOSの設定を変更した後、問題はなくなりました。

UEFI / BIOSを開きます。
Advanced→Powermanagement→EuP-setting disabled
設定を保存して終了します

その後、コンピュータを再起動すると、すべてが正常に行われるはずです。

— グロウスター
ソース

1

EuP設定とは何ですか？

— Xen2050

0

私にとっては、grubのGRUB_CMDLINE_LINUX_DEFAULTパラメータから「静かな」値と「スプラッシュ」値を削除した後で、この問題は修正されました。

— モーテン
ソース