web-dev-qa-db-ja.com

Linuxカーネル4.9.0、Debian 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は論理的（resides-inside-extended）でした。

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ビットだと思いました）

debianlinux-kernelfstabinitramfshibernate
9
Enginecrafter77

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

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

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


私はまったく同じ問題を抱えていましたが、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とは関係ありません。

4
Andi

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

3
Jaleks

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

2
vcc

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

1
Lopi Dani

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

1
Alain

時々、問題は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と入力します。

0
David Kariuki

この返信の一般的な性質をお許しください。私はウェブ全体で同様の質問を見てきましたが、全員に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の後に挿入されるGRUB_CMDLINE_LINUX_DEFAULTが空白でない限り、"video=SVIDEO-1:d"は最後のLinuxコマンドライン引数にはなりません。実際にはどこでもかまいません。

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

[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
David McCracken