とあるサーバにrailsを入れる必要が出てきたんですが、こんなエラーでpumaが起動後お亡くなりになります。その原因の調査。

> bundle exec puma
/home/issei/cure_heart/vendor/bundle/ruby/3.2/gems/puma-6.6.0/lib/puma/puma_http11.so: [BUG] Segmentation fault at 0x0000000000000000
ruby 3.2.7 (2025-02-04 revision 02ec315244) [amd64-freebsd13]

-- Control frame information -----------------------------------------------
c:0012 p:---- s:0053 e:000052 TOP    [FINISH]
c:0011 p:---- s:0050 e:000049 CFUNC  :require
c:0010 p:0011 s:0045 e:000044 METHOD :37
c:0009 p:0035 s:0039 e:000038 TOP    /home/issei/cure_heart/vendor/bundle/ruby/3.2/gems/puma-6.6.0/lib/puma.rb:12 [FINISH]
c:0008 p:---- s:0036 e:000035 CFUNC  :require_relative
c:0007 p:0017 s:0031 e:000030 TOP    /home/issei/cure_heart/vendor/bundle/ruby/3.2/gems/puma-6.6.0/lib/puma/cli.rb:6 [FINISH]
c:0006 p:---- s:0028 e:000027 CFUNC  :require
c:0005 p:0011 s:0023 e:000022 METHOD :37
c:0004 p:0005 s:0017 e:000016 TOP    /home/issei/cure_heart/vendor/bundle/ruby/3.2/gems/puma-6.6.0/bin/puma:6 [FINISH]
c:0003 p:---- s:0013 e:000012 CFUNC  :load

--中略--
   0x85d9f7000    0x85da37000 rw-   64   64   1   0 ---- df 
   0x85e437000    0x85e439000 r--    2    2   3   0 ---- vn /usr/local/bin/ruby32
   0x85fa00000    0x85fde4000 r--  996  996   5   2 ---- vn /usr/local/lib/libruby32.so.32
   0x8607e4000    0x860804000 r--   32   32  47  20 ---- vn /lib/libthr.so.3
   0x861804000    0x8619dd000 r--  473  473  79  34 ---- vn /lib/libc.so.7
   0x8627dd000    0x8629d1000 r--  500  500   3   1 ---- vn /lib/libcrypto.so.7
   0x864800000    0x864ae6000 r--  742  742  39  14 ---- vn /lib/libcrypto.so.111
   0x8668e6000    0x86697b000 r--  149  149  39  14 ---- vn /usr/lib/libssl.so.111
0x1a2e9affd000 0x1a2e9b004000 r--    7   29  61  17 CN-- vn /libexec/ld-elf.so.1
0x1a2e9b004000 0x1a2e9b01a000 r-x   22   29  61  17 CN-- vn /libexec/ld-elf.so.1
0x1a2e9b01a000 0x1a2e9b01b000 r--    1    1   1   0 ---- df 
0x1a2e9b01b000 0x1a2e9b01c000 rw-    1    0   1   0 C--- vn /libexec/ld-elf.so.1
0x1a2e9b01c000 0x1a2e9b01e000 rw-    2    2   1   0 ---- df 
0x7ffffffff000 0x800000000000 r-x    1    1 183   0 ---- ph 

Abort (core dumped)

結論から先に言っておきます。これFreeBSDの秘伝のタレの問題でした。古いライブラリがバージョンアップで削除されていない問題です。

どうしてそこに至ったかというと、エラーからしてなんかSSL関係っぽいから。

で調べてみるとありました。めっちゃ古いファイルが。

$ ls -l /lib/libcrypt*
-r--r--r--  1 root  wheel    53264 May 18 10:09 /lib/libcrypt.so.5
-r--r--r--  1 root  wheel  3039112 May 18 10:09 /lib/libcrypto.so.111
-r--r--r--  1 root  wheel  2046848 Jun 13  2016 /lib/libcrypto.so.7
-r--r--r--  1 root  wheel  2046848 Jun 13  2016 /lib/libcrypto.so.7

/usr/libにもありました。

lrwxr-xr-x 1 root wheel 19 Nov 12 2014 libcrypto.so -> /lib/libcrypto.so.7

/lib/libcrypto.so.7を削除して、ln -s ../../libcrypto.so.111 /usr/lib/libcrypto.so を実行。pumaを再ビルドしたら無事に起動しました。

そもそもなんでこうなってしまったのか？まともにメンテをしてなかったからかもしれませんが、とにもかくにもfreebsd-updateで運用しているとよくあるんですよ。というかbashでもつい最近あったわけで。こういうエラーに遭遇しちゃうと知らないと解決が大変で・・・

とにかく、/libおよび/usr/libのタイムスタンプが異様に古いものは古いバージョンのものの可能性があるので削除。あるいは新しいものにsymbolic linkを切り替え。これが基本です。こんな古いライブラリが必要になるケースなんてほとんどないはずですし、そもそもメンテされてないライブラリを使っているアプリがあること自体ナンセンスです。

あと、ついでだから今このバージョンで真っ新からインストールしたらどのような配置になるのか。それを調べる方法も書いておきます。以下の場所にbase.txzってファイルがあるかと思います。ベースシステムはこの中に全部入っています。これをダウンロードしてきます。

https://download.freebsd.org/ftp/releases/amd64/13.5-RELEASE/

このファイルはタダのtarファイルなんで中身を見ることができます。全部見ると大変なんで ./libだけとってきて、さらにファイルを出力します（ディレクトリの最後の/はとりのぞく。これはあとでfindの結果と比較するため）。これが最新のbaseシステムです。

tar tfz /usr/dist/13.5-RELEASE/base.txz ./lib ./usr/lib | sed -e 's/\/$//' | sort > /base.list

これを find ./lib した結果と比較すればOKです。

find ./lib ./usr/lib|sort | diff -c base.list -

OpenAIにイラスト描いてもらいました。pumaに乗ってます。

秘伝のタレのように継ぎ足しながら運用しているFreeBSDにありがちな問題。以前もあったんですが、またまたupgradeで動かない問題。今回は以下のようなエラーが発生しました

# bash
ld-elf.so.1: Undefined symbol "rl_sort_completion_matches" referenced from COPY relocation in /usr/local/bin/bash

こんな感のエラーです。例によって問題は/lib以下に残っている古いライブラリなんでしょうけど、この探り方についてのメモを残しておきます。まずこのエラーが一体なんなのか？という説明。

多くのプログラムはdynamic linkというものを使ってビルドされています。これは実行時にlibraryをリンクするというもので最近の主流となっているものです。これの真逆はstatic linkで実行ファイルを作成するときにlibraryも一緒にリンクしちゃうことです。dynamic linkにすることでバイナリサイズを小さくできますし、ライブラリにバグが見つかったときでもライブラリだけの更新で済むと言う利点があります。

一方、dynamic linkは正しくlinkされないとダメということで同じ名前のライブラリが別なディレクトリなどにあったりするとうまく整合性が取れずこのようなエラーが発生している・・と予想できます。

実行ファイルやライブラリには、プログラム本体の他に「シンボル」と呼ばれる情報があります。シンボルというのは簡単にいえば関数名のようなもので、実行ファイルとライブラリのシンボル名を実行時にリンクして解決することで初めてプログラムがメモリ上に配置され実行できるようになるわけです。それを出力するコマンドが nmです。

nm -D /usr/local/bin/bash

を実行すると以下のような箇所がありました。

00000000002fac00 B rl_signal_event_hook
00000000002fabdc B rl_sort_completion_matches
00000000002f7b00 B rl_special_prefixes
00000000002fac10 B rl_startup_hook

左の数字はプログラムにおけるアドレスで右がシンボルになります。真ん中のBがそのシンボルの状態を表す記号。この場合BですのでBSSセクションに配置されているということになります。BSSセクションとはなんぞや？とかなるとリンカ沼にハマるので詳しくは解説しません・・（というか解説できません。私が知ってるのはDATAとかTEXTとか古くからあるやつだけでこいつらはプレステでゲーム作ってるときは重要だった。今はどうなんだろ？）。まぁ状態ということで認識しておけばよいかと思います。ちなみにBは解決済みです。じゃぁなんでエラーがでるんでしょうか？

そこでエラーメッセージに戻ります

COPY

の文字。これは「COPY relocation」という仕組みに関するエラーで領域はプログラム側に予約されているけれど、実体はライブラリ側にあるということです。それがうまく解決できていないと。

名称からしてreadlineの保管の問題っぽいので /libのあたりから探りをいれていきます。

ldd コマンドで何がリンクされているのかを確認します

# ldd /usr/local/bin/bash
/usr/local/bin/bash:
 libreadline.so.8 => /lib/libreadline.so.8 (0x3762cef30000)
 libhistory.so.8 => /usr/lib/libhistory.so.8 (0x3762cf42e000)
 libncursesw.so.9 => /lib/libncursesw.so.9 (0x3762d0296000)
 libintl.so.8 => /usr/local/lib/libintl.so.8 (0x3762d1029000)
 libdl.so.1 => /usr/lib/libdl.so.1 (0x3762d1e18000)
 libc.so.7 => /lib/libc.so.7 (0x3762d2de0000)
 libncurses.so.8 => /lib/libncurses.so.8 (0x3762d33ca000)
 libthr.so.3 => /lib/libthr.so.3 (0x3762d3d5e000)
 [vdso] (0x7ffffffff650)

ここで/libの下をみてみると

-r--r--r--  1 root  wheel   273064 Aug 28  2018 libreadline.so.8

というファイルがありました。あやしいです。これだけ2018年。

こではFreeBSDのアップデートの仕組みが関係しているようです。FeeBSDはfreebsd-update でアップデートをしたとしても古いライブラリをアップデートの際に削除しないようです（あるいはしていなかった？裏とってません）。つまりバージョンがあがって最新バージョンで無くなったとしてもそのライブラリは残しているわけです。削除してしまうとそのライブラリをリンクして動作していたプログラムが動かなくなるからということかと思いますがこれが秘伝のタレのような運用をしているサーバに悪影響を与えるわけです。

bashに関していえば /usr/local/lib/以下にもpkgから入れられたlibreadlineが存在しています。こちらをリンクするようにすれば解決するものと思われます。念の為コマンドをタイプ

# nm -D /usr/local/lib/libreadline.so.8 | grep rl_sort_completion_
0000000000051114 D rl_sort_completion_matches
# nm -D /lib/libreadline.so.8 | grep rl_sort_completion_

/usr/loca/lib/以下のほうには存在するようです。そこで強引にこちらのライブラリを優先的に検索するようにしてみます

env LD_LIBRARY_PATH=/usr/local/lib bash

はい、動きました。あとは /lib/libreadline.so.8をどうするかだけを考えればよいわけですが、基本的にpkgだけでアプリをいれているサーバなんでそんなものを使っているものが残っているはずもない・・ということでガッツリ削除することにしました。 ls -ltでタイムスタンプで並べ直してみると

-r--r--r--  1 root  wheel   314744 Dec 30  2022 libzfs.so.3
-r--r--r--  1 root  wheel    31800 Dec 30  2022 libufs.so.6
-r--r--r--  1 root  wheel   387320 Dec 30  2022 libncursesw.so.8
-r--r--r--  1 root  wheel   349640 Dec 30  2022 libncurses.so.8
-r--r--r--  1 root  wheel   216728 Dec 30  2022 libedit.so.7
-r--r--r--  1 root  wheel   273064 Aug 28  2018 libreadline.so.8
-r--r--r--  1 root  wheel    37000 Aug 28  2018 libkvm.so.6
-r--r--r--  1 root  wheel     7736 Aug 28  2018 libipx.so.5
-r--r--r--  1 root  wheel  2055072 Aug 28  2018 libcrypto.so.7
-r--r--r--  1 root  wheel   192040 Aug 28  2018 libcam.so.6
-r--r--r--  1 root  wheel  1722192 Apr  9  2014 libcrypto.so.6
-r--r--r--  1 root  wheel    34728 Dec  4  2012 libkvm.so.5
-r--r--r--  1 root  wheel    68360 Dec  4  2012 libmd.so.5

いやー結構ありますね。10年以上前から残っている秘伝のタレlibraryがたくさん・・・

これら全部削除してよいものだと思います。トラブルのもとなので。というか、たまたま動いているだけで、意図せずメンテナンスされていない古いライブラリが使われている可能性もあります。これはこれで問題ですよね？

OpenAIにイラスト描いてもらいました

FreeBSD-13.0でこのエラーが出ました

ld-elf.so.1: /lib/libcrypto.so.111: version OPENSSL_1_1_1e required by /usr/local/bin/node not found

FreeBSDのパッチレベルの問題。13.0-RELEASE-p4なら発生しない。

以前書いたブログで「ここに書いてありました」とリンクだけを置いておいたのですがそのリンク先が死亡したようなので、あらためてそのやり方を書きます。parallelsを使ってMacで実験をしました。 この実験では以下の4つのサーバを想定していますが実際には2つだけです。また、実験に用いたFreeBSDのバージョンは12.2-RELEASEです

1. dhcpdが動くFreeBSD（でなくても良いと思うが多分それが楽）。ネットワーク上に1つだけ。10.1.1.1とする
2. tftpが動くFreeBSD（でなくても良いと思うが多分それが楽）。 とりあえず1と同じマシンで動かす。
3. nfsが動いていてFreeBSDのツリーが普通に存在しているFreeBSD（でなくても良いと思うが多分それが楽）。1, 2と同じマシンで動かす
4. ネットワークブートをさせたい機器（mac addressを 00:1c:42:af:07:57とする）今回はUEFIでの実験ですのでParallelsの仮想マシンを作るときにbootのオプションでUEFIの指定をする必要があります。完全ネットワークブートですからHDDは不要です。

dhcpd.confは以下のように記述をしておきます。 

host test {
hardware ethernet 00:1c:42:af:07:57;
fixed-address 10.1.1.100;
next-server 10.1.1.1;
filename "loader.efi";
option root-path "10.1.1.1:/FreeBSD/";
}

意味ですが、00:1c:42:af:07:57のmac アドレスを持つ機器に 10.1.1.100のIPアドレスを振る。次のサーバは10.1.1.1で（１と同じ）そこからtftpを使ってloader.efiというファイルを読み込み、起動できたらrootのツリーは10.1.1.1:/FreeBSD（１と同じ）だよという意味です。

２のサーバは以下の/etc/inetd.confのコメントを外しtftpbootを使えるようにしておきます。

tftp    dgram   udp     wait    root    /usr/libexec/tftpd      tftpd -l -s /tftpboot
tftp    dgram   udp6    wait    root    /usr/libexec/tftpd      tftpd -l -s /tftpboot

そして、/etc/rc.confにinetd_enable="YES"を追加しinetdが起動するようにします。

次に mkdir /tfpbootでtftpbootのディレクトリを作成しその下にloader.efiを/boot/loader.efiからコピーして置いておきます。これで2のサーバはokです。

3のサーバは mkdir /FreeBSDとして /etc/exportsに以下のような行を追加して/etc/rc.confにnfs_server_enable="YES"を追加しておきます。

/FreeBSD -maproot=root -alldirs -network 10.1.1.0/24 -ro

/FreeBSDにて kernel.txzとbase.txzを展開しておいておきましょう。

この状態で４のサーバを起動させるとloader.efiを2のサーバより読みこみ10.1.1.1:/FreeBSDをマウントして、起動すると思います。

FreeBSD12.1でpkg upgrade bashでbashを5.0.16から5.1.4に更新をしたらエラーが出て起動しなくなりました。

# pkg upgrade bash
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
The following 2 package(s) will be affected (of 0 checked):

Installed packages to be UPGRADED:
	bash: 5.0.16 -> 5.1.4
	gettext-runtime: 0.20.1 -> 0.21

Number of packages to be upgraded: 2

2 MiB to be downloaded.

Proceed with this action? [y/N]: y
[1/2] Fetching bash-5.1.4.txz: 100%    1 MiB   1.5MB/s    00:01    
[2/2] Fetching gettext-runtime-0.21.txz: 100%  165 KiB 168.9kB/s    00:01    
Checking integrity... done (0 conflicting)
[1/2] Upgrading gettext-runtime from 0.20.1 to 0.21...
[1/2] Extracting gettext-runtime-0.21: 100%
[2/2] Upgrading bash from 5.0.16 to 5.1.4...
[2/2] Extracting bash-5.1.4: 100%
root@berry:/home/issei # bash
ld-elf.so.1: Undefined symbol "rl_filename_rewrite_hook" referenced from COPY relocation in /usr/local/bin/bash

悩みましたが原因は/libに残っていたこれ

-r--r--r--  1 root  wheel  273064 Sep 18  2018 /lib/libreadline.so.8

2018年のタイムスタンプ。これを削除したら動くようになりました。古いバージョンから何年もバージョンアップしながら運用していたので昔のファイルが残っていたんでしょうね。

dhcpサーバを用意するとか、tftpのサーバを用意するとかnfsのサーバを用意するとか、そのあたりのレガシーな情報は沢山出てくるんですが、その手順通りにbootさせようとしても、エラーで終了しちゃいます。以下のページに答えが書いていました。

Netbooting FreeBSD with PXE/UEFI | FreeBSD developer's notebook

pxebootを指定するのではなくloader.efiを指定するのがポイントのようです。これで難なくbootできました。
（参考までにbootできたのはIntelのNUC7CJYHというNUCです）

Raspberry PIのFreeBSD では freebsd-upgradeが使えません。(2018年12月25日現在)

そこでソースからパッチが配布されたときなど、自分でビルドをしないといけません。当然 Raspberry PI上でのビルドは遅すぎて鼻血が出そうになるので別マシン(母艦)でビルドするのが常套手段ではないかと思います。

FreeBSDでのクロスコンパイルは簡単で makeのパラメータとして、 TARGET, TARGET_ARCH, KERNCONFなどの パラメータをソースツリーで適切に指定してやるだけです。例えば以下のリンクにはSDを母艦でmountして インストール(またはアプデート)するやり方が書いてあります。

Installing and updating FreeBSD 11.0 release on a Raspberry Pi – solence

このようなやりかたでもよいのですが、本ブログでは別のやり方を紹介します。 それは、FreeBSDに標準であるパッケージの管理を利用する方法です。

FreeBSDの pkgは実はシステムのbaseでも使えるようになっています。 そこで、母艦でクロスビルドしbaseのパッケージを作成し、Web上に配置し、 Raspberry PIで pkgコマンドでアップデートをするという作戦です。

作りかた

ソースのチェックアウト

とりあえずチェックアウト先のディレクトリは /home/hogehoge/releng/12.0としておきます

# svn checkout http://svn.freebsd.org/base/releng/12.0 /home/hogehoge/releng/12.0

違うバージョンをビルドしたいときは 12.0を適切なものに置き換えてください。

パッケージの作成

以下のコマンドで行います。

# cd /home/hogehoge/releng/12.0 
# make TARGET=arm TARGET_ARCH=armv6 KERNCONF=RPI2 buildworld 
# make TARGET=arm TARGET_ARCH=armv6 KERNCONF=RPI2 buildkernel
# make TARGET=arm TARGET_ARCH=armv6 KERNCONF=RPI2 packages

各コマンドの意味は説明するまでもないので省略します。母艦のSPECにもよりますが、問題がなければ数時間後に/usr/obj/home/hogehoge/releng/12.0/repo/FreeBSD:12:armv6 以下にbaseのパッケージのレポジトリが作成されます。

このbaseのパッケージレポジトリにあるファイルやリンク(latestというシンボリックリンクがあると思います）をhttpでアクセス可能な場所にコピーします。ここでは

https://pkgbase.guru.gr.jp/FreeBSD-base/FreeBSD:12:armv6

でアクセスできる場所に置いてみました。

Raspberry PIの設定

以下の設定ファイルをラズパイ側で作成します。

/usr/local/etc/pkg/repos/FreeBSD-base.conf:

FreeBSD-base: {
  url: "https://pkgbase.guru.gr.jp/FreeBSD-base/${ABI}/latest",
  enabled: yes
}

updateの実行

Raspberry PI側で

# pkg update -r FreBSD-base 
# pkg upgrade

をするとビルドしたものが（必要なら）インストールされます。 なお、以下のページを参考にしました

PkgBase - FreeBSD Wiki

面倒な点としてfreebsd-updateと違って設定ファイルがマージされないことがあること。 pkgのソースをみると pkg add で設定ファイルをmergeをする仕組みは入っているようですが、 うまい感じにマージをしてくれないファイルが多々ありました。3way mergeが必要なので、１つ前の設定ファイルがなんであるかわからないといけないので、それが分からない以上やむを得ないのかな？という気もします。実際上記wikiでは mergemasterまたは　etcupdateを使えとあります。ただどちらの場合であっても /usr/srcが必須でしょう(未検証)

ただ実際は/etc以下でいじくるファイルはごく一部です。単純に上書きできない場合は当該ファイルが pkgnewという拡張子が付加されて保存されるようなので、私はfindでさがして手動で修正するということにしました。

またbaseに追加された/削除されたというのが判断できないので上記wikiに記述してあるコマンド

$ diff <(pkg rquery -r FreeBSD-base %n) <(pkg query -e '%o = base' %n) | grep "^[<>]"

で判断して手動で追加/削除をする必要もあります。

なお、上記URLは暫く残しておきます。興味がある方は自己責任でどうぞ。

# make TARGET=arm TARGET_ARCH=armv6 DESTDIR=/FreeBSD/rpi2 KERNCONF=RPI2 packages
make[1]: "/FreeBSD/releng/11.2/Makefile.inc1" line 1517: Unassociated shell command "@cd ${KSTAGEDIR}/${DISTDIR} ;  awk -f ${SRCDIR}/release/scripts/mtree-to-plist.awk  -v kernel=yes -v _kernconf=${INSTALLKERNEL}  ${KSTAGEDIR}/kernel.meta ;  cap_arg=`cd ${SRCDIR}/etc ; ${MAKE} -VCAP_MKDB_ENDIAN` ;  pwd_arg=`cd ${SRCDIR}/etc ; ${MAKE} -VPWD_MKDB_ENDIAN` ;  sed -e "s/%VERSION%/${PKG_VERSION}/"  -e "s/%PKGNAME%/kernel-${INSTALLKERNEL:tl}${:U""}/"  -e "s/%KERNELDIR%/kernel/"  -e "s/%COMMENT%/FreeBSD ${INSTALLKERNEL} kernel ${:U""}/"  -e "s/%DESC%/FreeBSD ${INSTALLKERNEL} kernel ${:U""}/"  -e "s/%CAP_MKDB_ENDIAN%/$${cap_arg}/g"  -e "s/%PWD_MKDB_ENDIAN%/$${pwd_arg}/g"  ${SRCDIR}/release/packages/kernel.ucl  > ${KSTAGEDIR}/${DISTDIR}/kernel.${INSTALLKERNEL}${:U""}.ucl ;  awk -F\" '  /name/ { printf("===> Creating %s-", $$2); next }  /version/ {print $$2; next } '  ${KSTAGEDIR}/${DISTDIR}/kernel.${INSTALLKERNEL}${:U""}.ucl ;  ${PKG_CMD} -o ABI_FILE=${WSTAGEDIR}/bin/sh -o ALLOW_BASE_SHLIBS=yes  create -M ${KSTAGEDIR}/${DISTDIR}/kernel.${INSTALLKERNEL}${:U""}.ucl  -p ${KSTAGEDIR}/${DISTDIR}/kernel.${INSTALLKERNEL}${:U""}.plist  -r ${KSTAGEDIR}/${DISTDIR}  -o ${REPODIR}/$$(${PKG_CMD} -o ABI_FILE=${WSTAGEDIR}/bin/sh config ABI)/${PKG_VERSION}"
make[1]: "/FreeBSD/releng/11.2/Makefile.inc1" line 1517: Unassociated shell command "@cd ${KSTAGEDIR}/${DISTDIR} ;  awk -f ${SRCDIR}/release/scripts/mtree-to-plist.awk  -v kernel=yes -v _kernconf=${INSTALLKERNEL}  ${KSTAGEDIR}/kernel.meta ;  cap_arg=`cd ${SRCDIR}/etc ; ${MAKE} -VCAP_MKDB_ENDIAN` ;  pwd_arg=`cd ${SRCDIR}/etc ; ${MAKE} -VPWD_MKDB_ENDIAN` ;  sed -e "s/%VERSION%/${PKG_VERSION}/"  -e "s/%PKGNAME%/kernel-${INSTALLKERNEL:tl}${:U-debug}/"  -e "s/%KERNELDIR%/kernel/"  -e "s/%COMMENT%/FreeBSD ${INSTALLKERNEL} kernel ${:U-debug}/"  -e "s/%DESC%/FreeBSD ${INSTALLKERNEL} kernel ${:U-debug}/"  -e "s/%CAP_MKDB_ENDIAN%/$${cap_arg}/g"  -e "s/%PWD_MKDB_ENDIAN%/$${pwd_arg}/g"  ${SRCDIR}/release/packages/kernel.ucl  > ${KSTAGEDIR}/${DISTDIR}/kernel.${INSTALLKERNEL}${:U-debug}.ucl ;  awk -F\" '  /name/ { printf("===> Creating %s-", $$2); next }  /version/ {print $$2; next } '  ${KSTAGEDIR}/${DISTDIR}/kernel.${INSTALLKERNEL}${:U-debug}.ucl ;  ${PKG_CMD} -o ABI_FILE=${WSTAGEDIR}/bin/sh -o ALLOW_BASE_SHLIBS=yes  create -M ${KSTAGEDIR}/${DISTDIR}/kernel.${INSTALLKERNEL}${:U-debug}.ucl  -p ${KSTAGEDIR}/${DISTDIR}/kernel.${INSTALLKERNEL}${:U-debug}.plist  -r ${KSTAGEDIR}/${DISTDIR}  -o ${REPODIR}/$$(${PKG_CMD} -o ABI_FILE=${WSTAGEDIR}/bin/sh config ABI)/${PKG_VERSION}"
make[1]: Fatal errors encountered -- cannot continue
make[1]: stopped in /FreeBSD/releng/11.2
*** Error code 1

Stop.
make: stopped in /FreeBSD/releng/11.2

create-kernel-packages: _pkgbootstrap .PHONY
.if exists(${KSTAGEDIR}/kernel.meta)
.if ${MK_DEBUG_FILES} != "no"
_debug=-debug
.endif
.for flavor in "" ${_debug}

Index: Makefile.inc1
===================================================================
--- Makefile.inc1       (revision 338621)
+++ Makefile.inc1       (working copy)
@@ -1485,11 +1485,11 @@
                        -o ${REPODIR}/$$(${PKG_CMD} -o ABI_FILE=${WSTAGEDIR}/bin/sh config ABI)/${PKG_VERSION} ; \
        done

-create-kernel-packages:        _pkgbootstrap .PHONY
-.if exists(${KSTAGEDIR}/kernel.meta)
 .if ${MK_DEBUG_FILES} != "no"
 _debug=-debug
 .endif
+create-kernel-packages:        _pkgbootstrap .PHONY
+.if exists(${KSTAGEDIR}/kernel.meta)
 .for flavor in "" ${_debug}
        @cd ${KSTAGEDIR}/${DISTDIR} ; \
        awk -f ${SRCDIR}/release/scripts/mtree-to-plist.awk \