From nobody Sat Sep 10 22:03:03 2022 X-Original-To: freebsd-users-jp@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MQ6LR2Ncyz4c7TT for ; Sat, 10 Sep 2022 22:03:11 +0000 (UTC) (envelope-from amogha@www1084.sakura.ne.jp) Received: from www1084.sakura.ne.jp (www1084.sakura.ne.jp [219.94.129.94]) (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 4MQ6LP5spWz43Vw for ; Sat, 10 Sep 2022 22:03:09 +0000 (UTC) (envelope-from amogha@www1084.sakura.ne.jp) Received: from www1084.sakura.ne.jp (localhost [127.0.0.1]) by www1084.sakura.ne.jp (8.15.2/8.15.2) with ESMTP id 28AM34Vj098247; Sun, 11 Sep 2022 07:03:04 +0900 (JST) (envelope-from amogha@www1084.sakura.ne.jp) Received: (from amogha@localhost) by www1084.sakura.ne.jp (8.15.2/8.15.2/Submit) id 28AM3458098246; Sun, 11 Sep 2022 07:03:04 +0900 (JST) (envelope-from amogha) X-Mailer: emacs 24.5.1 (via feedmail 11-beta-1 I) From: masa@amogha.jp (=?iso-2022-jp?B?GyRCNF07M0Q+PjsbKEI=?=) To: freebsd-users-jp@freebsd.org Subject: Re: loader.efi of 13.1 In-Reply-To: (masa@amogha.jp) Organization: =?iso-2022-jp?B?GyRCNF07M0Q+PjskTjtkRSo7SE1RJSIlSSVsJTkbKEI=?= Reply-To: masa@amogha.jp Date: Sun, 11 Sep 2022 07:03:03 +0900 Message-ID: List-Id: Discussion relevant to FreeBSD communities in Japan List-Archive: https://lists.freebsd.org/archives/freebsd-users-jp List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-users-jp@freebsd.org X-BeenThere: freebsd-users-jp@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp X-Rspamd-Queue-Id: 4MQ6LP5spWz43Vw X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of amogha@www1084.sakura.ne.jp has no SPF policy when checking 219.94.129.94) smtp.mailfrom=amogha@www1084.sakura.ne.jp X-Spamd-Result: default: False [-1.80 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; FORGED_SENDER(0.30)[masa@amogha.jp,amogha@www1084.sakura.ne.jp]; MIME_GOOD(-0.10)[text/plain]; FROM_NO_DN(0.00)[]; MLMMJ_DEST(0.00)[freebsd-users-jp@freebsd.org]; HAS_REPLYTO(0.00)[masa@amogha.jp]; R_DKIM_NA(0.00)[]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[amogha.jp]; HAS_ORG_HEADER(0.00)[]; ASN(0.00)[asn:9371, ipnet:219.94.128.0/17, country:JP]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; REPLYTO_DN_EQ_FROM_DN(0.00)[]; TO_DN_NONE(0.00)[]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FROM_NEQ_ENVFROM(0.00)[masa@amogha.jp,amogha@www1084.sakura.ne.jp] X-ThisMailContainsUnwantedMimeParts: N 丸山です。 loader.efi の挙動を理解するために行った「大袈裟な」実験の続きです。 実験3 ada0p4(ufs, 純正ロゴ) ada0p5(zfs, 純正ロゴ) ada0p6(ufs, 偽ロゴ) ada0p7(zfs, 偽ロゴ) をすべて復活させ、 ada0p4 の loader.conf の zfs_load="YES" を削除して loader.efi を起動する。 3.0 何もせず、Welcome 画面でタイムアウトさせる ==> ada0p4上のシステムが起動 3.1 OK boot ==> ada0p4上のシステムが起動 以上二つの場合、システム起動後に kldstat で見ると zfs.ko は無い。 (ada0p4の /etc/rc.conf に zfs_enable="YES" は無い) 3.2 OK set currdev=zfs:zboot1/ROOT/default: OK boot ==> 画面には大量のメッセージ、通常のシステム起動時に見られる dmesg と同種のもの、が流れるが最終的に mountroot> プロンプトで止まる。 止まる前の10行ほどを見ると Loader variables: vfs.root.mountfrom=zfs:zboot1/ROOT/default Manual root filesystem specification: などが見える。mountroot> プロンプトに対して zfs:zboot1/ROOT/default と入力すると Trying to mount root from zfs:zboot1/ROOT/default []... Mounting from zfs:zboot1/ROOT/default failed with error2: unknown file system となって成功しない。 3.3 OK set currdev=disk2p6: OK boot ==> ada0p6上のシステムが起動。システム起動後に kldstat で見ると zfs.ko は無い。 3.4 OK set currdev=zfs:zboot2/ROOT/default: OK boot ==> 3.2と同様成功しない。 3.5 OK set currdev=zfs:fbsd131pc06/ROOT/default: OK boot ==> 3.2と同様成功しない。 なお、3.2, 3.4, 3.5 で mountroot> プロンプトが出たところで、 ufs:/dev/ada0p4 と入力すると adap04 のシステムが起動する。 ada0p4 の /etc/rc.conf に zfs_enable="YES" を入れても 3.2 〜3.5 の結果 は 変わらない。3.0, 3.1 では kldstat で zfs.ko が表示される。 実験4 ada0p4 を削除し、 ada0p5 の loader.conf の zfs_load="YES" を削除 4.0 何もせず、Welcome 画面でタイムアウトさせる ==> 3.2と同様症状で成功しない。 4.1 OK boot ==> 3.2と同様症状で成功しない。 OK プロンプトから show コマンドで見ると、 loaddev と currdev の値は zfs:zboot1/ROOT/default: となっている。rootdev という変数は見当たらない。 4.2 OK set currdev=disk2p6: OK boot ==> ada0p6 のシステムが正常起動する。起動後に kldstat で見ると zfs.ko は無い。 4.3 OK set currdev=zfs:zboot2/ROOT/default: OK boot ==> 3.2と同様症状で成功しない。 4.4 OK set currdev=zfs:fbsd131pc06/ROOT/default: OK boot ==> 3.2と同様症状で成功しない。 ada0p5 の /etc/rc.conf に zfs_enable="YES" を入れても 4.0 〜 4.4 の結 果は 変わらない。 注目すべきは 4.2, 4.3 あたりでしょう。 私は8月中にこのMLに書いた時点では勘違いしていたのですが、 mountroot> プロ ンプトは loader.efi では無く、 kernel が出しているわけですよね。一連の実 験は loader.efi は zfs を読むことができることを示していますが、 loader.efi がカーネルをロードしたとき、そのカーネルが zfs を理解できて ルートファイルシステムとしてマウントできるかどうかは、カーネルに付随して zfs.ko がロードされているかどうかにかかっていて、それはloader.efi が読み 込んだ /boot/loader.conf に zfs_load="YES" があるかどうかによる、という ことでしょう。カーネルが /etc/rc.conf を読み込むのはルートファイルシステ ムのマウントが終わった後でしょうから、 /etc/rc.conf にzfs_enable="YES" を入れても、 /boot/loader.conf に zfs_load="YES" 欠落していることの代用 にはならない、と考えるとすべての辻褄が合います。 -------- 丸山 直昌 まるやま なおまさ メールアドレス： masa@amogha.jp