読み取り専用 BIOS のインストール回避策 - GRUB2 ISO ブート

数か月前、ようやく Lenovo G50 ラップトップで読み取り専用の問題を解決することができました。元の問題と私の最初の回避策の試みについて読むことができます。そして最後に、Ubuntu 17.10 ドライバーの大失敗により問題が本当に一般的になった後、実際の解決策はカーネルの更新という形でもたらされました。私のUEFIは再び正常に動作しています。面白いことに、これははるかに大きな問題であり、Ubuntu に限ったことではありませんが、長い間何気なく無視されていました.

さて、修正プログラムが作成されるのを待っている間、修正プログラムが作成されるかどうかはわかりませんでしたが、Lenovo マシンで新しいオペレーティング システムを起動する方法を見つけようとしました。前述したように、VirtualBox を介した raw ディスク アクセスはその 1 つです。 GRUB2 ISOBoot. BIOS/UEFI NVRAM 読み取り専用の問題に直面する可能性がある (またはまだ直面している) 日が来る可能性があり、それを回避する方法が必要であり、カーネルの更新などは利用できないため、ここで説明します。先に進みましょう。

起動

ISO ファイルから直接起動する機能は、GRUB2 ブートローダーの新機能です。ラップトップで実際にリムーバブル メディアを使用できないという事実を回避するために、この機能を利用します。この機能の使用に関するドキュメントはやや不足しており、いつものように、そして当然のことながら、最も普及している Linux ディストリビューションである Ubuntu に偏っています。

とにかく、最初に私の GRUB2 チュートリアルを読んで、ブートローダーとその仕組みに慣れてください。その知識がなければ、この記事に書かれている提案を実装することはできません.

手動メニュー入力

自動化やヘルパー ツールを使用する前に、まずテストを行うことをお勧めします。これにより、何が起こっているのかを理解できるからです。舞台裏。基本的な考え方は次のとおりです。カスタム GRUB2 スクリプトを作成する必要があります。または、既存のテンプレートを使用して、ディスク上のパーティションの 1 つで関連する ISO ファイルを指定し、ISO をループバック デバイスとしてマウントします。次に、利用可能なカーネルと initrd/initramfs ファイルを起動します。

/etc/grub.d にある 40_custom スクリプトを使用します。デフォルトでは、ファイルは空で、次のもののみがリストされます:

#!/bin/sh
exec tail -n +3 $0
# このファイルを使用すると、カスタム メニュー エントリを簡単に追加できます。このコメントの後に追加したい
# メニュー エントリを入力するだけです。
# 上記の「exec tail」行を変更しないように注意してください。

それでは、エントリを作成して何が得られるか見てみましょう:

#!/bin/sh
exec tail -n +3 $0
# このファイルを使用すると、カスタム メニュー エントリを簡単に追加できます。
# この
# コメントの後に、追加したいメニュー エントリを入力するだけです。上記の「exec tail」行を変更しないように注意してください。

menuentry "<タイトル>" {
set root=(<ディスク>,<パーティション>)
set isoname=""
set isofile="${isoname}.iso"
ループバック ループ $isofile
linux (ループ) <ブート オプション>
initrd (ループ)
}

ここには何がありますか?

スクリプトを見てみましょう。

• 最初の行 - title - は、特定のブート エントリのタイトルを指定します。
• 次に、ルートを設定します。これにより、スクリプトの後半にリストされている特定のパスを検索するパーティションが GRUB に通知されます。 GRUB2 は GRUB レガシーとは少し異なる表記法を使用し、パーティション番号は 0 ではなく 1 で始まることに注意してください。
• 3 番目のディレクティブ isoname は、ダウンロードした ISO ファイルの名前を指定します。
• 4 行目は、ISO ファイルの場所のフルパスを指しています。 ISO ファイルの名前と .iso サフィックスを使用して行を結合します。
• 次の命令は、ISO ファイルをループバック デバイスとしてマウントするようにブートローダーに指示します。
• 次に、カーネルをロードします。Linux エントリは、UEFI システムで linuxefi を読み取る必要があります。それから、(悲しいことに) ディストリビューションごとに異なるいくつかの必須の起動オプションがあります。最後に、initrd で同じことを行います (UEFI システムでは initrdefi です)。
  

問題は...

このアプローチの問題は、そこにあるほとんどすべてのディストリビューションが、オーバーレイ ファイルシステム、ブート オプションなどを含む独自の方法を使用してライブ セッションを起動することです。 which ジェネリック エントリを起動するための単純で単純な方法はありません。繰り返しになりますが、利用可能な例を見ると、Linux デスクトップの他の側面と同様に、この領域に膨大な量の違いと断片化があることがわかります。

Fedora テスト

Ubuntu の例は本当に些細なことなので、Fedora でテストすることにしました。オンラインで読んだところ、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"
ループバック ループ $isofile
linux (ループ)/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 (ループ)/isolinux/initrd0.img
}

最新の Fedora 27 の例と、ISO ファイルが 8 番目のパーティション (sda8) にあるデュアル ブート システムを使用しました。これをカスタム スクリプトに追加したら、次のステップは GRUB メニューを更新することです。次に、作成された GRUB 構成ファイルに実際にエントリが含まれていることを確認してください。

これをテストしてもうまくいきませんでした。他の多くのバリエーションも同様です。また、ディスクとパーティションの表記の代わりに UUID を使用し、さまざまなモジュールを挿入しようとしましたが、Ubuntu 以外の ISO ファイルを簡単かつシームレスに起動することはできませんでした。

非手動の方法:grml

はるかに簡単な方法は、/boot/grml の下にある ISO ファイルのエントリを自動的に追加するヘル​​パー ツールを使用することです。プログラム (sudo apt-get install grml) をインストールし、関連する ISO ファイルをコピーしてから、GRUB update コマンドを実行します。

この方法では、さまざまな結果が得られました。一部のディストリビューションは起動し、他のディストリビューションは起動しませんでした。生成された grub.cfg ファイルを見ると、出力がどのように表示されるかについて、共通の単純な規則がないように見えます。おそらく、VirtualBox で raw ディスク アクセスを使用するよりも安全ですが、このトピックに関する最初の記事で示したように、ISOBoot メソッドはすべての場合に機能する可能性が低くなります。

その他の回避策

GRUB2 ISOBoot とは厳密には関係ありませんが、他にも考慮すべきツールがいくつかあります。これらのツールのいくつかは私の読者からの提案であり、ラップトップの修理を手伝ってくれた彼らの真の助けと貢献に感謝したいと思います.

Lenovo の公式の推奨事項は、マザーボードを交換することです。これは機能し、それを試みたいと思うかもしれませんが、すべてのソフトウェアベースのソリューションを使い果たした後でのみ.それらは安価であり、いつでもハードウェアにフォールバックできます.そして、これまで見てきたように、カーネルの更新は役に立ったので、まだマザーボードを交換するのはお金の無駄でした (これは常にオプションであり、最後にすべきです)。

もう 1 つの (かなり専門的な) ハードウェアの提案は、flashrom ツールでサポートされている USB SPI プログラマーを使用して、クリーンな UEFI イメージをラップトップのチップに直接フラッシュすることです。私はこれを試したことはありませんが、非常に大胆で精通している場合は、これを検討することをお勧めします。

この話のサブレッスンは、待つのは良いことだということです。私の場合、辛抱強く4ヶ月ほど待ちました。ハードウェアの修理や新しいラップトップの購入に急いでお金を使うことはありませんでした。ただし、状況によっては選択の余地がないことも理解しています。

その他のオプションは、優先度の高い順に次のようになります。1) 利用可能な場合は BIOS/UEFI ファームウェア フラッシュ 2) GRUB の代替としての rEFInd ブート マネージャーの使用。ちょっとしたハッキン​​グ (いつかもっと詳しく調査するかもしれません) で、読み取り専用の BIOS/UEFI によって課せられた既存の制限をうまく回避できるかもしれません 3) EasyUEFI のような他のいくつかの UEFI 管理プログラム 4)ほとんどのギークにとって Python のマニュアルとなる祈祷書です。

最後から 2 番目の点について、もう少し詳しく説明しましょう。これは Windows ベースのプログラムであり、エントリの有効化/無効化、リストされたエントリの順序の変更、無効な項目のクリーンアップなど、EFI ブートローダーの管理に使用できます。

このクリーンアップ コマンドは、NVRAM を連携させるのに役立つ可能性があります (おそらく)。 In the main menu, try to disable one of the entries, or if you already have some in the disabled state, then you can try the cleanup option. In my case, this did not work. The tool threw a system API error, which is probably not that different from the interrupted system call issue we saw in my initial report on the problem. Don't get your hopes too high, but it might work for you better than it did for me.

I would like to thank aigle, Ivan, L., Neal, Marcin, Richard, Nik, Floris, zloster, Georg, and Matthew for their suggestions, ideas, encouragement through the adventure. Since the problem has been resolved, I won't be able to continue any additional tools or ways to resolve the issue, and with what you have above, plus the kernel update, plus the VirtualBox raw disk access, you should be okay.

結論

When you're facing an odd hardware situation, like we have here, there are no guarantees. In the first workaround article, I mentioned VirtualBox and raw disk access. This is bound to work, but the risks are quite high. A less intrusive method is to try to boot from ISO files using GRUB2, our topic today. My testing shows this is a much less successful and effective way, but it also carries less risk of damaging the data on the hard disk. Lastly, you could try some other tools, and we will explore some of those more in the future.

For the time being, my suggestion is - if the kernel update does not work for you AND you do not really have to change the current setup AND it works for you well - let it be. For me, this was the matter of using eight operating systems, more than plenty for a test box, and I could still perform in-vivo upgrades, so it was all right waiting for the kernel fix. If you do want to try to be able to use additional operating systems without making any hardware repairs, then you have several workaround solutions and semi-solutions to consider. I wish I could give you a 100% foolproof 100% applicable recipe, but that is never the case in a war between software and hardware.気をつけてね。

乾杯。