From owner-freebsd-users-jp@freebsd.org Tue Apr 19 12:41:30 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 7FB7EB14ED4 for ; Tue, 19 Apr 2016 12:41:30 +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 4649A1515 for ; Tue, 19 Apr 2016 12:41:29 +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 u3JCfK5L030519; Tue, 19 Apr 2016 21:41:20 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Tue, 19 Apr 2016 21:41:19 +0900 From: Tomoaki AOKI To: freebsd-users-jp@freebsd.org Cc: maruyama@ism.ac.jp Message-Id: <20160419214119.7f47561d73ac7d7d6764fcec@dec.sakura.ne.jp> In-Reply-To: References: <57143EE5.1050108@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 95788] Re: GPT and EFI 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: Tue, 19 Apr 2016 12:41:30 -0000 青木@名古屋です。 既に野中さんがコメントを付けておられますので、若干の補足のみ。 野中さんご紹介のUEFIの部分に加え、下記もご参照下さい。 　https://ja.wikipedia.org/wiki/GUID%E3%83%91%E3%83%BC%E3%83%86%E3%82%A3%E3%82%B7%E3%83%A7%E3%83%B3%E3%83%86%E3%83%BC%E3%83%96%E3%83%AB とはいえ、物理ドライブのパーティション管理が乱立すると「修復の名の下の 破壊」の元になりますので、MBR形式の制約からの逃げ場としてEFI以外にも 採用されるのは極めて合理的ですが。 ちなみに、ブートマネージャの類には、 　・MBRの基本区画1個を専有するもの（例：OS/2 ブートマネージャ） 　・パーティション境界がシリンダ境界で整列しており、（ある容量以降で） 　　最初のパーティションの前にそれなりの量の空きがあるのを利用して、 　　MBR本来の部分からPartitionBootRecordではなく空き部分にインストール 　　した拡張ブートコートを呼び出すもの（例：MBMやFreeBSDのboot0ext） も存在します。　OS/2ブートマネージャからはFreeBSDの起動ができず、 boot0extからFreeBSDを起動するかOS/2ブートマネージャを起動するかを 選んでいたこともありました...。 なお、実装されているかどうかはファームウェア依存ですが、本来、UEFIでは ファームウェア側でブートマネージャを用意し、EFIパーティション内の任意の ローダを選択できるようにもなっています。 　※UEFIファームウェアから見ると、ローダもUEFIアプリケーションの一種。 同じOSを複数インストールするのを許すかどうかはOS自体のライセンスにも 関係するため、UEFIファームウェアとしては起動したローダが複数パーティ ションからの起動選択をサポートするかどうかは管轄外です。 個人的には、メニュー選択可能なのが優、属性をbootonce→bootmeの順で チェックし、最初に引っ掛かったパーティションを起動するのが良、 とにかく最初に見つかったのだけでも起動できるのが可、というところ でしょうか。 なお、UEFIの場合、GPTスキームを理解し、EFIタイプのパーティションから ローダを起動するのは標準機能なのでそれ以外のブートレコードは不要な筈、 非UEFIの場合、MBRの位置にあるPMBRが次段のローダ（FreeBSDのものの場合、 freebsd-bootタイプのパーティション）を探して起動する仕組みのため、 BIOSとしては普通にMBRを読み込んで制御を渡したのと変わりません。 　※これはそのまま、Windoze等がMBRを見た時「壊れている」と認識して 　　自前のもので上書きしてしまい、FreeBSDが起動できなくなるリスクも 　　MBR時代同様に存在することを意味します。 おまけですが、UEFIファームウェアによっては規格どおりのGPTだとLegacy での起動を許さないもの（Lenovo等）があり、PMBRパーティションテーブルの GPTを示すエントリを2番め以降にずらす（gpartでlenovofix属性を付けると こうしてくれます）なりタイプを0xeeから0xefその他に変えるなり（当初、 そのためのパッチを作って対応しました）しないといけなかったりします。 UEFI非対応のBIOSなら無用の苦労でしょうけど。 On Tue, 19 Apr 2016 00:50:45 +0900 maruyama@ism.ac.jp (丸山直昌) wrote: > 統計数理研究所の丸山です。 > > 発端となった問題は既に解決したと思いますが、Subjectを変えて GPT と EFIの > 関係について考えてみたいと思います。私が気になったのは野中さんの > > >GPTスキームは元々(U)EFI規格の一部として作成されたのですが、現状では > >Legasy BIOSとGPTの組合せも(の方が？)多用されており、 > > という部分です。そのあたりの歴史は知らないので、まずは何か参照できる文献 > があればご教示願いたいと思います。 > > それはともかく、GPT を少し知って、 UEFI のことは殆ど知らない私から見ると、 > 歴史はどうであれ、GPTはこれまで広く普及していた「(Microsoft slice)+(BSD > label)」の方式(今ではMBRスキームを呼ぶようになったが)がはらんでいた問題 > を解決しており、例え UEFI規格が無くても、UEFIモードがなくBIOS boot しか > できないマシンであっても、MBRは捨ててGPTに移行すべき、と思えるのです。で > すから、 > > >現状ではLegasy BIOSとGPTの組合せも(の方が？)多用されており、 > > は起るべくして起っている現象であって、そこに敢えて UEFI boot モードの話 > を持ち出す必要もないし、また GPTの規格はLegacy BIOS, UEFIの起動モードと > は独立の規格であるべきだと思うのです。 > > 皆様のご意見を伺いたい。 > > なお、一応「(Microsoft slice)+(BSDlabel)の方式がはらんでいた問題」の中で > 特に重大なものをここに書いておくと、 > > 1. Microsoft slice のアドレス指定は 32ビットであって、2TBを越えるストレー > ジでは、アドレス指定が不可能になる。(/usr/include/sys/diskmbr.h 或いは > /usr/src/sys/boot/i386/boot0/boot0.S 参照) > > 2. stage 1 boot code の大きさが 15 sector(7680バイト)に制限されていて、 > 自由が効かない。 > > 3. (2と実質同じ意味だが)boot manager を特定のOSパーティションの中に埋め > 込まざるを得ず、その OSパーティションを削除すると、他のOSパーティショ > ンまで起動困難になる。 > > -------- > 丸山直昌＠統計数理研究所 > _______________________________________________ > 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