[FreeBSD-users-jp 95656] Re: UEFI起動改善作戦へのお誘い

2016年 2月 1日 (月) 00:57:30 UTC

青木さま、こんにちは。

５年(?)ほど前にFreeBSD用のUEFIbootを作りかけて挫折した野中と申します。

当時のソース等残っていないかちょっと探してみたのですが、見当たらないので
記憶に頼って返答することをご容赦ください。

> なお、Stevenの修正版(Diff6)の挙動は、
> 　1)ドライブ単位で、ZFS→UFSの順に/boot/loader.efiを探す。
> 　2)最初にboot1.efi(bootx64.efi)が読み込まれたドライブをトライ。
> 　3)見つからなかった場合、それ以外のドライブを、boot1.efiが認識できた
> 　　順番で1)のルールで順次トライ。
> というものです。　特に違う挙動をお望みの場合は、待ったをかけるなら今の
> うちかと。

UEFIでのブート順序ですが、仕様上は環境変数(UEFIの不揮発メモリ)の値に
従って順序が指定されるはずです(Ex. Linuxのefibootmgrの-oオプション)。
この環境変数を利用しない理由は何でしょうか？

たしかこの環境変数の解析にはずいぶん手間がかかった記憶があるので、
工数が足りないのかもしれませんが、それ以外に積極的に現在の仕様を
採用する理由がありましたらご教示いただけると幸いです。

野中

On 2016/01/31 23:27, Tomoaki AOKI wrote:
> 青木@名古屋です。
> 
> UEFI対応のPCをheadのUEFI起動でお使いの方、何かトラブってインストール用の
> memstickから起動して修復しようとしても壊れた内蔵ドライブから起動しようと
> してしまって何ともならない現象に悩まされていませんか？
> 逆に、普通に使えている状況で、たまたまインストール用のmemstickを挿した
> まま起動した時、UEFIファームウェアの起動設定では内蔵ディスクから起動する
> 筈なのにインストーラが起動してきてびっくり、という経験はありませんか？
> 
> これ、現状のboot1.efi（EFIパーティションにbootx64.efiとしてインストール
> するもの）が起動するパーティションを選択する部分に問題があるのですが、
> 現時点ではheadでも直っていません。　Root-on-ZFS（stable/10にもMFC済)
> に対応したバージョンでも同様です。
> 
> 現在、freebsd-current MLでやり取りしながらsmh@が直してくれているのです
> が、私のテスト環境はThinkPad T420が1台だけなので、他社製品等でのレポート
> もあった方が彼もレビュアー（PHABRICATORではemaste@とimp@が指定されていま
> す）も決心し易いかと思います。
> 
> そこで、UEFIのhead環境（できればシリアルコンソールが使える環境）をお持ち
> の方、特に私と異なるメーカー・機種の方、テストしてfreebsd-current MLに
> レポートしてみませんか？
> 
> 議論自体は、（freebsd-currentなので英文ですが）
> 
> 　　https://lists.freebsd.org/pipermail/freebsd-current/2016-January/059387.html
> 
> あたりから見て頂ければ、「その時点でのRoot-on-ZFS対応パッチでもこの問題
> があるよ」と私が方向転換した分以降は全部見られるかと。
> 
> パッチは、
> 
> 　　https://reviews.freebsd.org/D5108
> 
> で上方右側の「Download Raw Diff」をクリックすると表示されますので、
> ブラウザのSave Page Asあたりで保存して頂ければ。　現在第6版(Diff6)で、
> headのr295032以降になら正常に当たる筈です。
> 
> 　※私もDiff1をテストしてレポートしたらDiff4が出ていて、MLでDiff5を待つ
> 　　ようにという話だったため動けるようになった時点でダウンロードに行った
> 　　らDiff6になっていてこれでテスト＆レポート、という状況ですが...。
> 　　私以外には、レビュアーでもあるimp@がPHABRICATORで不具合のレポート
> 　　（Diff1時点。　私の環境では使っていない/boot.config絡みのため確認
> 　　できず）をしているくらいです。
> 
> なお、Stevenの修正版(Diff6)の挙動は、
> 　1)ドライブ単位で、ZFS→UFSの順に/boot/loader.efiを探す。
> 　2)最初にboot1.efi(bootx64.efi)が読み込まれたドライブをトライ。
> 　3)見つからなかった場合、それ以外のドライブを、boot1.efiが認識できた
> 　　順番で1)のルールで順次トライ。
> というものです。　特に違う挙動をお望みの場合は、待ったをかけるなら今の
> うちかと。
> 
> 　※どこかで複数のUFSのどれから起動するかをパーティションのactiveフラグで
> 　　制御できるようにしたいという要望を見かけたような気がしますが、その
> 　　機能までは入っていませんし、boot0extのようなセレクタも入っていませ
> 　　ん。　その制約の中ではリーズナブルな挙動だと考えていますので、私の
> 　　暴走を放っておくとこのままの方向性でプッシュしていくことになります。
> 　　まずは10.3-RELEASEに確実に入るように進めた方が幸せになれる人が多い
> 　　かと思いますし、一旦loader.efi，loader.confと*.4thを読んでしまえば
> 　　そちらに機能を持たせるという選択肢もあると思われますので。
> 
> 
> なお、（-DDEBUGも指定していないと何か情報が欠落するかどうかは未確認です
> が）-DEFI_DEBUGを指定してビルドすると動作中の画面を見ながら控えるには
> 辛いレベルの出力が出ます（が、レポートするならあるに越したことはない）。
> シリアルコンソールをお持ちでそちらでログを取れればそれがベストです。
> スマホで動画撮影して打ち込むのは神経が疲れましたので、...。
> 
> 
> 補足：　現在、MFCされていない変更の都合で、残念ながらstable/10では
> 　　　　パッチは当たりません。　headでビルドしてしまえば出来上がった
> 　　　　boot1.efiでstable/10を起動することは可能です。
> 
> 補足2：　このメールをほぼ書き上げたところで、Diff7のテスト要請があり
> 　　　　 ました。　今から前述の方法でダウンロードすると、そちらが
> 　　　　 落ちてきますが、変更点は
> 　　　　　・同じデバイスが複数回認識されることが原因のfalse positive防止
> 　　　　　・上記に伴い、デバッグ出力の見直し
> 　　　　 の模様です。　なお、-DEFI_DEBUGさえ指定していればOKっぽいです。
> 