web-dev-qa-db-ja.com

「孤立iノードのクリア」および休止状態の再開時に失われた状態

新しい16.04 LTSをインストールしました。 Wifiアプレットの表示エラー(サスペンドからの再開後)および休止状態の再開でいくつかの問題が発生しています。 here に示す方法を使用して、メニューで休止状態を有効にしました。現在、休止状態の再開は断続的に機能していません。正常に機能する場合もあれば、「孤立したiノードをクリアする」ことを示すテキストを履歴書に表示する場合もあります。システムは、以前のメモリ状態なしで、単純に再起動します。

ここにいくつかの情報があります:

$ Sudo blkid
/dev/sda1: LABEL="System Reserved" UUID="50921EE4921ECE7A" TYPE="ntfs" PARTUUID="dda192f8-01"
/dev/sda2: LABEL="Primary Disk" UUID="765E305F5E3019F7" TYPE="ntfs" PARTUUID="dda192f8-02"
/dev/sda3: LABEL="Secondary Disk" UUID="E2D42C6AD42C42E1" TYPE="ntfs" PARTUUID="dda192f8-03"
/dev/sda5: UUID="dbaad068-46da-4637-9c45-5c32c20d3cfe" TYPE="swsuspend" PARTUUID="dda192f8-05"
/dev/sda6: UUID="31385b29-f351-4a10-9dcf-c92efd58334b" TYPE="swap" PARTUUID="dda192f8-06"
/dev/sda7: UUID="1f734f56-7328-4029-88a0-fa995426d4d2" TYPE="ext4" PARTUUID="dda192f8-07"

$ cat /etc/initramfs-tools/conf.d/resume
RESUME=UUID=31385b29-f351-4a10-9dcf-c92efd58334b
2
thethakuri

まあ、私はかなり長い間この問題を抱えていたので、誰もこれを提案しなかったことに驚いています。答えは私の顔をじっと見つめていた。どうやら私のスワップパーティションは私のメモリとほぼ同じサイズでした。また、grubファイルにスワップパーティションのUUIDへのリンクを追加していませんでした。スワップパーティションサイズをメモリのサイズの2倍に増やし、そのUUIDをgrubファイルに追加すると、休止状態の再開は過去数日間正常に機能します。ただし、休止状態からの履歴書には少し時間がかかりますが、私は文句を言っていません。

スワップパーティションが次のファイルで定義されていることを確認する必要があります。

  • /etc/initramfs-tools/conf.d/resume
  • /etc/default/grub

UPDATE

低レベルインターフェイスuswsuspをデフォルトの休止メカニズムとして使用すると、再開時間が1分未満に大幅に改善されました。

Sudo apt-get install uswsusp

ファイル/etc/pm/config.d/00sleep_moduleを作成し、次の行を追加します。

  • SLEEP_MODULE="uswsusp"
1
thethakuri

私はちょうど同じ問題を「修正」したので、たとえあなたの問題が異なっていても、ここで私の解決策を提供します。

最初にby-uuidの問題を繰り返しました(systemdを削除すると、sysvinitが他の場所で示唆されているようにデバイスの順序を台無しにする可能性があり、uuidリファレンスで問題が解決するはずです。

1週間、あるいは2週間も有効であるように思われ、その後再び開始しました。

この後、grub.cfgでresume=/dev/disk/by-uuid/{}を明示的に設定する必要があるGentooの問題を思い出しました。それ以外の場合は、それが再開されませんでした。そこで、問題が修正されました。 initramfsを管理するためにdracutもインストールしました。しばらくは再び機能しましたが、機能しませんでした。

次に、カーネルのダウングレード、bootlogdのインストールなど、さまざまなことを試しましたが、特別なことを示唆するものはありませんでした。

この時点で、私はより多くの助けを探し始めました。私はすべてを把握しました-非常に読みにくい-情報 ここkernel.orgで 。私はこれを試しました、そして、私は正確に何をしたかをよく覚えていませんが、ちょっと。

再びそれは時々働いた、そして再びそれはしなかった。

今、私は実際に妄想に陥り、カーネル内の隠されたモジュールを探し、コールドブート攻撃を想定し、誰かがおそらく私のBIOSの剣を取得し、休止状態から再開し、コンピュータをリセットし、メモリブートをダンプしますいくつかの外国の画像システム。 (これらすべては絶対に遠いものではないことに注意してください-判明したように-完全に無関係です。)

このクエストで-今日の夜-私はこのサイトを見つけることができました: https://01.org/blogs/rzhang/2015/best-practice-debug-linux-suspend/hibernate-issues 。ここから、2.1 initcall_debug2.3 ignore_loglevelにパラメーターを追加しました。 and2.4 dynamic debugto grub.cfg to kernel boot parameters。

それからまた起こりました。

しかし、今はもっと気を配っていました。私の「孤立したiノード」は、「スーパーブロックの最終書き込み時刻は未来です」が原因であることに気付きました。私は数年前、その半年前に何が間違っていたかを見つけるのに費やしましたが、再び役に立ちませんでした。 systemdの不足と、localtimeをhwclockとして使用する習慣(W7との時折のデュアルブートのため)に関連していると考えたため、6〜10分(不正確なクロックソース)の間隔である必要があります。最大時間(私はGMT + 1 DSTにいます)。

少年、私は間違っていた。

そのため、ignore_loglevelカーネルパラメータが追加されたため、ブートログには、修正時刻だけでなくブート時に時計があった正確な日付が含まれていました。

私の時計は実際には2013年6月6日に設定されましたが、これはおそらくBIOSのリリース日またはそれに類似したものです。それは3年の差です(97010350.488716秒) ntpdateによると)。

そのため、my CMOSバッテリーが破壊されていることが最終的にわかりました。それはちょっと充電されているかもしれません-それは充電可能ではありません-そして、私が長時間コンピュータを残したとき、それは1-2日間「生き残る」のに十分な充電を拾ったかもしれません-またはそれはおそらくただの温度でした、 知るか。 (これは私のプライマリコンピューターではないため、1週間おきに電源を入れずに連続して数日間行きました。)

tl; dr

そうは言っても、CMOSバッテリーを交換するか、ラップトップコンピューターなどの場合は、

  1. (オプション、Xenial 16.04のデフォルトインストールを使用する場合、これは必要ありません)bootlogdをインストールして構成します。これにより、/ var/log/bootにブートログが表示されます。 (systemdでは、journalctl -bを実行してブートログを取得します。)

  2. /boot/grub/grub.cfgファイルを編集し、menuentryで始まる最初の行の下のinitcall_debug ignore_loglevelで始まる最初の行の最後にlinux /boot/vmlinuz...を追加します。

  3. 今すぐ再起動します。これは非常に重要なので、新しい設定をアクティブにして休止状態になります。

  4. 休止状態にし、少なくとも数時間など、かなりの時間マシンをオフにしてから再開します。

  5. 最後に、systemdと呼ばれるものを削除したこと、および/またはupstartopenrc、またはsysvinitと呼ばれるものをインストールしたことを覚えていない場合は、journalctl -b > /var/log/bootを実行します。

これらのすべてのステップでは、rootになる必要があるため、再起動するたびにSudo -sコマンドで開始し、Midnight Commander(apt install mcまたはSoftware Center)を最初に使用し、その(mc)を使用して構成とログを操作します

これで/var/log/bootにログが作成されました。このログでは、「孤立iノード」の実際の原因のような起動時のイベントを検索できます。 「将来の変更時間」の問題を発見し、多くの時間またはそれ以上の差がある場合は、CMOS/RTCバッテリーも完全に破損しているので、交換する必要があります。

0
Victor