From owner-freebsd-users-jp@freebsd.org Mon Mar 21 11:21:26 2016 Return-Path: Delivered-To: freebsd-users-jp@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A748EAD863E for ; Mon, 21 Mar 2016 11:21:26 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from dec.sakura.ne.jp (dec.sakura.ne.jp [210.188.226.8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 585429BE for ; Mon, 21 Mar 2016 11:21:26 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from fortune.joker.local (123-48-23-227.dz.commufa.jp [123.48.23.227]) (authenticated bits=0) by dec.sakura.ne.jp (8.15.2/8.15.2/[SAKURA-WEB]/20080708) with ESMTPA id u2LBLH1N082158 for ; Mon, 21 Mar 2016 20:21:18 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Mon, 21 Mar 2016 20:21:17 +0900 From: Tomoaki AOKI To: freebsd-users-jp@freebsd.org Message-Id: <20160321202117.9a795d134d0afdb3f4492f4e@dec.sakura.ne.jp> In-Reply-To: <56EA9E41.7070508@enuenu.org> References: <20160131232720.a6965244560c3a7b85ddd903@dec.sakura.ne.jp> <56AEABEB.8070505@enuenu.org> <56B09530.5050608@enuenu.org> <20160202211104.b3d0b815041fafbd3f494f73@dec.sakura.ne.jp> <56E1F7B0.6070902@enuenu.org> <20160313165920.d787e5959336c7eaf1e634af@dec.sakura.ne.jp> <56E6995B.4070906@enuenu.org> <20160316231808.b88d187993407bb3e16057e2@dec.sakura.ne.jp> <56EA9E41.7070508@enuenu.org> Organization: Junchoon corps X-Mailer: Sylpheed 3.5.0 (GTK+ 2.24.29; amd64-portbld-freebsd10.3) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: [FreeBSD-users-jp 95689] Re: =?iso-2022-jp?b?VUVGSRskQjUvRjAyfkExOm5AbyRYJE4kKk02JCQbKEI=?= X-BeenThere: freebsd-users-jp@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussion relevant to FreeBSD communities in Japan List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 11:21:26 -0000 野中様 あれ以降、Bugzillaの方も動きがありませんね。　FreeBSD-currentの方では ローダでっかくなってない？という話を発端に、11.0までにboot1.efiにgeli サポートを組み込みたいね、みたいな話が出ていたりしますが。 　https://lists.freebsd.org/pipermail/freebsd-current/2016-March/060201.html On Thu, 17 Mar 2016 21:08:33 +0900 Naomichi Nonaka wrote: > 青木様 > > 応援コメント、ありがとうございます。 > > On 2016/03/16 23:18, Tomoaki AOKI wrote: > > 野中様 > > > > 見つけました。　Bug 207940ですね。 > > > > あらら、Stevenに却下されてしまいましたか。　しかし拾う神もあったようで。 > > 今のところ誰のアドレスか分かっていませんが、HardenedBSDの人のようです > > ね。　こういったFreeBSDからの派生プロジェクトの人にとっては有難い存在と > > 思いますので、反応にも納得です。 > > > > Stevenは前回の私の要望の時は、要望の意図と、対応しない場合の問題点を納得 > > してからは非常に積極的に動いてくれたので、"Why needed?"の部分を納得して > > 貰えれば強力な助っ人になると期待していたので、簡単な位置づけ説明のReply > > を付けておきました。　これで理解してくれるといいのですが。 > > > > 　※こないだ直したばかりなのに...という気持ちもあるかもしれませんが。 > > > > 同じくBugzillaの方に（上記の行きがかり上、先に）コメントを付けておきまし > > たが、ver2のパッチも想定どおりに機能してくれています。　タイムアウトと > > 非選択時のデフォルト対応、早速ありがとうございます。 > > > > 前回の投稿で、間抜けなコメントをしていました。　/(boot/)boot.configは > > 現行の実装では/boot/loader.efiを読み込むパーティションから読み込むように > > なっていますし、このファイルの本来の用途からしてもそれが適切ですが、 > > boot1.efi自体の設定のためにはそれと無関係に自身が読み込まれたパーティ > > ションから読まないと意味がありませんし、混乱の元ですね。 > > > > ところで、今回の野中さんのPRを検索している間に、 > > > > 　Bug 201788 - UEFI boot1.efi doesn't honor GPT bootme/bootonce flags > > > > とか > > > > 　Bug 204674 - [PATCH] boot1.efi remove consolecontrol as it's not > > 　in the UEFI specs > > > > とかを発見してしまいました(^^;。　201788はStatus:Newで絶賛放置中、 > > 204674は野中さんのパッチで削除している画面周りの部分と関係しそう > > ですが、一部それが無いと駄目な機種が存在するようですね。 > > 上記２つを見てみましたが、#201788はgptboot固有機能をboot1.efiにも > 実装しようとするもので、機能的には私のパッチでカバーできそうです。 機能の意味合い的にも親和性は高そうですよね。 > #204674は私と同じく、ConsoleControlはUEFIの仕様書には記載されて > いない、ベンダー固有機能なので削除したいというものですが、この > パッチでは単純にConsoleControl関連の機能を削除しているだけなのに > 対し、私のパッチでは正規のAPIであるConsoleI/Oを呼び出してmode設定 > しているので、私の方が動く可能性は高いと思っています。 旧バージョンの仕様書は全く読めていないので不明確ですが、現在のUEFIの 仕様書が2.5版なのを考えると、仕様で定義される前に必要な機能を独自実装 していたケースで、互換性の都合で現行の仕様に合わせられない（又は、改修版 のファームウェアがリリースされていても、ユーザ側での互換性リスク懸念等で 旧バージョンのファームウェアが使い続けられている）状況だと、それに対応 するためのコードを削除するには「今後そのようなハードウェアには対応しな い」というFreeBSDコミュニティとしての（少なくとも、コアなりREなりの範囲 内での）コンセンサスが必要かと思います。　今後のメンテナンスのために本来 機能以外をシンプルに保ちたいという面からは残念なことですが。 > ただ、たしかにUEFI周りはベンダー依存性が高いので、テスト環境をそろえる > のは頭が痛いですね。 個人レベルではほぼ不可能なことですし。　現行のコードで非標準の機能を使う きっかけになった環境のユーザが気づいて試してくれるといいんですが。 今回実装して頂いたタイムアウト、stall()でのキー入力待ちでいけたん ですね。　仕様書のWaitForEvent()の項のDescriptionを眺めていて、Timer イベントを仕掛けておいて第2引数にリストアップすることになるのかな、と 思っていました。　まだまだUEFIの（も？）理解が不足しています。 ところで、操作性上の細かなことですが、リブート時にPCの前にいると、 選択画面が出ている時、デフォルトでいい場合についついEnterキーを叩いたり してしまいます。　これでも「0」同様にデフォルト選択扱いになると、私の 場合は「あ、しまった！」が減りそうです。　ただ、さほど実害がある訳でも ないので、もし「選択肢が10個では足りない」という意見が出てきて複数文字 入力＋Enterで対応する手を入れざるを得なくなった場合に「Enterの前が空か ゼロならデフォルト」という処理を入れる方が良いかもしれません。 ※個人レベルだとそうそう無いとは思いますが、10台とかそれ以上のドライブで 　RAID構成されたサーバだと、ひょっとして...。 ※人によってはESCキーかもしれませんが、こちらはUEFIファームウェアや端末の 　構成しだいでエスケープシーケンス入力でないことを確認するためのタイム 　アウト待ち状態に入ってしまう可能性がありそうですので、厄介そうです。 　Appendix Bを見ていたら若干の不安が。 > 野中 > > > これら2件のテストも絡むと、最低でもテストは問題の出ない環境だけでは > > 足りないのが悩ましいですね。 > > > > 　※Bugzillaの方のComment 4で「FreeBSD Foundationのスポンサード > > 　　プロジェクトのリストに足すべき？」という趣旨のコメントが付いて > > 　　ますが、もしかするとその絡みもあるかもしれませんね。 > > > > > > On Mon, 14 Mar 2016 19:58:35 +0900 > > Naomichi Nonaka wrote: > > > >> 青木様 > >> > >> 試していただきありがとうございます。他の環境でも動いているようでほっと > >> しました。 > >> > >> タイムアウトは最初は入れるつもりだったのですが、とりあえず動いた所で > >> やる気が切れて(^^;;、そのままになってます。 > >> > >> 尚、既に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 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 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-unsubscribe@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-unsubscribe@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-unsubscribe@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-unsubscribe@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-unsubscribe@freebsd.org" > -- 青木 知明 [Tomoaki AOKI] junchoon@dec.sakura.ne.jp MXE02273@nifty.com