青木様 試していただきありがとうございます。他の環境でも動いているようでほっと しました。
タイムアウトは最初は入れるつもりだったのですが、とりあえず動いた所で やる気が切れて(^^;;、そのままになってます。 尚、既にsend-pr済なのですが、「興味なし」との回答なので、マージされる ことはないでしょう。 野中 On 2016/03/13 16:59, Tomoaki AOKI wrote: > 野中様 > > 試させて頂きました。 素晴らしい！ 私の環境でもキチンと選択したパーティ > ションから起動できています。（GPTで、2台のドライブにUFSとZFSが1つずつの > 環境しかありませんが...。） > > ところで、このパッチ、せっかくなのでfreebsd-current MLに投げてみません > か？（たぶん、日本語のページからのダウンロードは外国人開発者にはハードル > が高いと思いますし。） > > Baseに取り込むとなると、データセンタ等のリモート環境で予定外のリブートが > かかった場合（FreeBSDに限らず、*BSDだとありそうです）も考慮すると > > ・loaderでいうautoboot_delayのようなtimeout（固定or可変）を設けて、 > 選択入力が無ければデフォルトの（現状のboot1.efiと同じ）優先順位で > 起動する。 > > ・timeout値は/(boot/)boot.config等で指定できるようにする。 > > ・timeout値可変で設定値がゼロの場合はデフォルトの優先順位で起動する。 > > ・選択したパーティションの表示後のキー入力は不要では？（固定or可変時間 > 表示後に起動。 1秒程度の固定でよいか？） > > といった形で手を入れる必要はありそうですし、 > > ・eficonsctl.hのincludeを止めている点 > > については説明を求められそうではありますし、これを見て欲が出た人からは > > ・どうせならパーティションはada0p4やらda0p3のような形で見たい > > ・いやいや、（自分の管理し易い）DISKIDやラベル名で見たい > > ・ZFSのbootfsのsnapshotを指定できると/boot/*.4th更新の不具合で > BE選択すらできなくなって起動不能な時にmemstickを引っぱり出さずに > 済んで助かるんだけど > > というような贅沢な要望も出てきそうな気はしますが、そのあたりは（要説明の > 部分を除いて）誰か引き継いでね、でもいいのではないかと思います。 > > ざっとパッチを拝見したところ、現状のパーティション自動選択の部分を > 手動選択機能と差し替えているように見えますので、併存できるように > しないとUEFI版インストーラで使用するのは辛そうですね。 > > いずれにせよ、既にRC2まで進んでしまった10.3にMFCするのまでは難しいとは > 思いますが、喜ぶ人も多い機能かと思います。 ありがとうございました。 > > > On Fri, 11 Mar 2016 07:39:44 +0900 > Naomichi Nonaka <n...@enuenu.org> wrote: > >> 青木様 >> >> 確定申告に手を付けたくなくて(^^;、起動時にパーティションを選択できる >> パッチを作っていたらとりあえず動いているようなので公開します。 >> >> 興味のある場合は >> >> http://blog.livedoor.jp/goldfish_and_laser/archives/5191810.html >> >> をご参照ください。 >> >> 野中 >> >> On 2016/02/02 21:11, Tomoaki AOKI wrote: >>> 野中様 >>> >>> On Tue, 2 Feb 2016 20:38:24 +0900 >>> Naomichi Nonaka <n...@enuenu.org> wrote: >>> >>>> 青木さま >>>> >>>> 前回は私の勘違いから的外れなコメントを行ってしまい、大変失礼しました。 >>>> >>>> 前回書きました >>>> >>>>> UEFIでのブート順序ですが、仕様上は環境変数(UEFIの不揮発メモリ)の値に >>>>> 従って順序が指定されるはずです(Ex. Linuxのefibootmgrの-oオプション)。 >>>>> この環境変数を利用しない理由は何でしょうか？ >>>>> >>>>> たしかこの環境変数の解析にはずいぶん手間がかかった記憶があるので、 >>>>> 工数が足りないのかもしれませんが、それ以外に積極的に現在の仕様を >>>>> 採用する理由がありましたらご教示いただけると幸いです。 >>>> >>>> というコメントは無意味ですので撤回いたします。 >>>> >>>> ５年も前の話を、あいまいな記憶で書くものではないですね。 >>>> 反省しております。 >>> >>> 先ほどこちらもトンチンカンな返信をしていますのでお気になさらず。 >>> >>> >>>> 尚、HDを漁った所、以前私が作っていたUEFIloaderのソースを発掘できたの >>>> ですが、私はUbuntu上でEDK2ベースで作っていたので、残念ながら参考には >>>> ならないと思います。 >>>> >>>> なんだかいちゃもんをつけたようになってしまい、申し訳ありませんでした。 >>> >>> 他の分野でもそうですが、色々なバックグラウンドを持ったメンバーが議論 >>> する中で思いもよらない打開策が出てきたり、見落としていたトラブルの種を >>> 処理できたりすることも多々有ります。 スルーされずコメント頂けただけでも >>> 有難いと思います。 >>> >>> さて。 Diff7で再度発生した不具合が修正された筈のDiff9が出来ているとの >>> ことなので、これから再びテストです...。 >>> >>>> >>>> 野中 >>>> >>>> On 2016/02/01 9:50, Naomichi Nonaka wrote: >>>>> 青木さま、こんにちは。 >>>>> >>>>> ５年(?)ほど前に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っぽいです。 >>>>>> >>>>> >>>>> _______________________________________________ >>>>> freebsd-users-jp@freebsd.org mailing list >>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-users-jp >>>>> To unsubscribe, send any mail to >>>>> "freebsd-users-jp-unsubscr...@freebsd.org" >>>>> >>>> >>>> _______________________________________________ >>>> freebsd-users-jp@freebsd.org mailing list >>>> https://lists.freebsd.org/mailman/listinfo/freebsd-users-jp >>>> To unsubscribe, send any mail to "freebsd-users-jp-unsubscr...@freebsd.org" >>>> >>> >>> >> >> _______________________________________________ >> freebsd-users-jp@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-users-jp >> To unsubscribe, send any mail to "freebsd-users-jp-unsubscr...@freebsd.org" >> > > _______________________________________________ freebsd-users-jp@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-users-jp To unsubscribe, send any mail to "freebsd-users-jp-unsubscr...@freebsd.org"
