web-dev-qa-db-ja.com

Ubuntu 18.04は休止状態の後に再開できません

Ubuntu 17.04を使用していたとき、Hibernateは正しく機能しました。 17.10にアップグレードした後、再開後の黒い画面のため再開できませんでした( このバグ )。

18.04にアップグレードした後、休止状態の後にコンピューターを起動しようとすると、休止状態が完了していないかのように起動します。

17
Kamil

以前のLTS(16.04)と比較すると、デフォルト設定に変更が加えられています。私の場合、ハイバネーションはいくつかのステップを実行するまで機能しませんでした。その中で、スワップファイルのサイズを増やし、オンにし、ポリシーで許可されていることを確認しました。

これは簡単にStackExchange全体で最も長い答えかもしれないので、ヘッダーを説明的にしようとしました

冬眠のないブーツ

ログ(dmesgが役立つかもしれません)を見て、何かあるかどうかを確認するのが賢明でしょう。システムに休止状態を指示しても、実際には休止しないか、代わりにRAMにサスペンド(スリープ)する理由があります。

kern.logsyslogを見て、休止状態に関連するメッセージを探しても同様に害はありません。 「問題」で始まるセクションは、特定の問題に役立つ場合があります。

スワップファイルまたはスワップパーティション

重要な変更の1つは、スワップパーティションを持たないが、スワップファイルがあることです。

スワップファイルは、ハードウェア/ドライバー/ OSと休止状態の組み合わせでは機能しない場合があります。

ハイバネーションがオフになりました

また、ポリシーによって休止状態がオフになったり、禁止されたりする場合があります。

専門用語

RAMにサスペンド-RAMはデータを保持し、コンピューターはより速くスリープ状態になり、サスペンドされるとより多くのエネルギーを使用し、より早く起動します。これをスリープと呼ぶ人もいます。

ディスクへのサスペンド-別名休止状態。 RAMはスワップ(パーティションまたはファイル)に保存され、コンピューターのスリープ状態が遅くなり、休止中のエネルギー消費量が少なくなり、起動が遅くなります。

Suspend-to-RAM in Linux by Rafael J. Wysocki and A. Leonard Brown

前提条件-十分なスペースがありますか?

休止状態にするには、RAM全体をハードドライブに保存する必要があります(ここでは簡略化しています)。そのため、そのための十分なスペースを確保する必要があります。そうしないと、これは失敗し、休止状態になりません。

  1. free -mは、スワップのメモリ量、使用量、およびスワップ量を示します。
  2. df -hは、各マウントポイントにあるディスク容量と使用量、空き容量などを示します。これは、後でスワップファイルの場所やパーティションを指定する必要があるため重要です。スワップに十分なスペースを確保するために「トリム」します。
  3. cat fstabは、スワップパーティションまたはファイルがある場合に情報を提供する必要があります。 Ubuntu Hibernation FAQによると、swapfileは、ハードウェア/ドライバーのいくつかの組み合わせで常に動作するとは限りません。

十分なスペースがない場合は、 buntuスワップFAQ に従ってください。スワップファイルを増やす方法、別のファイルを追加する方法、使用されているかどうかを確認する方法などを説明しています。コマンドと説明を参照してください。本当に素敵なリソース。

RAMを入れるのに十分なスペースがありません!

カーネルドキュメントは言う:

/ sys/power/image_sizeは、ディスクへのサスペンドメカニズムによって作成されるイメージのサイズを制御します。画像サイズの上限として使用される非負整数を表す文字列をバイト単位で書き込むことができます。ディスクへのサスペンドメカニズムは、イメージサイズがその数を超えないように最善を尽くします。ただし、これが不可能であることが判明した場合、可能な限り最小のイメージを使用して一時停止しようとします。特に、このファイルに「0」が書き込まれる場合、一時停止イメージは可能な限り小さくなります。このファイルから読み取ると、現在の画像サイズ制限が表示されます。これは、デフォルトで使用可能なRAMの2/5に設定されています。

そのため、画像サイズを調整してみてください。方法-別の質問をお願いします。

前提条件-カーネルはディスクへのサスペンドをサポートしていますか?

カーネルは、/sys/power/stateにリストされているものをすべてサポートします。

cat /sys/power/state

許可される(私の知る限り)エントリには、memstandbyfreezediskが含まれます。説明:

  • mem-いくつかの意味があり、cat /sys/power/mem_sleepを介してシステム上で正確にわかります。私が持っている:s2idle [deep]
  • standby-パワーオンサスペンド(サポートされている場合)
  • freeze-アイドル状態へのサスペンド(STI)
  • disk-ディスクへのサスペンド(STD)、休止状態。これ-あなたが欲しい。

次に、cat /sys/power/diskを確認する必要があります。 disabledがある場合は、セキュアブートを探してBIOSに飛び込みます。これが私が提供できる唯一のアイデアであり、休止状態を妨げる可能性があるのは私が知っていることだけです。私はSecureBootしか知っていませんが、他の干渉があるかもしれませんので、「セキュアブート」がなくてもBIOSを確認することは良い考えです。

ここを読む:

  1. カーネルドキュメント
  2. 冬眠に関するDebian Wiki

TBH、カーネルが休止状態をサポートしていない場合でも、別の方法で試すことができます。セクションInterfacesまでスクロールします。

これを読む-警告と問題-BTRFSなし

順不同:

  1. すべてのチップセットが機能するわけではありません(ここで引用できるソースはありませんので、これは伝聞だとしましょう)
  2. VAIOには問題があります。おそらくそれらに対抗するためのフラグがあります
  3. SecureBootは、多くの場合、休止状態を妨害したり、休止状態にしたりするものとして引用されます
  4. Wake-on-LANは休止状態でも電力を消費します
  5. システムの休止状態から適切に再開する前に、モジュールの数(特にグラフィック)を初期化できます-これは通常、再開時の黒い画面の原因です。問題のデバッグ方法に関するヒントについては、ArchLinux Wikiをご覧ください。また、休止状態の問題に関するUbuntu FAQもお勧めします。 Launchpadのバグを閲覧しても結果が得られる場合があります。 IIRCには、再開までの遅延を秒単位で指定するカーネルパラメーターがあります。
  6. ハイバネーション手順の許可は、Polkitバージョンごとに異なります

BTRFSと休止状態を使用しないでください:破損したデータが結果になります。

休止状態にしたい-パーティションをスワップする

人々がスワップファイルを放棄し、スワップパーティションに戻る場合があります。結局、以前のLTSで機能しました。私は試していないので、ポインターを提供しません。

休止状態にしたい-スワップファイルで

  1. 十分なスペースがあることを確認してください。 buntuスワップFAQ は、必要な量を示します。上記のコマンドも同様です。ここで詳細が必要な場合は、別の質問をお願いします。これは長いトピックです。
  2. スワップファイルを増やすか、十分なサイズの新しいファイルを作成し(推奨、 @ mur に同意します)、/etc/fstabを新しいものに変更します。変更を確認するために再起動します(fstabのバックアップを保存するので、万が一の場合に簡単に元に戻すことができます)。
  3. 適切なパラメータを使用してカーネルにこれを向けると、どこから再開するかがわかります。
  4. ブートローダーを更新/再構成し、再起動します。

カーネルパラメーター?怖い!

注意深く読み、それを行うかどうかを決定しますが、これはカーネルを構成するための方法にすぎません。 systemdおよびuswsuspを使用して休止状態にする方が簡単な場合があります(以下のInterfacesを参照)。私と同じように、最終的にはRAMへのサスペンドで十分であり、スワップファイルに32GBを入れたくないと判断するかもしれません(たとえば、ラップトップにSSDを1つ搭載している人にはあまり適していません)。 しかし!

  1. スワップファイルの休止状態では、resume=がスワップファイルがどのパーティションにあるかを知る必要があり、resume_offset=がスワップファイルのどこから再開するかを知る必要があります。
  2. パーティションの休止状態では、スワップパーティションを指すためにresume=が必要です。
  3. ブラックスクリーンの問題を解決するには、resumedelay=が必要になる場合があります。

ハイバネーションからの再開の遅延に関するカーネルドキュメント:

resumedelay = [HIBERNATION]再開ファイルの読み取りを試みる前に一時停止する遅延(秒単位)

スワップファイルと休止状態に必要なパラメーター

履歴書= [SWSUSP]

      Specify the partition device for software suspend

      Format:

      {/dev/<dev> | PARTUUID=<uuid> | <int>:<int> | <hex>}

resume_offset = [SWSUSP]

      Specify the offset from the beginning of the partition
      given by "resume=" at which the swap header is located,
      in <PAGE_SIZE> units (needed only for swap files).

      See Documentation/power/swsusp-and-swap-files.txt

resume=については、root要素がfstabに持つものと同じスタイルを選択します。したがって、/dev/sdaXまたはUUIDまたはLVMのいずれかです。ファイルを冬眠する場合-ファイルが見つかるパーティションを提供します。

読書:

  1. https://www.kernel.org/doc/Documentation/admin-guide/kernel-parameters.txt
  2. https://wiki.archlinux.org/index.php/Kernel_parameters

問題-スワップヘッダーが見つかりません

スワップファイルは適切にフォーマットする必要があります。ログにこれが示されている場合は、ファイルへの休止状態を試みているか、再開パラメーターが正しくありません。

パーティションに切り替えるか、ファイルを修正するか、休止状態に使用するインターフェイスを変更します。

参照: https://unix.stackexchange.com/questions/43508/debian-hibernate-problem-pm-swap-header-not-found

mkswapはファイルのフォーマットに使用されます。詳細は こちら

問題!休止状態は許可されていません!

テスト:pm-hibernate(pm-utilsパッケージがインストールされている場合)またはsystemctl hibernateは、許可されていないことを通知します。 IIRC 12.04以降のUbuntuのデフォルト設定。

解決策:Polkitバージョン、Ubuntuバージョン、およびフレーバーに依存します... この質問 を参照してください。また、 PolkitのArchWiki が役立つ場合があります。

ミントについては、以下を参照してください: https://forums.linuxmint.com/viewtopic.php?t=259912

問題! BIOSの何かによってハイバネーションが無効になりました!

テスト:cat /sys/power/diskにはdisabledがあります。ログには、「logindを介したシステムの休止状態に失敗しました:スリープ動詞はサポートされていません」と表示されます。

解決策:BIOSを検索し、問題のあるものを見つけます。消して。

解決策2:別の休止状態のインターフェイスを試してください。

参照: 16.04.1で休止状態をアクティブにする方法?(systemd)

インターフェース

  1. swsusp-低レベルのカーネルインターフェイス。前提条件-どのファイルのカーネルを参照してください。ファイルに直接書き込むと、サスペンド(RAM、ディスク、ハイブリッド)が発生する場合があります。ファイルへの冬眠に問題があるSwapFAQによると。
  2. uswsusp- ArchWiki および Debian Wiki および AskUbuntuの質問と使用方法の説明付き
  3. systemd- ArchWiki on it
  4. pm-utils- スクリプトのコレクション 元々 Debian である-私は喜んで詳細情報を歓迎します。

閉会の辞

私にとっては、それをコンパイルするのにほぼ2日間の作業が必要でした。うまくいけば、これがあなた(および他の人)があなたの問題をより速く解決するのに役立つでしょう。まだ見逃した点はありますが、午前2時であり、これ以上書く気はありません。もちろん、私はこれを改善するために誰の指針にも心を開いていますので、コメントしてください。寝たら、仕事などで返信します:-)

ディスクへの冬眠がそんなにすばらしいとは思いません。最後に寝て行きました。しかし、私にとって問題は、ハイバネーションを実行できるようにするためだけに32GBファイルを使用することでした。最初のスワップファイルは2GBで、ほとんどが空でした。 YMMV。それにもかかわらず、幸運を! そしてログから始めましょう!

resume=UUID=<#>/etc/default/grubの両方のRESUMEパラメーター/etc/initramfs-tools/conf.d/resumeでマウントポイントの代わりにスワップパーティションのUUIDを使用します

/etc/fstabにスワップパーティションのエントリを作成しますマウントポイントなしこのようなもの

# Entry for Swap : 
UUID=# none  swap    sw              0       0

/etc/default/grubで、休止状態を再開するために別のエントリを使用しました

# FOR HIBERNATION 
GRUB_CMDLINE_LINUX="resume=UUID=..."

ローカル機関(pkla)でポリシーキットを作成する

Sudo gedit /etc/polkit-1/localauthority/50-local.d/com.ubuntu.enable-hibernate.pkla

そこに挿入します

[Re-enable hibernate by default in upower]
Identity=unix-user:*
Action=org.freedesktop.upower.hibernate
ResultActive=yes

[Re-enable hibernate by default in logind]
Identity=unix-user:*
Action=org.freedesktop.login1.hibernate;org.freedesktop.login1.handle-hibernate-key;org.freedesktop.login1;org.freedesktop.login1.hibernate-multiple-sessions;org.freedesktop.login1.hibernate-ignore-inhibit
ResultActive=yes

[Enable hibernate to be run via cron]
Identity=unix-user:*
Action=org.freedesktop.login1.hibernate;org.freedesktop.login1.hibernate-multiple-sessions
ResultAny=yes

その後、initramfsとGRUBを更新します

Sudo update-initramfs -u -k all
Sudo update-grub

再起動し、いくつかのアプリを開き、systemctl hibernate(Sudoなし)を使用して、動作するかどうかを確認します

7
Roey

私にとっては、18.04までは常に機能し、18.04以降は多くの記事でそのまま有効にしましたが、昨日突然機能しなくなりました(4〜5か月間正常に機能しました)。

そしてここにある...それが再び機能するようになったもの...

スワップパーティションの場所をgrub2に伝えます。

まず、以下のコマンドを使用して、どのパーティションにあるかを調べます。

cat /etc/fstab

私のものはsda7にあり、次の出力があります:

インストール中にスワップが/ dev/sda7にあった

次に、次のコマンドを使用して、Grub2で次の行に次の追加を追加します。

Sudo gedit/etc/default/grub

GRUB_CMDLINE_LINUX_DEFAULT = "intel_pstate = disable resume =/dev/sda7"

重要な部分はresume=/dev/sda7です

私の場合、/ dev/sda7

次に、Grubを次のコマンドで更新します。その後、再び完全に機能し始めました。

Sudo update-grub

多くの試みの後、これがうまくいったことの1つでした。たぶんそれは、カーネルの更新が失敗しただけのせいかもしれません。

これが誰かを助けることを願っていますが、私はpopos/ubuntu 19.04を実行しています。私のセットアップでは、s2diskまたはpm-hibernateを使用して休止状態にすることができましたが、再開は失敗しました。これを修正するには、grubではなくUEFIを使用してシステムを起動します。ブートローダーを再インストールする必要がありました。 UEFIを実行しているかどうかを確認するには、次を使用します。

[ -d /sys/firmware/efi ] && echo "Installed in UEFI mode" || echo "Installed in Legacy mode"

uEFIモードの場合、このガイドに従ってブートローダーを再インストールしますが、nvmeディスクまたはsataディスクを使用している場合は異なります。 https://support.system76.com/articles/bootloader/

kernalbootオプションで、再開するパーティションのパーティションまたはUUIDを指定していることを確認してください。たとえば、次のようなものです。

resume = UUID = ed8347ed-2eb4-40bc-bc77-cc53b987ed88

これは、次のいずれかで追加できます。1)Sudo kernel-stub -a "resume = UUID = ..." 2)/etc/initramfs-tools/conf.d/resumeファイルを編集して、次を追加します。resume= UUID = ed8347ed- 2eb4-40bc-bc77-cc53b987ed88

/ var/log/syslogファイルで次のようなものを確認してください:Aug 4 22:26:42 pop-os/usr/bin/kernelstub [19639]:kernelstub:DEBUG kopts:root = UUID = b37019a8-91f5-445f-94c1 -7359a49ed5df ro quiet loglevel = 0 systemd .show_status = false resume = UUID = ed8347ed-2eb4-40bc-bc77-cc53b987ed88

履歴書が見つからないか間違っている場合は、ブートカーネルを再度更新する必要があります。

0
Lingster

Sam73の answerに記載されているgrubでスワップ再開ポイントを設定することとは別に、Ubuntu 18.04もlaptop-mode-toolsをインストールする必要があることがわかりました。 :

$Sudo apt install laptop-mode-tools

次に、構成ファイルのENABLE_LAPTOP_MODE_ON_AC=1を変更します。

$Sudo vim /etc/laptop-mode/laptop-mode.conf

ラップトップモードを開始するには:

$Sudo laptop_mode start

追伸ラップトップが起動するかどうかを確認できます

$cat /proc/sys/vm/laptop_mode

0を出力する場合、laptop_modeは機能していません。それ以外の場合は、正常に機能していることを示します。

0
Yossarian42