From owner-freebsd-users-jp@freebsd.org Thu Jul 14 09:54:10 2016
Return-Path: <owner-freebsd-users-jp@freebsd.org>
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 94F33B92E3A
for <freebsd-users-jp@mailman.ysv.freebsd.org>;
Thu, 14 Jul 2016 09:54:10 +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 649CB1D2A
for <freebsd-users-jp@freebsd.org>; Thu, 14 Jul 2016 09:54:10 +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
u6E9s1U8036851; Thu, 14 Jul 2016 18:54:01 +0900 (JST)
(envelope-from junchoon@dec.sakura.ne.jp)
Date: Thu, 14 Jul 2016 18:54:01 +0900
From: Tomoaki AOKI <junchoon@dec.sakura.ne.jp>
To: freebsd-users-jp@freebsd.org
Message-Id: <20160714185401.e2060a68e5b9d2faaa667bd1@dec.sakura.ne.jp>
In-Reply-To: <20160714034834.GE2499@ginganet.org>
References: <20160713161238.GD2499@ginganet.org>
<48a9b2eb-1b7d-8783-ddc9-30de19f21bad@enuenu.org>
<20160714034834.GE2499@ginganet.org>
Organization: Junchoon corps
X-Mailer: Sylpheed 3.5.0 (GTK+ 2.24.29; amd64-portbld-freebsd11.0)
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit
Subject: [FreeBSD-users-jp 95867] Re:
=?iso-2022-jp?b?aW5zdGFsbGVyIFpGU1Jvb3QbJEIkRyRONS9GMEBfGyhC?=
=?iso-2022-jp?b?GyRCRGobKEI=?=
X-BeenThere: freebsd-users-jp@freebsd.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Discussion relevant to FreeBSD communities in Japan
<freebsd-users-jp.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-users-jp>,
<mailto:freebsd-users-jp-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-users-jp/>
List-Post: <mailto:freebsd-users-jp@freebsd.org>
List-Help: <mailto:freebsd-users-jp-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-users-jp>,
<mailto:freebsd-users-jp-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Jul 2016 09:54:10 -0000
川口様
青木@名古屋です。 一部、佐藤さんの別途コメントとも重複しますが...。
On Thu, 14 Jul 2016 12:48:34 +0900
KAWAGUTI Ginga <ginga-freebsd@ginganet.org> wrote:
> 川口です
（中略）
> はい，誤解を生みやすい表現でした．
> 「partition scheme」はinstallerの
> 「ZFS Configuration」画面における
> 「Partition Scheme」の選択肢の意味でした．
> ( https://www.freebsd.org/doc/handbook/bsdinstall-partitioning.html の
> Figure 2.19)
> たしかに，一般用語と見えてしまうと分かりにくいですね．失礼しました
>
> 改めて確認したところ，この「Partition Scheme」の
> 選択肢は(10.3Rでは)以下の5通りです
> * GPT (BIOS)
> * GPT (UEFI)
> * MBR (BIOS)
> * GPT + Active (BIOS)
> * GPT + Lenovo Fix (BIOS)
この中で、FreeBSDに限らず本来OSのインストーラがサポートすべき最低限は
MBR (BIOS) -- 所謂Legacy BIOS用
GPT (UEFI) -- UEFI用
の２つだけで、他は本来邪道です。
が、GPTは、（本来UEFI非対応のOSをインストールするためではなく）
GPTを理解しないパーティション管理ツールに自らを破壊されるのを予防
するため、PMBRという「見せかけの」MBR管理テープルを用意し、4つある
エントリの一つにGPTで管理する全域を専有するパーティションを登録する
ようになっていて、自身の管理テーブルはそれと重ならない位置に確保して
います。
※BIOSとしてはパーティションタイプは知ったことではなく、(P)MBRの
中の所定の範囲にあるBOOTCODEを読み込んで実行するだけですよね。
重要なのは、MBRしか知らないパーティション管理ツールが「正常な
管理状態にあり、空き容量が残っていない」と認識できることです。
ここで、MBRに書き込むBOOTCODEを、GPTを解して次段のものを探し、読み
出せるものにしてしまえば、UEFI対応でなくとも（GPTを理解する）OSを
起動できるわけで、これがGPT (BIOS)です。 基本的にOS側で対応ローダを
用意する必要がある（BIOSベンダお仕着せのものではできない）ため、
標準ではないのです。
ここまで来て問題になるのが、MBRのActiveフラグの扱いです。
これはMBR時代には必須となっていた訳ですが、GPT用のPMBRでは使わないことに
なっています。
そのため、UEFIファームウェアベンダやマザーボードベンダによって対応が
分かれ、
・UEFI/GPT寄り。 PMBR上のGPTのエントリにActiveフラグが立っている場合
はGPTを騙る不正なパーティションor壊れていると見做して起動させない。
※そのような処理をしていない限り、PMBR上のGPTのエントリもその他大勢
と同じなので、例えば/boot/pmbrが書き込まれ、処理が渡されていれば
freebsd-bootのpartcodeを読み込んで起動できない理由がありません。
・Legacy寄り。 とにかくActiveフラグが立っているパーティション以外、
起動対象としない。
・PMBRの場合、完全にActiveフラグを無視する、又は、PMBRのBOOTCODEの処理
を一切妨げない。
のどれかに該当します。 UEFI寄りに解釈すれば、使わない筈のActiveフラグが
立っていれば管理テーブルが壊れているとも解釈できる訳ですし、Legacy寄りに
解釈すればActiveフラグが立っていないパーティションは「確保はするが使わな
い」訳で、起動対象にはならない、と。 FreeBSDの場合、製品数の多さとGPTの
使用への整合との兼ね合いからと思いますが、Activeフラグ無しがデフォルトに
なっています。
このLegacy寄りの仕様への対応として、+Activeの方が存在するのですが、
実際に使うのがGPTである以上、邪道はこちら（又は、UEFI非対応）です。
※もっとも、UEFI(GPT)非対応の場合、BIOS／ディスクコントローラレベルで
MBR方式で対応できない容量のドライブで異常動作する懸念もあるので、
対応範囲のHDDを接続してMBRで使用すべきです。
+Lenovo Fixはさらに邪道（というより既に変態）で、明確なバグへの対応
です。 GPTのエントリがPMBR先頭にある場合はUEFIでしか起動を許さず、
Legacyで起動するためには2番め〓4番目のどれかにずらす必要があるのです。
存在を明確に確認されているのがLenovo製品のみのためこのような名称になって
いますが、他社品でも同じ問題があるかもしれません。
Lenovoの場合、Activeフラグには無頓着ですが、他社でこの対応が必要になった
場合、Activeフラグの有無が影響するかもしれません。
※実際には、PMBR上のGPTを別の種類に偽装する方法もありますが、こちらは
ローダの改造（偽装したパーティション種別をGPTと認識するようにする）
必要があり、現行のLenovo Fixの手法が採用されています。
> (今回の HP Z840の事情かどうか，は切り分け出来ていませんが，
> 「GPT (BIOS)」ではBIOS側でUEFI disable/Legacy bootにしてもダメ，
> インストールを「GPT (UEFI)」を選択し，
> BIOSでUEFI enable(Legacy bootも許容)，という状態で
> 起動OK,ということです)
その状態は、後段で記載頂いた情報から見ても、普通にUEFI用になっている
かと。 問題なければ、その状態を推奨します。
万一、どうしてもLegacyにしたい（UEFI起動時に限って何らかの問題が
生じた等）場合、まずは+Activeを、駄目なら+Lenovo Fixでトライする
価値はあります。
> > どのようなパーティション操作を行ったかが示されていないので
（中略）
> さらに当然ながら(?)，virtualbox では起動するので
> やはり機種固有の問題(当方がPC側BIOSの設定を間違えている，というパターン含む)，
> かもしれません．
機種固有の問題と思います。
佐藤さんご指摘のように、もし+Activeなら起動できる場合、ブラックリストに
追加してもらう価値が高いと思いますが、いまさら難しいですよね？
>
>
> > >本題は「インストーラでうまく起動できるように
> > >インストールできない(bootコードどこ?)」です．
> >
> > 気を悪くされたらすいませんが、上記は日本語として意味が取れません
> > でした。
>
> 元はUEFIでなくBIOS起動をしようとしていて，
> pmbrが見つからない(?)か何かで，起動できない状態だったという
> 話なので．
> (HDDには入っていても，PCのBIOS側の問題で見つけられない可能性含む)
>
> --
> ∧∧
> Zzz.. (- - )⌒⌒⊇～ 川口 銀河
> ############## ginga-freebsd@ginganet.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