読み取り専用になったUEFI NVRAMを回避するOSインストール術 ― VirtualBoxのrawディスクアクセス活用

今日のテーマにふさわしい、最も的確で役立つタイトルは何だろうとずいぶん考えた末、このタイトルに行き着きました。手短に言うと、私がテスト用として使っているLenovo G50ノートPC――WindowsといくつかのLinuxディストリビューションによる8重ブート環境を構築しているマシンですが――最近、NVRAMが読み取り専用になってしまったのです。UEFI設定を一切変更できなくなり、その結果、外部メディアからの起動も新しいシステムのインストールもできなくなりました。

とはいえ、既存の構成になんとか変更を加えられるようにしたい。そこで少し時間をかけて「回避策はあるのか?」と考えてみました。答えはイエス、あります! 今日お見せするのは、やや危険(データ面で)なトリックですが、目の前のハードウェア制限にもかかわらず新システムをインストールできるようにする方法です。それではご覧ください。

VirtualBoxのrawディスクアクセス

始める前に、厳重に警告しておきます。

今日扱う内容は、仮想化とrawディスクアクセスに関する専門的な知識と確かな経験を必要とします。非常にトリッキーで危険な操作の連続であり、深刻なデータ損失と精神的苦痛につながる可能性があります。何らかの理由で私の手順に従う場合、システムを完全に壊し、大切な個人情報を失う結果になりかねません。十分注意して進めてください。

データのバックアップとシステムイメージの作成が済んだら、ようやく試験を検討できます。仕組みはこうです。VirtualBoxでは、ディスク全体または特定のパーティションを仮想ディスクとしてマウントできます。これがいわゆる「rawアクセス」です。仮想ディスクとなるファイルコンテナを作成する代わりに、物理ハードウェアを直接使うのです。

というわけで、アイデアはこうなります。仮想マシンを作成し、rawディスクアクセス機能を使ってISOから起動し、目的のオペレーティングシステムを物理パーティションにインストールします。ブートローダーのセットアップはスキップし、その後、起動シーケンスを管理している物理側のOS(この場合はopenSUSE)に入って、そちらでGRUBを更新するのです。

rawディスクの作成

次のコマンドが魔法をかけてくれます。

VBoxManage internalcommands createrawvmdk -filename file.vmdk -rawdisk /dev/sdX -partitions Y,Z -relative

ここで何をしているのか? ディスクファイルを作成します。場所はホームディレクトリ内でも、仮想マシンをまとめて保管している専用フォルダでも構いません。使用したいrawディスク(私の場合は/dev/sda)と、利用するパーティションを指定します。私は1つだけ(/dev/sda8、CentOS 7.2が入っているパーティション)を選び、さらに-relativeフラグを付けました。これにより書き込みアクセスが特定のパーティションのみに限定され、潜在的な被害を最小限に抑えられます。

VBoxManage internalcommands createrawvmdk -filename test.vmdk -rawdisk /dev/sda -partitions 8 -relative

VBoxManage internalcommands createrawvmdk -filename /home/roger/test.vmdk -rawdisk /dev/sda -partitions 8 -relative
RAW host disk access VMDK file /home/roger/test.vmdk created successfully.

このコマンドはsudoまたはrootで実行してください。また、vmdkファイルのパーミッションや所有権にかかわらず、VirtualBoxも同じ権限で起動する必要があります。mountコマンドと同様、デバイスをつかむには一定の特権が必要だからです。

ストレージに注目してください。Kubuntuパーティションはわずか100GBなのに、1TBのディスクとして認識されています。これはrawディスクアクセスを使っているためです。

sudoやrootなしで実行すると、次のような不親切で役に立たないエラーに遭遇します。

Result Code: VBOX_E_FILE_ERROR (0x80BB0004)
Component: MediumWrap
Interface: IMedium {4afe423b-43e0-e9d0-82e8-ceb307940dda}
Callee: IVirtualBox {0169423f-46b4-cde9-91af-1e9d5b6cd945}
Callee RC: VBOX_E_OBJECT_NOT_FOUND (0x80BB0001)

UEFIへの対応

話はそれだけではありません。さらに厄介なことに、私のシステムはUEFI搭載でGPTディスクレイアウトです。つまり、ディスクにはSATAコントローラを使用し、ISOも同様の方法でマウントする必要があります。さらに、仮想マシンの設定でEFIを有効に指定しなければなりません。「あなたは」と言いましたが、正確には「私」のことです。あなたは真似すべきではありませんから。

テスト結果

実際、この方法なら仮想マシンを簡単に起動できました。ディスク全体の構造が丸見えになるのは避けられませんが、あとは単純なインストール作業と、何も壊さないための強い集中力の問題です。それでも、新しい情報をパーティションに書き込む手段としては機能します。

技術的には、仮想マシンを起動した状態で、展開・マウントしたライブメディアからデータをハードディスクへコピーすることも可能です。ddコマンドも使えますが、それはもう「狂気的でクール」な領域の話です。

これこそ、いわゆるインセプション(入れ子構造)というやつです。

まとめ

rawアクセスは戦略兵器だと考えてください。普段は絶対に使いたくないものですが、存在しているという事実だけで心強く、雨の日(いざという時)が来れば頼ることができます。本来は、OS自身によるアップグレードの方が十分興味深い選択肢ですし、ディストリビューション探検の娯楽については、他にもう少し古いテストマシンがいくつかあって、必要な楽しみを提供してくれるでしょう。

よく考えてみれば、道は必ずあります。ただし私は平和的な解決策、つまりノートPCを分解したりディスク上のすべてを危険にさらしたりせずに、NVRAMを再び書き込み可能に戻す方法を模索したいと思っています。とはいえ、どうしてもどうしても必要になったときのために、仮想化経由のrawディスクアクセスが回避策を提供してくれるのです。もちろん、普段は使いません。それでは、ごきげんよう。

それではまた。