Linuxカーネル4.9.0、Debian 9で休止状態の再開が失敗する


9

最近、カーネルを3.16.4(Debian jessie)から4.9.0(Debian Stretch)にアップグレードしました。「ハイバネート」(ディスクにサスペンド)するまで、すべてが順調でした。

LXDEでHibernateオプションを使用すると、休止状態のように見えます。ディスクのスピンドルがカチカチとデータを書き込んでいるのが聞こえます。しかし、休止状態から再開するときに問題が発生します。カーネルはスワップからイメージを正常に復元しますが、フリーズして再起動し、すべての作業が失われます。インターネットのどこにも答えが見つかりませんでした。人々は/etc/initramfs-tools/conf.d/resumeを設定しない、またはカーネルパラメータを設定していない、または/ etc / fstabに間違ったエントリがあることに関するいくつかの間違いを解決しています。これらは正しいです。/etc/initramfs-tools/conf.d/resume内のUUIDを修正し、fstabを修正し、再開カーネルパラメータを設定しない。

  • スワップパーティションを拡張パーティションの外のプライマリに移動しました。UUIDが保存され、新しいスワップに適用されました。

  • システムは「イメージの復元100%」に達し、次に「コンソールの一時停止」に達した後、すべての作業が失われた状態で電源がオフになり、通常どおりに起動します。

  • クリーンインストールを試みましたが、運がありませんでした。

  • i386(32ビットx86)でのみ発生し、amd64(64ビットx86)は影響を受けません。

ディスクパーティションテーブルのレイアウト:

NAME   FSTYPE LABEL    UUID                                 MOUNTPOINT
sda                                                         
├─sda1 ext4   HDD      <ROOT-UUID> /
└─sda2 swap   HDD-SWAP <SW-UUID> [SWAP]
sr0

アップグレード前は、sda2は論理的(内部拡張)でした。

Fstab:

UUID=<ROOT-UUID> / ext4 errors=remount-ro 0 1
UUID=<SW-UUID> none swap sw 0 0

/etc/initramfs-tools/conf.d/resume

RESUME=UUID=<SW-UUID>

カーネルコマンドライン

BOOT_IMAGE=/boot/vmlinuz-4.9.0-3-686-pae root=UUID=<ROOT-UUID> ro quiet

システムインフォメーション:

Computer: Compaq CQ60-120ec
Swap Size: 3.5GiB
Processor: AMD Athlon X2 64 QL-66
GPU: Nvidia Geforce 8200M G
Memory: 2G DDR2 667MHz
Desktop Environment: LXDE
Debian Version: 9 (stretch)
Kernel version: 4.9.0-3
Graphics Driver: nvidia legacy 304xxx

(私はプロセッサが64ビットであることを知っていますが、元々は32ビットOSが付属していたため、/ proc / cpuinfoを調べるまでは32ビットだと思いました)

回答:


4

この問題は、x86-32でのhibernateとkASLRの競合原因です。これは、nokaslrカーネルブートオプションでkASLRを無効にすることで解決できます。x86-64は影響を受けません。

Grubの場合、これは/ etc / default / grubを編集し、ブートオプションにnokaslrを追加することで実行できます。例:GRUB_CMDLINE_LINUX_DEFAULT = "quiet nokaslr "

次に、update-grubを実行して構成を更新し、再起動して試してください。


私はまったく同じ問題を抱えていましたが、PAEカーネルのみがその問題の影響を受けているようです。PAEなしの同じカーネルは問題なく動作します。

私の回避策は、linux-image-686をインストールし、linux-image-686-paeとlinux-image-4.9.0-4-686-paeをアンインストールすることでした。正確なカーネルバージョンは、アップグレードのために時間とともに変化する可能性がありますが、基本的に、現在実行中のPAEカーネルは、PAEなしのカーネルに置き換える必要があります。

私のCPUは/ proc / cpuinfoに従ってPAEをサポートしているため、実際にはCPUのPAEサポートとは関係ありません。しかし、PAEはとにかく古いノートブックではあまり役に立ちません。

同じ問題がDebianバックポートのカーネル4.13 PAEでも発生するため、カーネル4.9 PAEとは何の関係もありません。


この優れた答えははるかに多くの価値がありますが、私は1つだけを与えることができます。
peterh-モニカを2017年

はい、このサイトはエキスパートではないと思いました。(Un)幸いにも、amd64バージョンは問題なく動作することがわかったので、686バージョンを維持するために停止したと思いましたが、PAEがない686バージョンがあることを知りませんでした。私はdebianがそれを修正することを望みます、そうでなければ人々は不満を言うでしょう。
Enginecrafter77 2017

3

おそらく/etc/uswsusp.conf「再開デバイス」の変更されたエントリ/etcが必要です。これが使用されない場合、myabeはすべてのファイルの古いUUIDをgrepして、変更が必要な場所を見つけようとします。またupdate-initramfs必要だろうと私は言うでしょう。


これはuswsuspをインストールしてファイルが正しいかどうかを確認するのに役立ちましたが、うまくいきませんでした。また、/ etc内の構成ファイルに古いUUIDが含まれていません。
Enginecrafter77 2017

2

同じエラーが発生しました。最新のnetinst isoで再インストールする。つまり、debian-9.1.0-amd64-netinst.isoがそれを整理した。バグは修正されたようです(少なくともこのアーキテクチャでは)。


はい、同意します。amd64(つまりx64)で修正されていますが、バグはi386(エイリアス686またはx86)にも残っています
Enginecrafter77

1

uswsuspを削除すると、休止状態が再び魅力のように機能します。ところで、私がnvidiaドライバーを使用していたときは、ジェシーの前にすでにそうだったと思います。私はuswsuspを使用してテストし、休止状態を機能させるためにそれを削除する必要がありました。


テスト用の32ビットコンピューターにuswsuspをインストールしていませんが、それでも休止状態が機能しません。
Enginecrafter77

残念な。nvidiaドライバーを削除してnouveauを使用してみましたか?
2017

はい、完全にクリーンなDebian 9インストール(32ビット)を試しましたが、問題はまだ残っています。インテルグラフィックスを搭載したコンピューターでも発生するため、GPUとは関係がないと思います。
Enginecrafter77 2017

1

スワップパーティションがあり(サイズが正しい)、 "/ etc / initramfs-tools / conf.d / resume"を編集して "#blkid"の結果を得ると、i386は正しく休止状態にならず、Debians i386 4.9のバグです。カーネル!カーネルを4.9以上のバージョンに更新するか、3.16カーネルにロールバックします。


0

この返信の一般的な性質をお許しください。私はウェブ全体で同様の質問を見てきましたが、全員に1つの回答を書くことにしました。Hp2510でDebian-Jessieをアップグレードするのと同じ問題が発生しました。私はUbuntu-desktopに切り替えて、そこにもそれを見つけました。その後、UbuntuとHp2510でテストを行ったので、状況に完全に適用されない可能性があります。

新しいLinuxシステムで更新された一部の古いコンピューターでは、起動の問題が発生します。まったく起動しない場合や、起動に3分ほどかかる場合があります。偶然にも、休止状態に失敗するか、休止状態と休止状態になるまでに時間がかかり、機能が役に立たなくなります。多くの場合、これは古いコンピュータの速度が遅いためではなく、4.8 Linuxカーネルに導入された変更が原因で、svideo出力を含む非常に一般的なIntelチップセットで問題が発生します。このカーネル以降、このチップセットを搭載したコンピューターでは、Linuxコマンドライン引数を使用しない限り、起動の問題が発生します"video=SVIDEO-1:d"GRUB_CMDLINE_LINUXに含まれています。これにより、64ビットと32ビットの両方の起動時間が大幅に短縮されますが、休止状態の問題は64ビットでのみ修正されます。この時点以降、32ビットシステムは休止状態をサポートしません。さらに、すべての4.8および4.9カーネルバージョンのブート時間は不適切です(4.8.rc1-7を除く)。これは、4.10で最終的に解決されます。カーネル4.8と4.9は避けるべきです(とにかく時代遅れです)。

最速の起動時間が必要な場合は、4.8より前のカーネルを使用してください。カーネルを4.7.10に更新したUbuntu-desktop 15.04を使用します。これは、32システムで休止状態を取得する唯一の方法です。64ビットシステムの起動は32ビットシステムより7%遅くなりますが、それでもそれ以降のどのバージョンよりも高速です。現在サポートされている32ビットシステムが必要で、休止状態を見逃したい場合は、4.10以降のカーネルにリリースまたは更新されているカーネルを使用してください。すべての64ビットバージョンは4.8以降のビデオ修正で機能しますが、最高のパフォーマンスを得るには4.8および4.9を避けてください。

ビデオ修正を追加するには、を実行しますsudo nano /etc/default/grub。nanoを閉じた後sudo update-grub。GRUB_CMDLINE_LINUX_DEFAULT(GRUB_CMDLINE_LINUXの後に挿入されている)が空白でない限り、"video=SVIDEO-1:d"一部の人々が必要とする最後のLinuxコマンドライン引数にはなりません。実際にはどこでもかまいません。

ターミナル(またはtty)でpm-hibernateコマンドを使用していつでもhibernateを呼び出すことができますが/etc/polkit-1/localauthority/50-local.d/ com.ubuntu.enable-hibernate.pkla、次のテキストを作成またはポリシーファイル(明らかにディストリビューション固有)に追加する必要があるGUIオプションを使用するには、

[Re-enable hibernate by default for login1]
    Identity=unix-user:*
    Action=org.freedesktop.login1.hibernate
    ResultActive=yes
[Re-enable hibernate for multiple users by default in logind]
    Identity=unix-user:*
    Action=org.freedesktop.login1.hibernate-multiple-sessions
    ResultActive=yes

0

時々問題はgrubまたはUUIDにありません。これは、ストレージスペースが不足している場合にも発生します。書き込みスペースがなくなるため、休止状態から再開するとフリーズします。

そのエラーが発生したら、alt+ f2/f3/f7またはctrl+alt+ f2/f3/f7をクリックしてターミナルを開きます。ターミナルを使用してアカウントまたはrootにログインします。

次に、コマンドsudo df -hを実行してストレージ容量を確認します。私の場合、空き容量がなかった/dev/sda1ので、リストのドライブの空き容量を確認します。

スペースが足りない場合は、いくつかのファイルを削除して、かなりのスペースを確保してください。

その後、alt+f1またはctrl+alt+f1をクリックして、ログインGUIが表示されるか入力するのを待ちますreboot in the terminal to reboot


まあ、あなたの試みに感謝しますが、この問題はすでに解決されています。問題は4.9.0 i386 + PAEカーネルにあります。後でPCが64ビットソフトウェアを実行できることを発見しました(ただし、PCは入手した日から常に32ビットで実行されていました)、64ビットカーネルが問題を解決しました。
Enginecrafter77

いいよ歓迎します。
David Kariuki
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.