☰

efivarsへのダンプファイルの書き込みを無効にする

tag-icon • tag-icon linux ubuntu uefi
efivarsへのダンプファイルの書き込みを無効にする

最近、私は2台のコンピュータ（ThinkPad X230とW530）がUEFIブート変数を格納したNVRAMが独立して不足し始めているという問題を発見しました。これは開始されません。幸い、レガシーブートモード（すべてUbuntu 20.04.1）に切り替えた後、正常にOSブートしましたが、問題は解決しませんでした。

さらなる調査の結果、起動する/sys/firmware/efi/efivarsたびに -tingcat変数に何も表示されないことがわかりました。完全に空のように見えますが、多くのスペースを占めています。これらのダンプ変数はしばしば。catdumpdump-type0-11-1-1643821377-C-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0

私はより詳細に掘り下げ、この変数名の一部についてJournalctlを検索し始めました。次のログからわかるように、pstoreによってefivarsに書かれていることがわかりました。

Feb 03 10:37:35 slazien-thinkpad-x230 systemd-pstore[1367]: PStore dmesg-efi-164382137702001 moved to /var/lib/systemd/pstore/164382137/dmesg-efi-164382137702001

私が理解したのは、コアダンプを/sys/fs/pstore次に移動する役割を担うのはsystemd-pstoreです/sys/firmware/efi/efivars（間違っている場合は訂正してください）。だから設定でpstore処理を無効にしてみました。Storage=noneだから設定で試してみました。pstore.conf(5)。これにより、前述のジャーナルctlログが削除されますが（空ですか？）ダンプファイルは引き続き記録されます。

ちなみに、systemd-pstoreはうまく機能します。

systemctl status systemd-pstore.service
● systemd-pstore.service - Platform Persistent Storage Archival
     Loaded: loaded (/lib/systemd/system/systemd-pstore.service; enabled; vendor preset: enabled)
     Active: active (exited) since Thu 2022-02-03 11:03:13 EST; 2h 13min ago
       Docs: man:systemd-pstore(8)
   Main PID: 1287 (code=exited, status=0/SUCCESS)
      Tasks: 0 (limit: 18853)
     Memory: 0B
     CGroup: /system.slice/systemd-pstore.service

Feb 03 11:03:13 slazien-thinkpad-x230 systemd[1]: Starting Platform Persistent Storage Archival...
Feb 03 11:03:13 slazien-thinkpad-x230 systemd[1]: Finished Platform Persistent Storage Archival.

dump現在、根本的な原因を解決しながら、これらのefivars書き込みを無効にしたいと思います。どうすればいいですか？

編集する：いくつかの探偵作業を終えた後、私は根本的な原因を見つけてください。良い概要が提供されていますこの点。

答え1

pstoreEFIストレージバックエンドを使用しないようにするには、カーネルブートオプションを追加してみてくださいefi_pstore.pstore_disable=1（今は直接確認できませんが）。

NVRAMオーバーフローは、特定のノートブックモデル（ThinkPads xx30を含む）にのみ影響し、他のノートブックモデルには影響しないまれな問題のようです。私が正しく理解した場合、一部のシステムのEFIファームウェアは正しく実装されていないか、NVRAMスペースが制限されすぎて動作が結合されてpstoreオーバーフローが発生する可能性があります。

この問題の最初の言及を見つけることができます。ここ。より多くの（しかしまだ不足している）情報：ここそしてここ。しかし、全体像を明らかにするには、より多くの調査が必要です。

PS皮肉なことに、古いカーネルモジュールのいくつかの重要ではないバグは、カーネルダンプを保存するのに苦労しすぎるデバッグメカニズムのために致命的になる可能性があります。

関連情報