私の顧客は、1年ほど前からLenovo ThinkpadT450を使用しています。マシンは現在、jessie-backportsからカーネルを使用してDebianjessieを実行しています4.5+73~bpo8+1
。最新のUEFIバージョンがフラッシュ/インストールされます。オペレーティングシステムは「UEFIモード」でインストールされ、追加のEFI
パーティションなどがあります。約4週間前まで、このセットアップは堅実で安定していました。LenovoThinkpadとDebian、何がうまくいかない可能性がありますか?
4週間後、起動するたびに、マシンは私が件名に入れたエラーを表示します。これがこの画像です:
押す Esc 「うまく」機能したブートプロセスをさらに2週間継続します。その後、メッセージはから変更されました
Escキーを押して続行するか、F1キーを押してセットアップに入ります。
に
はいまたはいいえをクリーンアップします
(残念ながら、私はこれのイメージを持っていません)。
クライアントが「YES」を押すと、ストレージが消去されました。現在、このすべてが表示されているため、マシンが起動できなくなりました。その後、「debian」ブートエントリを復元しましたが、マシンは再び正常に起動し、正常に起動しました。これはさらに数日間続きました。約1週間なので、起動するたびにメッセージが再び表示されます。
私は4日間に4回Lenovoサポートに連絡しようとしましたが、毎回電話キューで30分ほど過ごした後あきらめました。
私は最近、すべての$(your-favorite-search-engine-here)スキルを使用しましたが、ほとんど何も見つかりませんでした。これはどこから来たのか、デバッグする方法、そして最も重要なのは、これを修正する方法です。現在の状況では、マシンはまもなく再び起動できなくなると思います。
どんなポインタも高く評価しています!
バージョン3.8以降のLinuxカーネルはUEFI変数ストレージをefivarfs
として抽象化します 。
efivarfs
mount | grep '^efivarfs'
が何も返さない場合は、次のコマンドを使用してefivarfs
をマウントできます。
mount -t efivarfs efivarfs /sys/firmware/efi/efivars
これで、/sys/firmware/efi/efivars
を参照して、目立つ変数があるかどうかを確認できます。
efivarfs
にはディスク使用量の概念はありませんが、各変数をサイズ別に報告します。このコマンドは、変数をサイズの昇順で並べ替えます。
ls -lh /sys/firmware/efi/efivars | sort -k5 -h
これは、あなたが提供した情報を使用して私があなたを連れて行くことができる限りです。次に、UEFI変数NVRAMで何がこれほど多くのスペースを占めているかを把握する必要があります。
Arch Linux wiki は、/sys/firmware/efi/efivars/dump-*
ファイル/変数が存在する場合はそれらを削除することを提案していますが、それらの変数を作成するものについては言及されていません。
チャットで説明 のように、1つのアプローチは、UEFI変数のスナップショットを取り、Lenovoファームウェアによって提案されたとおりにフラッシュし、DebianのEFIブートを再インストールし、スナップショットを再度作成し、UEFI変数がもう一度いっぱいにして、もう1つのスナップショットを撮ります。次に、スナップショットを比較して何が変更されたかを確認し、問題のある1つまたは複数の変数が非常に多くのスペースを占める原因を特定できます。
他のすべてが失敗した場合は、レガシーブートに戻ることができます。