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

Tomoaki AOKI junchoon @ dec.sakura.ne.jp
2016年 2月 2日 (火) 11:52:51 UTC


野中様 こん**は。 青木@名古屋です。
反応が遅くなり申し訳ありません。

On Mon, 1 Feb 2016 09:50:51 +0900
Naomichi Nonaka <nao at enuenu.org> wrote:

> 青木さま、こんにちは。
> 
> 5年(?)ほど前に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オプション)。
> この環境変数を利用しない理由は何でしょうか?
>
> たしかこの環境変数の解析にはずいぶん手間がかかった記憶があるので、
> 工数が足りないのかもしれませんが、それ以外に積極的に現在の仕様を
> 採用する理由がありましたらご教示いただけると幸いです。

私自身は現時点の挙動を何とかして欲しいとリクエストした立場なのでテス
トを進めていますが、正直コードの方はまだまだ理解が及んでいません。

# なにせ、現状ではUSB memstickから起動するようにUEFIファームウェア
# のメニューで指定しても、USB memstickのEFIパーティションのbootx64.efi
# が内蔵ディスクのloader.efiを起こしに行き、内蔵ディスクのloader.confに
# 従った起動処理をしてしまうという、例えばインストールメディアで起動
# してのfixitが成り立たない挙動です。


という状態での話ですが、Diff7, Diff8 の吐くデバッグ情報を見る限り、
boot1.efiがどのドライブの何番目のパーティションから読み込まれたかの
情報は取得できているようです。

 例:
  boot1 imagepath: pciroot(0x0):pci(0x1f,0x02):sata(0x0,0x0,0x0):hd(1)

公開されている UEFI Spec 2.5 を流し読みしてみた程度ですが、仰っているの
は恐らくGlobal Variablesの BootOrderの、 NVRAM に記録されているものの
ことですよね? 上記情報がここから取得されているのか他の手段で取得して
いるのかは把握できていません。 libefi.cあたりを見るとSystemTableや
BootServiceやRuntimeServiceはアクセス用ポインタを用意しているようですが
NVRAM(NV)らしきものへのポインタは無さそうな気がします。

現状の内部仕様の理由は私の立場では分かりませんが、つい最近まで必要性の
高い機能が実現できていなかった(bsdinstallに標準で用意されている
Root-on-ZFSの選択肢もUEFI起動では実現できていなかった)状況だったので、
とにかく動いている部分の見直しより必要な機能の実装に注力しているのかな、
と感じます。 他にも、Secure Boot対応という大物もいつ本気で必須になるか
分からない状況ですし。

いずれにせよ、私の立場としては、直近の10系リリース(現在、stable/10が
10.3に向けたコードフリーズに突入しています)に UEFIファームウェアの起動
ディスク選択で指定したディスクからの確実な起動を保証できる仕組みを間に
合わせてあげたい(でないと、下手をするとリリース待ちの人がもうひとつ分
待たされる)というのが最優先です。

# 私自身は基本的に最新のstableブランチを追いかけつつpipermail経由で
# freebsd-src-headを眺めてMFCが来ると挙動変化が心配な変更があったら
# headを試してみるというスタンスです。

なお、ここ数ヶ月作っていませんが、stable/10でmemstick.imgを生成すると
Legacyブート仕様なのですがheadではUEFI対応(Legacyオンリーならそちら)で
起動するようになっていて、例えば現状のheadのmemstickで壊れた環境の修復を
しようとすると壊れた内蔵ディスクの環境を起動しようとしてドツボに嵌まりま
す。

あまりまともな答えになっていなくて申し訳ありません。

> 野中
> 
> 
> 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っぽいです。
> > 
> 
> _______________________________________________
> freebsd-users-jp at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-users-jp
> To unsubscribe, send any mail to "freebsd-users-jp-unsubscribe at freebsd.org"
> 


-- 
青木 知明  [Tomoaki AOKI]
    junchoon at dec.sakura.ne.jp


freebsd-users-jp メーリングリストの案内