テスト用ラップトップのNVRAMが読み取り専用に――2年半のディストロ酷使が招いた結末

ハードウェアを限界まで酷使する人間がいるとすれば、それは私自身です。2015年初頭、私はLenovo IdeaPad G50-70を購入し、以来このマシンは数多くのLinuxディストリビューションを含むソフトウェアテスト専用機として使われてきました。しかし、それから2年半が経ち、状況は一変しました。

何が起きたのか。いつものように、新しいディストリビューションのISOイメージをダウンロードし、USBメモリに書き込み、ラップトップを再起動して外部デバイスからブートさせようとしたのです。ところが、それができませんでした。デバイスが認識されないのです。書き込みに使っている定番ソフトEtcherのバージョン固有の問題だろうと思い、古いバージョンを試しても結果は同じ。別のUSBメモリでもダメ。さらに3種類のディストリビューションを試しましたが、そのうち2つは実際にこのマシンにインストール済みのものです。それでも何も変わりません。

調査

事態は複雑化していきます。思考の全経緯を正確には思い出せませんが、まずハードウェア関連のトラブルシューティングに入る前に、ソフトウェア側から攻めることにしました。

当時、このマシンの複雑なマルチブート環境を管理していたのはopenSUSE Leap 42.3です。インストール時にSecure Bootサポートを有効にするか尋ねられたことを思い出し、これがシステムが新しいブートデバイスを拒む原因なのではないかと考えました。有効な署名済みイメージを持つ他のディストリビューションもあるので、どうも筋が悪そうですが、念のため設定を変更して再起動してみました。やはり何も起こりません。

そこで、openSUSEが原因ではないことを確認するため、Kubuntu Zestyをマルチブート環境の管理ディストリビューションとしてセットアップし直すことにしました。効果はないだろうという予感はありましたが、見落としがないよう、ゆっくりと粘り強く進める必要があります。さて、以前GRUBとEFIの復旧チュートリアルでお見せしたように、ブートローダーの復元方法はいくつもあります。その作業中、私は次のような出力を目にしました。

Installing for x86_64-efi platform.
Could not delete variable: Interrupted system call
Could not add entry to BootOrder: Interrupted system call
Installation finished. No error reported.

これは良くありません。efibootmgrを直接使っても同じエラーメッセージが出ました。ここでネットで調べてみると、この問題への言及がいくつか見つかりました。奇妙なことに(あるいは当然のことながら)、openSUSEユーザーの間でまったく同じ症状――UEFI設定を変更できず、私と同じようなフラストレーションを抱えている――の報告が多数あったのです。しかしopenSUSEだけではありません。Arch、Debian、Fedoraなど、挙げればきりがありません。

さまざまな方法でブートマネージャーに変更を加えようとトラブルシューティングを続けました。efibootmgrを試し、Windows 10からbcdeditも試しました。そこでも似たようなエラーが出ました。

bcdedit.exe /import newbcd /clean
The store import operation has failed.
The request was aborted.

さらにUEFIメニューであらゆる変更を試み、違いが出るか確認しました。予想通り、何をしても再起動後には変更が保持されません。NVRAMが読み取り専用になってしまったようです。

次の一手……そして撃沈

いくつかの軽度なハードウェア的な小技も試しました。バッテリーを外す、電源ボタンを長押しする、といった無害な類のものです。UEFIの再書き込みも試みましたが、残念ながらBIOSバージョンが一致していたため、Lenovoのユーティリティは書き込みを許可してくれません。サポートに連絡して追加の診断ツールがないか尋ねてみたものの、返ってきたのは既に公開されているKB記事と、自分でダウンロードできるものへのリンクだけでした。

苦労して古いバージョンのBIOSツールを見つけ出しましたが、やはりユーティリティは現行より古いバージョンへのダウングレードを拒否します。プロセスを強制する方法も見つかりません。お手上げです。

これからどうする

つまり現状、私は「設定が固定された完全に動作するラップトップ」を手にしていることになります。これは新しいディストリビューションのクリーンテストには使えないということです。ただし、稼働中のシステム上でのアップグレードテストや、各種ソフトウェア関連のチュートリアル・トピックには引き続き活用できます。実はクリーンインストールも不可能ではないのですが、それは別記事の話題であり、かなり危険な手法です。詳細は改めて。ともあれ、現状の構成はそのまま維持されます。パーティション順に並べると以下の通りです。

• Windows 10 Home(/dev/sda5)
• Xubuntu 17.04 Zesty Zorba(/dev/sda6)
• Ubuntu 16.04 Xenial Xerus(/dev/sda7)
• CentOS 7.2 KDE(/dev/sda8)
• Manjaro 17.0.1 Gellivara Xfce(/dev/sda9)
• openSUSE Leap 42.3 Plasma(/dev/sda13)
• Kubuntu 17.04 Zesty Zeus(/dev/sda14)
• Fedora 25 Workstation GNOME(/dev/sda15)

つまり、非常に珍しい8重ブート環境です。ほとんどの人は一生設定しないでしょう。この2年半で、おそらく200〜300個のディストリビューションインスタンスをインストールしてきました。加えて、断続的なブートローダーの更新やブート順序の変更があり、しかもNVRAMへのデータ書き込みは複数のチャンクに分けて行われるため、その一つひとつが小さなメモリ領域に摩耗をもたらします。総書き込み回数はおよそ1,000回以上。半導体の記録領域を文字どおり使い果たし、もう電子は残っていない、というわけです。

技術者でない一般の方は(そもそも入っているものをそのまま使うだけですが)、ラップトップの一般的な寿命である3〜5年の間に、せいぜい片手で数えられる程度、多くても10回未満のインストールしか行いません。私はこの数字を約2桁上回っています。つまり300〜500ラップトップ年に相当するUEFIへの虐待であり、これが今回の小さな惨事の原因である可能性が高いのです。

というわけで当面の間、新しいテストマシンを購入するかどうか決めるまで、新規ディストリビューションのテストは古いLG RD510で行います。Antergosなどで既にお見せした通りです。老朽化したCPUとのデュアルブートのみになりますが、性能制約がある分、そしてNVIDIAカードが搭載されている分、むしろ少し面白くなるかもしれません。もちろん、いつものクールな要素はすべて盛り込みます。UEFIはなく、おそらくネットワークのハードウェア問題にも悩まされません。ただ、徹底的で詳細かつ正直なレビューをお届けすることは変わりません。そして近いうちに必ず新しいハードウェアを購入するので、また痛みとバグとドラマの日々が戻ってきます。

もう一つ。私の執筆キューは非常に長く、すでに3か月分の記事が書き溜められています。その一部はG50が元気に動いていた頃に完成したものなので、その点はご了承ください。きっと興味深く、楽しい内容になるはずです。

結論

この記事を書いている最中に、ふと考えました。大量のファームウェア書き込みを伴うテストを行うなら、Legacyモードを使った方が良いかもしれません。UEFIモードは使えなくなりますが、それほど悪い話ではないでしょう。そもそもこの「書き込みによる摩耗」問題はルーターにも当てはまります。設定を変更するたびに、メモリセルが一つ死ぬのです。覚えておいてください。ともあれ、G50は特殊なテストケースとなり、古参のLGが華々しく復帰します。玉座に値する後継者が見つかるまで。Tux Vivat!

さて、真面目な話として、皆さんにお願いがあります。次に何をすべきか、何かアイデアをお持ちでしょうか? ラップトップを分解する気はありません。CMOSバッテリー自体が存在しない可能性もありますし、無理な改造はデバイスを文鎮化させる恐れがあります。もし何か提案があれば――オンライン検索は不要です、それは私が済ませています――本当に確かな技術的知識と専門性をお持ちの方は、メールでご意見や裏ワザをお聞かせください。できれば非破壊的な方法で。目標は、ラップトップを壊さずにNVRAMを復活させることです。ご意見お待ちしています。

それでは、また。