読み取り専用BIOS問題の回避策 ― GRUB2でISOファイルを直接ブートする

数ヶ月前、私はついにLenovo G50ノートパソコンで発生していた「読み取り専用NVRAM問題」を解決することができました。元の問題や最初の回避策の試みについては以前の記事でお読みいただけます。その後、Ubuntu 17.10のドライバー騒動でこの問題が一気に注目を集めることになり、ついにはカーネルアップデートという形で本当の解決策が登場し、以後私のUEFIは再び正常に動作するようになりました。面白いことに、これは本来もっと大きな問題であり、Ubuntuに限定されたものではありませんでした。それにもかかわらず、長い間黙殺されてきたのです。

さて、修正が提供されるのを待っている間――そもそも修正が出るかどうかすら分かりませんでした――私は、このLenovoマシンで新しいOSを起動させる方法を模索していました。前述のとおり、VirtualBoxによるrawディスクアクセスがそのひとつです。もうひとつの方法が、ややリスクは低いものの効果も相対的に低い「GRUB2 ISOBoot」です。今回はこれについて解説します。いつの日かあなたも（あるいは今まさに）BIOS/UEFI NVRAMの読み取り専用問題に直面し、カーネルアップデートなどが利用できない状況で回避策を必要とするかもしれません。それでは始めましょう。

ISOファイルからの起動

ISOファイルを直接起動できる機能はGRUB2ブートローダーの比較的新しい機能で、今回はこれを利用して、リムーバブルメディアが使えないノートパソコンという制約を回避します。この機能の使い方に関するドキュメントはやや乏しく、例によってUbuntu寄りに偏っています。とはいえ、最も普及しているLinuxディストリビューションであることを考えれば、ある意味当然とも言えるでしょう。

まずは私のGRUB2チュートリアルを読んで、ブートローダーの仕組みを把握しておいてください。その基礎知識がないと、本記事で紹介する内容を実装することはできません。

手動でメニューエントリを作成する

私は自動化やヘルパーツールに頼る前に、まず手動でテストすることを信条としています。そうすることで、裏側で何が起こっているのかを正しく理解できるからです。基本的な流れは次のとおりです。カスタムGRUB2スクリプトを作成する（既存のテンプレートを流用しても構いません）。ディスク上のパーティション内にある対象のISOファイルを指定する。ISOをループバックデバイスとしてマウントする。そして利用可能なカーネルとinitrd/initramfsファイルを起動する、という手順です。

ここでは /etc/grub.d 配下にある 40_custom スクリプトを使用します。デフォルトでは、このファイルは空で、以下の内容のみが記述されています。

#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries.
# Simply type the menu entries you want to add after this
# comment. Be careful not to change the 'exec tail' line above.

それでは、実際にエントリを作成して試してみましょう。

#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries.
# Simply type the menu entries you want to add after this
# comment. Be careful not to change the 'exec tail' line above.

menuentry "<title>" {
set root=(<disk>,<partition>)
set isoname="<iso file name>"
set isofile="<path>${isoname}.iso"
loopback loop $isofile
linux (loop)<vmlinuz> <boot options>
initrd (loop)<initrd>
}

スクリプトの解説

それでは、このスクリプトの中身を一行ずつ見ていきましょう。

• 1行目のtitleは、その起動エントリのタイトルを指定します。
• 次にrootを設定します。これは、スクリプト内で後ほど指定するパスをGRUBがどのパーティションから探すべきかを伝えるものです。なお、GRUB2は従来のGRUB（legacy）とは若干異なる記法を採用しており、パーティション番号が0ではなく1から始まる点に注意してください。
• 3番目の指示子isonameは、ダウンロードしたISOファイルの名前を指定します。
• 4行目はISOファイルの場所へのフルパスを示します。ISOファイル名と .iso 拡張子を組み合わせてパスを構成します。
• 次の命令は、ブートローダーに対してISOファイルをループバックデバイスとしてマウントするよう指示します。
• 続いてカーネルをロードします。UEFIシステムでは linux エントリは linuxefi と記述します。その後に必須となる起動オプションがいくつか続きますが、残念ながらこれらはディストリビューションごとに異なります。最後にinitrdについても同様に指定します（UEFIシステムでは initrdefi）。

この手法の問題点

このアプローチの課題は、ほぼすべてのディストリビューションが独自の方法でライブセッションを起動していることです。オーバーレイファイルシステムや起動オプションの扱いも含め、汎用的なエントリをそのまま起動できる単一のシンプルな方法は存在しません。繰り返しになりますが、公開されているサンプル集を見れば、この分野における膨大な差異と断片化ぶりが分かるでしょう。Linuxデスクトップの他のあらゆる側面と同じように。

Fedoraでのテスト

私はFedoraでテストすることにしました。Ubuntuの例はあまりに単純だからです。ネットで調査したところ、F18〜F27ファミリー全体で少なくとも12件以上の言及が見つかり、しかもそれぞれ微妙に記述が異なっていました。共通する慣習は、多かれ少なかれ以下のような形に収束します。

menuentry "Fedora Live" --class fedora {
set root='hd0,msdos8'
set isofile="/home/roger/Downloads/
Fedora-Workstation-Live-x86_64-27-1.6.iso"
loopback loop $isofile
linux (loop)/isolinux/vmlinuz0 iso-scan/filename=${isofile}
root=live:CDLABEL=Fedora-Live rootfstype=auto ro rd.live.image
quiet rhgb rd.luks=0 rd.md=0 rd.dm=0
initrd (loop)/isolinux/initrd0.img
}

私は最新のFedora 27の例と、ISOファイルが第8パーティション（sda8）に配置されたデュアルブート環境を使用しました。これをカスタムスクリプトに追加したら、次のステップはGRUBメニューの更新です。その後、生成されたGRUB設定ファイルに自分のエントリが正しく含まれているか確認してください。

しかしテストの結果、うまくいきませんでした。他の十数通りのバリエーションでも同じでした。ディスクとパーティション表記の代わりにUUIDを使ってみたり、さまざまなモジュールを読み込ませてみたりしましたが、どの方法でもUbuntu以外のISOファイルをシームレスに起動することはできませんでした。

自動化ツールを使う方法：grml

はるかに簡単なアプローチは、/boot/grml 配下で見つかった任意のISOファイルに対して自動的にメニューエントリを追加してくれるヘルパーツールを使うことです。プログラムをインストールし（sudo apt-get install grml）、対象のISOファイルをコピーして、GRUB更新コマンドを実行するだけです。

この方法での結果はまちまちでした。起動に成功するディストリビューションもあれば、失敗するものもあります。生成されたgrub.cfgファイルを眺めても、出力がどうあるべきかについての共通のシンプルな規約は見当たりません。確かに、最初の記事で紹介したVirtualBoxのrawディスクアクセスよりは安全ですが、ISOBoot方式はすべてのケースで成功する可能性は低いと言わざるを得ません。

その他の回避策

GRUB2 ISOBootに厳密には関係ありませんが、検討の価値のあるツールが他にもいくつかあります。これらの一部は読者の方々からの提案です。私のノートパソコン修復を手伝おうとしてくださった皆さんの心強い支援と貢献に心から感謝します。

Lenovo公式の推奨はマザーボードの交換です。これは確実に機能しますし、試す価値もあるでしょう。ただし、ソフトウェアベースの解決策をすべて使い尽くしてからにしましょう。そちらの方が安価ですし、ハードウェアは常に最終手段として取っておけるからです。実際、カーネルアップデートで問題が解決したように、慌ててマザーボード交換にお金を払うのは無駄になっていたはずです（ハードウェア修理は常に選択肢の一つであり、だからこそ最後に回すべきなのです）。

もうひとつの（かなり上級者向けの）ハードウェアの提案は、flashromツールが対応するUSB SPIプログラマを使って、クリーンなUEFIイメージをノートパソコンのチップに直接書き込むというものです。私は試していませんが、相当大胆で技術に自信がある方なら検討する価値はあるかもしれません。

この一件から得られる小さな教訓は、「待つこと」の大切さです。私の場合、約4ヶ月間辛抱強く待ちました。ハードウェア修理にお金をかけたり、新しいノートパソコンを購入したりせずに済みました。もちろん、状況によっては待つ余裕がない場合もあることは理解しています。

その他の選択肢を優先度の高い順に挙げると、1) 利用可能であればBIOS/UEFIファームウェアの再フラッシュ、2) GRUBの代替としてrEFIndブートマネージャーを使用する。多少の工夫（いずれ詳細に掘り下げたいと思います）によって、読み取り専用BIOS/UEFIが課す制限を回避できる可能性があります、3) EasyUEFIなどその他のUEFI管理プログラム、4) 祈りの書――多くのギークにとってはPythonマニュアルのことです。

後ろから2番目のポイントについて、もう少し詳しく見てみましょう。EasyUEFIはWindows向けのプログラムで、EFIブートローダーの管理に利用できます。エントリの有効化・無効化、表示順序の変更、無効化された項目のクリーンアップなどが可能です。

このクリーンアップ機能こそが、NVRAMを協力的な状態へ戻す鍵になるかもしれません（あくまで「かもしれません」ですが）。メインメニューからエントリをひとつ無効化するか、すでに無効状態の項目がある場合はクリーンアップオプションを試してみてください。私の場合はうまくいきませんでした。ツールはシステムAPIエラーを返しました。これはおそらく、問題に関する最初のレポートで確認した「中断されたシステムコール」と大差ないものと思われます。期待しすぎるのは禁物ですが、私の場合より上手くいく可能性は十分あります。

aigle、Ivan、L.、Neal、Marcin、Richard、Nik、Floris、zloster、Georg、Matthewの各氏に、この冒険を通じていただいた提案、アイデア、励ましに深く感謝いたします。問題はすでに解決済みのため、追加のツールや解決策の検証を続けることはできませんが、本記事の内容に加えてカーネルアップデートとVirtualBoxのrawディスクアクセスを組み合わせれば、十分対応できるはずです。

まとめ

こうした風変わりなハードウェアの不具合に直面すると、何の保証もありません。最初の回避策の記事では、VirtualBoxとrawディスクアクセスについて触れました。これは確実に機能しますが、リスクもかなり高い方法です。より影響の少ない手段が、今日のテーマであるGRUB2を使ったISOファイルからの起動です。私のテストでは、この方法は成功率・効果ともにかなり劣るものでしたが、その反面、ハードディスク上のデータを損傷するリスクも低くなります。最後に、他のツールも試すことができます。今後、いくつかのツールについてはさらに詳しく取り上げる予定です。

現時点での私の提案はこうです。もしカーネルアップデートがうまくいかず、かつ現在のセットアップを変更する必要性が本当にないなら、そして現状が快適に機能しているなら、そのままにしておきましょう。私の場合、目標は8つのOSを使い分けることであり、テストマシンとしてはそれで十分でしたし、ライブアップグレードも実行できたため、カーネル修正を待つだけで事足りました。もしハードウェア修理なしで追加のOSを使えるようにしたいのであれば、本記事で紹介した回避策や準回避策を検討してみてください。100%確実で、あらゆる環境に100%適用できる魔法のレシピをお示しできれば良いのですが、ソフトウェアとハードウェアの戦いにおいて、そんな都合の良い話は決してありません。ご健闘をお祈りします。

それでは、また。