systemctl
タフなケースで休止状態を使用して動作させる
私にとっては、pm-hibernate
常に失敗します。いくつかの微調整の後、systemdのインターフェイス(16.04以降の初期システム)を使用して休止状態にすることができました。また、17.04でスワップファイルを使用して動作させることもできました。このケーススタディは、問題のある他の人に役立つ場合があります。
初挑戦:
sudo systemctl hibernate
それが失敗した場合は、トラブルシューティングを開始します。休止状態(HTDまたはACPI S4)では、マシンの状態がディスクに書き込まれるため、保存するために電力は必要ありません。状態は、スワップパーティションまたはスワップファイルのいずれかに書き込まれます。注:BTRFSを使用する場合は、ファイルシステムの破損を引き起こす可能性があるため、スワップファイルを使用しないでください。
スワップパーティションまたはスワップファイルは、休止状態を許可するためにRAMと同じサイズである必要がありますが、Arch wikiページによると、 RAMのサイズの少なくとも2/5であれば休止状態にできる可能性があります。、スワップサイズを増やす前に、まず他の手順を試してください。
問題が、予想される再開ではなくクリーンブートを取得することである場合、少なくともディスクイメージを見つけるためにブートパラメーターを設定する必要があります。
スワップパーティションを見つけます。
grep swap /etc/fstab
私にとっては、これは(部分的な出力)を返します
# swap was on /dev/mmcblk0p3 during installation
/dev/mmcblk0p3
指定するパーティションはどこですか
ブートパラメータを追加します。
sudoedit /etc/default/grub
開始GRUB_CMDLINE_LINUX_DEFAULT
する行にresume=/dev/YourSwapPartition
、引用符で囲んだセクションを追加します(前に特定したパーティションに置き換えます)。私の例を使用して:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash resume=/dev/mmcblk0p3"
このファイルを変更するたびに、実行する必要sudo update-grub
があります。変更しないと、変更は効果がありません。
次に、再起動する必要があります。次に、次のコマンドを発行して、休止状態を試みることができます。
sudo systemctl hibernate
再開するには、電源ボタンを押すとシステムが起動します。
それでも問題が解決しない場合は、デバッグを開始してください。
私は、一例として以下の私の場合を含むが、S状態のデバッグに関する詳細な情報を見つけることができ、このブログにしても、この1。
ブートパラメータをさらに設定して、より多くの情報を取得します。削除quiet
およびsplash
追加initcall_debug
をno_console_suspend
行うと、initシステムコールがコンソールに出力され、何が問題なのかを確認できます。私はこれを設定しました:
GRUB_CMDLINE_LINUX_DEFAULT="resume=/dev/mmcblk0p3 no_console_suspend initcall_debug"
これにより、休止状態からの再開時に何が問題になっていたかがわかりました。
私の場合、レジューム後にWiFiを失い、ほとんどのコマンド(たとえば/sys
、モジュールからの読み込み、モジュールのリロードなどsystemctl
)が機能しないため、カーネルが明らかに動揺しました-プロセスが開始してハングしたように見えます(これはすべてもちろん再起動後に通常に戻ります)。システムが非常にゆっくりとシャットダウンし、すべてのデバッグメッセージが表示されるのを見て、「brcm」に多くの問題があることに気づいたので、Broadcomワイヤレスドライバーモジュールのせいだと思いました。案の定、休止状態の手順を調整して、最初にモジュールをアンロードしました。
sudo modprobe -r brcmfmac
sudo systemctl hibernate
再開時にモジュールを再挿入します
sudo modprobe brcmfmac
そして、すべてが完璧に機能しました。また、btsdio
互換性がないと思われるモジュールをブラックリストに登録する必要がありますbrcmfmac
更新:17.04のスワップファイルを使用した休止状態。
再びArch wikiページの助けといくつかの追加の調整により、17.04でスワップファイルを使用してハイバネーションを動作させることができました。これには、追加のブートパラメータが必要でしたresume_offset=n
。nは、次physical_offset
の出力の最初の数字ですsudo filefrag -v /swapfile
。
$ sudo filefrag -v /swapfile
Filesystem type is: ef53
File size of /swapfile is 1425873920 (348114 blocks of 4096 bytes)
ext: logical_offset: physical_offset: length: expected: flags:
0: 0.. 32767: 34816.. 67583: 32768:
1: 32768.. 63487: 67584.. 98303: 30720:
....
したがって、私の場合の追加のブートパラメータはresume_offset=34816
です。再開するパーティションのブートパラメータを設定する必要があります。これがルートパーティション(またはスワップファイルのあるパーティション)になります。私のパラメーターは次のとおりです。
GRUB_CMDLINE_LINUX_DEFAULT="no_console_suspend initcall_debug resume=/dev/mmcblk1p2 resume_offset=34816"
/dev/mmcblk1p2
ルートパーティションはどこにありますか(あなたのものはのようなものです/dev/sda2
)。
再開中にイメージの読み込みが正常に行われたのを確認しましたが、私の場合(例-YMMVAPD)、さらにいくつかのドライバー(i2c_designware
)がエラーをスローし、再開時にシステムが完全にフリーズしました。に加えてこれらのモジュールをアンロードするとハイバネーションが機能しますbrcmfmac
が、これらのモジュールがないとシステムはすぐに使用できなくなります。したがって、バグのあるモジュールをアンロードして、再開時にすぐに再挿入するためのスクリプトを作成しました。
# remove buggy modules
modprobe -r brcmfmac i2c_designware_platform i2c_designware_core &&
# hibernate
echo disk > /sys/power/state
# reinsert
modprobe i2c_designware_core i2c_designware_platform brcmfmac
休止状態にしたいときは、を実行しsudo bash script
ます。これはうまく機能します。
TL; DR
systemdを使用し、スワップから再開するためのブートパラメータを設定し、バグのあるドライバを特定して、休止状態を開始する前にそれらをアンロードします。これらのモジュールがないとシステムが長時間動作しない場合、またはいくつかのモジュールをアンロードする必要がある場合、単純なスクリプトを使用して休止状態を開始する方が簡単な場合があります。