Ubuntu 17.04を使用していたとき、Hibernateは正しく機能しました。 17.10にアップグレードした後、再開後の黒い画面のため再開できませんでした( このバグ )。
18.04にアップグレードした後、休止状態の後にコンピューターを起動しようとすると、休止状態が完了していないかのように起動します。
以前のLTS(16.04)と比較すると、デフォルト設定に変更が加えられています。私の場合、ハイバネーションはいくつかのステップを実行するまで機能しませんでした。その中で、スワップファイルのサイズを増やし、オンにし、ポリシーで許可されていることを確認しました。
これは簡単にStackExchange全体で最も長い答えかもしれないので、ヘッダーを説明的にしようとしました。
ログ(dmesg
が役立つかもしれません)を見て、何かあるかどうかを確認するのが賢明でしょう。システムに休止状態を指示しても、実際には休止しないか、代わりにRAMにサスペンド(スリープ)する理由があります。
kern.log
とsyslog
を見て、休止状態に関連するメッセージを探しても同様に害はありません。 「問題」で始まるセクションは、特定の問題に役立つ場合があります。
重要な変更の1つは、スワップパーティションを持たないが、スワップファイルがあることです。
スワップファイルは、ハードウェア/ドライバー/ OSと休止状態の組み合わせでは機能しない場合があります。
また、ポリシーによって休止状態がオフになったり、禁止されたりする場合があります。
RAMにサスペンド-RAMはデータを保持し、コンピューターはより速くスリープ状態になり、サスペンドされるとより多くのエネルギーを使用し、より早く起動します。これをスリープと呼ぶ人もいます。
ディスクへのサスペンド-別名休止状態。 RAMはスワップ(パーティションまたはファイル)に保存され、コンピューターのスリープ状態が遅くなり、休止中のエネルギー消費量が少なくなり、起動が遅くなります。
休止状態にするには、RAM全体をハードドライブに保存する必要があります(ここでは簡略化しています)。そのため、そのための十分なスペースを確保する必要があります。そうしないと、これは失敗し、休止状態になりません。
free -m
は、スワップのメモリ量、使用量、およびスワップ量を示します。df -h
は、各マウントポイントにあるディスク容量と使用量、空き容量などを示します。これは、後でスワップファイルの場所やパーティションを指定する必要があるため重要です。スワップに十分なスペースを確保するために「トリム」します。cat fstab
は、スワップパーティションまたはファイルがある場合に情報を提供する必要があります。 Ubuntu Hibernation FAQによると、swapfile
は、ハードウェア/ドライバーのいくつかの組み合わせで常に動作するとは限りません。十分なスペースがない場合は、 buntuスワップFAQ に従ってください。スワップファイルを増やす方法、別のファイルを追加する方法、使用されているかどうかを確認する方法などを説明しています。コマンドと説明を参照してください。本当に素敵なリソース。
カーネルドキュメントは言う:
/ sys/power/image_sizeは、ディスクへのサスペンドメカニズムによって作成されるイメージのサイズを制御します。画像サイズの上限として使用される非負整数を表す文字列をバイト単位で書き込むことができます。ディスクへのサスペンドメカニズムは、イメージサイズがその数を超えないように最善を尽くします。ただし、これが不可能であることが判明した場合、可能な限り最小のイメージを使用して一時停止しようとします。特に、このファイルに「0」が書き込まれる場合、一時停止イメージは可能な限り小さくなります。このファイルから読み取ると、現在の画像サイズ制限が表示されます。これは、デフォルトで使用可能なRAMの2/5に設定されています。
そのため、画像サイズを調整してみてください。方法-別の質問をお願いします。
カーネルは、/sys/power/state
にリストされているものをすべてサポートします。
cat /sys/power/state
許可される(私の知る限り)エントリには、mem
、standby
、freeze
、disk
が含まれます。説明:
mem
-いくつかの意味があり、cat /sys/power/mem_sleep
を介してシステム上で正確にわかります。私が持っている:s2idle [deep]
standby
-パワーオンサスペンド(サポートされている場合)freeze
-アイドル状態へのサスペンド(STI)disk
-ディスクへのサスペンド(STD)、休止状態。これ-あなたが欲しい。次に、cat /sys/power/disk
を確認する必要があります。 disabled
がある場合は、セキュアブートを探してBIOSに飛び込みます。これが私が提供できる唯一のアイデアであり、休止状態を妨げる可能性があるのは私が知っていることだけです。私はSecureBootしか知っていませんが、他の干渉があるかもしれませんので、「セキュアブート」がなくてもBIOSを確認することは良い考えです。
ここを読む:
TBH、カーネルが休止状態をサポートしていない場合でも、別の方法で試すことができます。セクションInterfaces
までスクロールします。
順不同:
BTRFSと休止状態を使用しないでください:破損したデータが結果になります。
人々がスワップファイルを放棄し、スワップパーティションに戻る場合があります。結局、以前のLTSで機能しました。私は試していないので、ポインターを提供しません。
/etc/fstab
を新しいものに変更します。変更を確認するために再起動します(fstab
のバックアップを保存するので、万が一の場合に簡単に元に戻すことができます)。注意深く読み、それを行うかどうかを決定しますが、これはカーネルを構成するための方法にすぎません。 systemd
およびuswsusp
を使用して休止状態にする方が簡単な場合があります(以下のInterfacesを参照)。私と同じように、最終的にはRAMへのサスペンドで十分であり、スワップファイルに32GBを入れたくないと判断するかもしれません(たとえば、ラップトップにSSDを1つ搭載している人にはあまり適していません)。 しかし!
resume=
がスワップファイルがどのパーティションにあるかを知る必要があり、resume_offset=
がスワップファイルのどこから再開するかを知る必要があります。resume=
が必要です。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のいずれかです。ファイルを冬眠する場合-ファイルが見つかるパーティションを提供します。
読書:
スワップファイルは適切にフォーマットする必要があります。ログにこれが示されている場合は、ファイルへの休止状態を試みているか、再開パラメーターが正しくありません。
パーティションに切り替えるか、ファイルを修正するか、休止状態に使用するインターフェイスを変更します。
参照: 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
テスト:cat /sys/power/disk
にはdisabled
があります。ログには、「logindを介したシステムの休止状態に失敗しました:スリープ動詞はサポートされていません」と表示されます。
解決策:BIOSを検索し、問題のあるものを見つけます。消して。
解決策2:別の休止状態のインターフェイスを試してください。
参照: 16.04.1で休止状態をアクティブにする方法?(systemd) 。
私にとっては、それをコンパイルするのにほぼ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なし)を使用して、動作するかどうかを確認します
私にとっては、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
履歴書が見つからないか間違っている場合は、ブートカーネルを再度更新する必要があります。
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
は機能していません。それ以外の場合は、正常に機能していることを示します。