Re: 外付けディスクへのFreeBSD のインストール

From: Tomoaki AOKI <junchoon_at_dec.sakura.ne.jp>
Date: Sun, 11 Jan 2026 01:23:35 UTC
青木@名古屋です。

On Sun, 11 Jan 2026 05:11:02 +0900
丸山直昌 <masa@amogha.jp> wrote:

> Tue, 6 Jan 2026 19:46:20 +0900
> Tomoaki AOKI <junchoon@dec.sakura.ne.jp> writes:
> 
> 丸> 極めて皮肉なことに、内蔵ディスクがFreeBSDだと内蔵ディスクのefiパーティショ
> 丸> ンを壊してしまう可能性があります。13.5amdのインストーラーは結局のところ
> 丸> /usr/sbin/bsdinstall を動かしているだけの話なのですが、こいつがなかなか
> 丸> の曲者で、デバイスを丸ごと一本を割り当てるインストールをやると、ターゲッ
> 丸> トのデバイス上にefiパーティションを作り、 gpt/efiboot0 というラベルを付
> 丸> けます。この時gpt/efiboot0 が既に他のデバイス上にあるかないかのチェック
> 丸> をサボっているのです。そのため内蔵ディスクの方も同じように bsdinstall で
> 丸> 作成されたものですと、newfs_msdos /dev/gpt/efiboot0 をやられてしまって、
> 丸> 見事内蔵ディスクが壊れてしまう、というお粗末。これで一度痛い目を見ました。
> >
> >私はインストール用イメージをLIVE CDモード起動用としてしか使わなくなって
> >久しいためこれは知りませんでした。
> >
> >Bugzillaで報告を上げる(英語でないと駄目ですが)価値はあるかと。
> 
> EOLが近い 13.5の bug report を出してもあまり意味が無いように思います。
> 14.3で試して同じ問題があったら出してみます。13.5の bsdinstall には他にも
> 嫌な問題を見つけています。zfsで起動したシステム上で bsdinstall を使って
> target device 上に zfs でインストールしようとすると、動かしているシステ
> ムのzfs pool を destroy しようとする、というとんでもないやつです。
> /usr/libexec/bsdinstall/zfsboot に問題があり、これは私でも patch を作れ
> るような問題です。
> 
> *** ./usr/libexec/bsdinstall/zfsboot-1  Tue Apr 15 18:37:31 2025
> --- ./usr/libexec/bsdinstall/zfsboot    Mon Dec  8 04:22:53 2025
> ***************
> *** 790,799 ****
>         # NOTE: `-F' required to destroy if partitions still exist.
>         # NOTE: Failure is ok here, blank disk will have nothing to destroy.
>         #
> ! #     f_dprintf "$funcname: Exporting ZFS pools..."
> ! #     zpool list -Ho name | while read z_name; do
> ! #             f_eval_catch -d $funcname zpool "$ZPOOL_EXPORT_F" $z_name
> ! #     done
>         f_dprintf "$funcname: Detaching all GELI providers..."
>         geli status | tail -n +2 | while read g_name g_status g_component; do
>                 f_eval_catch -d $funcname geli "$GELI_DETACH_F" $g_name
> --- 790,800 ----
>         # NOTE: `-F' required to destroy if partitions still exist.
>         # NOTE: Failure is ok here, blank disk will have nothing to destroy.
>         #
> !       f_dprintf "$funcname: Exporting ZFS pools..."
> !       ROOTFS=`df /| tail -1`
> !       zpool list -Ho name | while read z_name; do
> !               echo ${ROOTFS} | grep -q "^${z_name}/" || f_eval_catch -d $funcname zpool "$ZPOOL_EXPORT_F" $z_name
> !       done
>         f_dprintf "$funcname: Detaching all GELI providers..."
>         geli status | tail -n +2 | while read g_name g_status g_component; do
>                 f_eval_catch -d $funcname geli "$GELI_DETACH_F" $g_name

スクリプト全体を読んでいないので間違っている可能性は高いですが、
変数名からするとdestroyするのではなくexportしているだけっぽいです。
ただ、exportした結果busyでなくなってdestroyできるようになってしまって...
という流れは有り得そうに見えます。

Bugzillaで"bsdinstall zfs"をキーワードとしてstatusがNEWかOPENかIN
PROGRESSかのものを検索すると16個ほど引っかかりますね。

 https://bugs.freebsd.org/bugzilla/buglist.cgi?bug_status=New&bug_status=Open&bug_status=In%20Progress&list_id=919788&query_format=advanced&short_desc=bsdinstall%20zfs&short_desc_type=allwordssubstr

ある程度近そうなのはこれですか。

 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214911


> 別の問題ですが、14.3のインストーラーを先ほどちょっと動かしてみたらCtrl-l
> での画面更新が効きませんね。インストーラーを起動してから USBデバイスを刺
> し込んでそのUSBデバイスにインストールする場合、つまりは私のブログの「外
> 付けディスクへのFreeBSD13.5のインストール(その2) 」ではこれ必要なんです
> が、、、。

こちらはもしかするとデフォルトのコマンドラインシェルがtcshから
shに変更されたからかもしれません。 コミットの履歴を追っていないので
間違っているかもしれませんが、確か14系からの変更だったと思います。
もしこれが原因だと、一番安全なのはデフォルトのシェルをtcshに切り戻した
インストール媒体を用意することでしょうか。
試していませんが、インストール媒体がUSB memstickならインストール済みの
FreeBSD環境から(仮に/mnt/にマウントしたとして)/mnt/etc/master.passwd
を編集してrootのシェルを(t)cshに変更し、処理対象をデフォルトから
変更してpwd_mkdbを実行して/mnt/etc/spwd.dbを更新させる感じでしょうか?

もしかするとインストール媒体から起動した後、メニューからシェルに
抜けてtcshを実行、そのtcshからbsdinstallを起動してしまうという手で
何とかなるかもしれませんが、bsdinstallのスクリプト含む全体を把握
していないので、何らかのマーカが残っていておかしなことになるリスク
がありますので、勇気が要りそうです。


> 
> --------
> 丸山 直昌 まるやま なおまさ
> メールアドレス: masa@amogha.jp
> 


-- 
青木 知明  [Tomoaki AOKI]    <junchoon@dec.sakura.ne.jp>