退役後、数年間使用していなかった FreeBSD サーバーの内容を確認した後、パーツに分けて処分しようかと考えていたところ。
ハードウェアの動作は問題ないのですが、OS のバージョンが退役時の10.x で止まっています。中身のファイルを確認したところ、いろいろ試したくなってきました。処分前にもう一度がっちり働いていただきましょう。
理由は、現時点では数少なくなった 32bit FreeBSD であること。CPUが Pentium III 700MHz なので、OSが32bit になるのは必然。マザーボードは、P3B-Fで、自由度が大変高くて素直なボード。
今、手元で稼働している 32bit FreeBSD は Raspberry Pi2 上の FreeBSD/arm だけで、こいつがしばしば問題を起こしてくれます。Intel系CPUのホストはメンテナンスの関係ですべて 64bit FreeBSDにしてしまったので、現在、32bit FreeBSDでのテスト環境がない状態。いい機会なので、ばらす前に FreeBSD 10.x を 13.3 に上げて、その過程を記録しておこうと考えました。
よくある話だと思いますが、しばらく放置していたホストを久しぶりに起動したら、OSが古くなりすぎて、ちゃんと動かない！てことがあります。FreeBSD は守備範囲が広いものの、さすがにメージャーバージョンが3つ違うと、何にもできない。パッケージを更新しようとしたら、 pkg コマンドで古くなったパッケージをリストアップできるものの更新しようとするとエラーになる。メンテナンスするためのコマンドが動かないわけ。
バイナリーメンテナンスは、FreeBSD10では有効のはずなんですが、サーバー側が見捨ててしまった模様。
いっその事、/usr/src に最新ソースを展開して、全体をビルドし直す方が早くないか？と git を入れようとするものの、pkg コマンドがちゃんと動かないので、この方法は終了。
古いメンテナンスコマンドが動かない原因はいろいろありますが、
- 暗号通信ライブラリが古くなりすぎている
- 同様に https 通信がエラーになる
- 設定項目の記述が、すでに無効になっている。フォーマットが異なる。
などなどでしょう。
やむを得ず、OSの方を freebsd-update コマンドで先に上げた後、パッケージ を pkg コマンドで更新する。最後にソースレベルで buildworld を行う という手順でメンテナンスを開始することにしました。
FreeBSD12系は 2023/12 までサポートされていたので、その後半年経過しているものの、まだサーバーにファイルは残っているだろうと、freebsd-update で 12.4 系最終バージョンに上げることにしました。そのあとでソースビルドを試そうと考えました。
freebsd-update コマンドで 10.x → 12.4 に上げるのは簡単。
しかし、10.x 時代の pkg コマンドは結果表示は出来てもメンテナンスオプションはエラーとなる。。。。
こういう時は、pkg-static コマンドで pkg を初期化。
しようとしたけど、
pkg-static: Repository FreeBSD load error: access repo file(/var/db/pkg/repo-FreeBSD.sqlite) failed: No such file or directory pkg-static: http://pkg.FreeBSD.org/FreeBSD:12:i386/quarterly/meta.txz: Not Found
エラーとなって、10.x の pkg ツールを更新出来ない！理由は、エラーの通り、pkg の管理構造自体が変わっているため。サーバー上から、すでに FreeBSD12 のメンテナンスファイルは片付けられているもよう。消されてはいないでしょうが、別のどこかに引っ越しされた後なんでしょう。場所が分かれば .conf ファイルをいじるという手もありますけど、諦めて、12.4 → 13.2 に上げることにしました。
12.4 までちゃんとパッケージメンテナンス出来ていれば、おそらく 12.4 から 13.x へのソースビルドで上げられたんでしょうけど、10.x で休眠していたサーバーから途中バージョンへの更新は難しいようです。
FreeBSD13.2 は先日まで使っていたサーバーOSなので、勝手知ったるところではありますが、バイナリーメンテナンスが終了した 32bit FreeBSD 12.4 を freebsd-update コマンドで 13.2 に上げられるのか？恐らく、パッチレベルメンテナンスは行ってくれないでしょうけど、メジャーアップデートは、サーバーからベースとなるバージョンをダウンロードして切り替えるだけだからいけるんじゃない？と試すことに。（確か、先日 AthlonXP で同じことをやって痛い目を見た記憶があるけど、CD-Rを焼くか、これしか、13.x に上げる方法がないわけですからね。）
13系の最新は13.3ですが、13.2に上げようとしているのは、ソースビルドで 13.2 → 13.3 に上げる検証を行いたいため。
freebsd-update -r 13.2-RELEASE upgrade
で、無事に 13.2 に上げることに成功。
FreeBSD pc61.lifewithunix.jp 13.2-RELEASE-p11 FreeBSD 13.2-RELEASE-p11 GENERIC i386
リブートして、2回目の「freebsd-update install」を発行後、10.x 時代にインストールした pkg を更新する必要があるので、「pkg upgrade」を発行したら、
# pkg upgrade ld-elf.so.1: Shared object "libssl.so.7" not found, required by "pkg"
となって、10.x の pkg が動かない。pkg コマンド自体を新しくするには、
# pkg bootstrap -f The package management tool is not yet installed on your system. Do you want to fetch and install it now? [y/N]: y Bootstrapping pkg from pkg+http://pkg.FreeBSD.org/FreeBSD:13:i386/quarterly, please wait... Verifying signature with trusted certificate pkg.freebsd.org.2013102301... done Installing pkg-1.21.3... Extracting pkg-1.21.3: 100%
これで、pkg も 13.x系に上がりました。
続いて、「pkg upgrade -y」とやったところ、うれしいことにコマンドが進む。phpなどは、メジャーバージョンアップが必要でしょうけど、pkg コマンドが使えるようになれば何とかなりそう。
FreeBSD の更新を完了させるため、「pkg upgrade -y」が終了したところで3回目の「freebsd-update install」を発行。
13.2 への更新が終わりました。この後は、pkg に関してはバイナリーメンテナンス可能なものの、OS本体はソースメンテナンスになります。
そのため、pkg コマンドで git をインストールし、その後 git コマンドを使って /usr/src をダウンロードしてきます。手順に関しては前のメモ通り。
しかし、ここでまた一旦停止。
/usr/src を作る git clone コマンド実行中にエラーが出る！
# git clone --branch releng/13.3 https://git.freebsd.org/src.git /usr/src Cloning into '/usr/src'... remote: Enumerating objects: 4514886, done. remote: Counting objects: 100% (382956/382956), done. remote: Compressing objects: 100% (28627/28627), done. remote: Total 4514886 (delta 377241), reused 354329 (delta 354329), pack-reused 4131930 (from 1) Receiving objects: 100% (4514886/4514886), 1.64 GiB | 1.43 MiB/s, done. Resolving deltas: 100% (3589889/3589889), done. fatal: did not receive expected object c04300d4913e87e9b2a378af8f52212d53f49375 fatal: fetch-pack: invalid index-pack output
fatal error なので、細かいことはわからない。わかるのはダウンロードしたファイルが壊れていて、しかも修正や再送が出来ないってこと。
再実行。
しかに、2回目も同様の現象。オブジェクト名は少し違っていますけど、原因は同じところにありそう。
# git clone --branch releng/13.3 https://git.freebsd.org/src.git /usr/src Cloning into '/usr/src'... remote: Enumerating objects: 4514891, done. remote: Counting objects: 100% (382956/382956), done. remote: Compressing objects: 100% (28627/28627), done. remote: Total 4514891 (delta 377243), reused 354329 (delta 354329), pack-reused 4131935 (from 1) Receiving objects: 100% (4514891/4514891), 1.64 GiB | 1.80 MiB/s, done. Resolving deltas: 100% (3589894/3589894), done. fatal: did not receive expected object 98e40282ac70a249f18a79c2566e0ba2d4fbdee9 fatal: fetch-pack: invalid index-pack output
使っているパッケージの問題？と、一度 python と git と openssl を抜いて、入れ直してみましたが、3回目の結果も同じ。
git サーバー側の問題？切り分けるために、13.2 ブランチのダウンロードを実行中。もし、clone が成功すれば、サーバー側に問題がありそう。同様の現象が引き続き発生するなら、ホスト側の問題っぽい。恐らく後者になるでしょうけど、その場合、どう対処すべきか？？なんか、古いOSの時から消えずに残っているライブラリーのような気がするな～。
いずれにせよ /usr/src 下にソースをコピーできないとOSメンテナンスが出来ないわけですから、ソースを ftp でダウンロードして手動で展開し、ビルドする方法しか残っていない。しかし、この方法で展開した場合、git でソース管理が出来なくなる。
Tier2 となった 32bit FreeBSD でのメンテナンスを確認したいだけだったのに、四苦八苦しています。放置していたOSを再び管理しようとすると、ものすごく大変。
13.2のソースコードダウンロードで試した結果は、
# git clone --branch releng/13.2 https://git.freebsd.org/src.git /usr/src Cloning into '/usr/src'... remote: Enumerating objects: 4514909, done. remote: Counting objects: 100% (382956/382956), done. remote: Compressing objects: 100% (28627/28627), done. remote: Total 4514909 (delta 377240), reused 354329 (delta 354329), pack-reused 4131953 (from 1) Receiving objects: 100% (4514909/4514909), 1.64 GiB | 1.58 MiB/s, done. Resolving deltas: 100% (3589906/3589906), done. fatal: did not receive expected object 76000156fece7c82626e3b7f8a37b046ea965308 fatal: fetch-pack: invalid index-pack output
やっぱり、fatal error。
パソコン側の問題っぽい。オプションパッケージを全部抜いてOSインストール直後と似た状況にすれば、ひょっとするとクローン出来るかも。と、思うものの、それって意味があることなのか？
FreeBSD.org の方針によりバイナリーメンテナンスから外れてソースメンテナンスとなった FreeBSD/x86 の再活用方法を知りたいためのテストなので、クリーンインストールしたOSをソースメンテナンス出来たとしても、「あっそ」と思ってしまう。活用を続けてきて、いろんなものが入ってしまっているOSのメンテナンスを継続出来て初めて情報に価値が出てくると思います。
/usr/src をクローン出来る別のホストから /usr/src や /usr/obj をエクスポートするとか rsync するとかという手があるにはあって、以前Raspbery Pi2 x2 で実際やってました。
一度、/usr/src を作ってしまえば、あとは git で管理できるなら、別ホストの /usr/src を rsync するのが楽かも。
一旦 git は諦めて、
http://ftp.jp.freebsd.org/pub/FreeBSD/releases/i386/13.3-RELEASE/src.txz
からソースをダウンロードして、/usr/src に展開することにしました。ソースコードのアップデートをどうするか課題ですが、まずはソースコードから 13.3 への更新を試したところ、またまた予想外の結果が。
ダウンロードしたばかりのソースから make buildworld がエラーになる。しかも、文法などのエラーじゃなく、原因不明のエラー。（以下）
1. parser at end of file 2. Code generation 3. Running pass 'Function Pass Manager' on module '/usr/src/contrib/llvm-project/llvm/utils/TableGen/AsmMatcherEmitter.cpp'. 4. Running pass 'Early Tail Duplication' on function '@_ZN4llvm23SmallVectorTemplateBaseINS_2cl6parserIPFvRNS_12RecordKeeperERNS_11raw_ostreamEEE10OptionInfoELb0EE28reserveForParamAndGetAddressERKSA_j' #0 0x04779724 (/usr/bin/c+++0x4779724) #1 0x04779ba0 (/usr/bin/c+++0x4779ba0) #2 0x0477794e (/usr/bin/c+++0x477794e) #3 0x0472ac63 (/usr/bin/c+++0x472ac63) #4 0x25cc1309 (/lib/libthr.so.3+0x18309) c++: error: clang frontend command failed with exit code 139 (use -v to see invocation) FreeBSD clang version 14.0.5 (https://github.com/llvm/llvm-project.git llvmorg-14.0.5-0-gc12386ae247c) Target: i386-unknown-freebsd13.2 Thread model: posix InstalledDir: /usr/bin c++: note: diagnostic msg: ******************** PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: c++: note: diagnostic msg: /tmp/AsmMatcherEmitter-d44107.cpp c++: note: diagnostic msg: /tmp/AsmMatcherEmitter-d44107.sh c++: note: diagnostic msg: ******************** *** Error code 139 Stop.
ソースビルドも出来やしない。この症状、一般的にはハードウェア不良が原因でエラーが出る場合に似ています。
この次一体どうすりゃいい？
x86 CPUの場合、freebsd-update コマンドによるバグフィックスは出来ないものの、メジャーバージョンアップはできると判明。
過去、Tier2 状態のRaspberry Pi2 で freebsd-update コマンドを試した時は、サーバーが見つからずにコマンドが終了したため、Tier2 x86 FreeBSDも同じだろうと思っていたのですが、13.2 → 13.3 の更新は出来る模様。脆弱性が見つかった場合はソースメンテナンスしなくちゃいけませんが、freebsd-update で 13.3 に上げてみることにしました。そして、それが最低の結果を招く。
freebsd-update コマンドで 13.3 に上げたあと、最後の再起動を掛けたところ、OSが上がってこない。
panic と 再起動のループに入ってしまいました。が～ん。
ブート画面で一旦停止させ、一つ前のカーネル kernel.old で起動。
root でログインして、「freebsd-update rollback」で、元に戻しました。
13.2 でもう少し調査しようと思って、uname -a コマンドを発行したら。なぜか 12.4 にまで戻ってしまった。
FreeBSD p3bf.lifewithunix.jp 12.4-RELEASE-p6 FreeBSD 12.4-RELEASE-p6 GENERIC i386 1204000 1204000
なぜだ～。
今のファイルシステムのままでは、完全に行き詰まってしまった。
もう一度、freebsd-update コマンドで、12.4 から 13.3 へ上げることにしました。今度は簡単に 13.3 に上がった。上がっちゃったから、32bit OSのソースでの更新テストは不要になりました。
大変だった割に、何の進展もなかったわ。
日を改めてゆっくり思い出してみると、ftp でソースコードをダウンロードし、/usr/src に展開し make buildworld してもビルドが失敗する症状。メモリに不具合がある場合に起きやすいことは、過去に何度も体験済み。メモリ認識やOS実行には問題なくても、特に高負荷になっているわけでもないのに、突然プロセスが終了するようなことが起きることがあります。短時間のメモリチェックでは検出できないものの、特定のメモリアクセスパターンでアクセス不良が起きることは稀に起きる既知の現象。必ずしもメモリの不良じゃなくて、マザーボードとの相性と言わざるを得ない問題。配線レイアウトの関係などでノイズが貯まるようなパーツの組み合わせが出てしまう。インストールしているメモリモジュールの位置を変えたりすると現象が変化する場合もあります。メモリバンクを変えながら git clone を試せば切り分けできるかもしれませんが、git clone は1回で2時間くらい掛かる作業。または、何時間もかけてメモリテストプログラムを走らせれば、git clone じゃなくても再現できるかもしれないけど、さすがにやってられない。
やるなら、現在 72pin DIMM x 4 で構成しているメモリシステムを、容量を減らしてでも安定するスピードのDIMMに丸々替えてみること。
古いPCパーツの整理中なので、長期間保管していたメモリと全取換えしてみようと考えました。
256MB x 4 構成を、（これしかなかったので）128MB x3 + 64MB = 448MB で git clone を実行してみることにしました。
結果は、
/usr/src # git clone --branch releng/13.3 https://git.freebsd.org/src.git /usr/src Cloning into '/usr/src'... remote: Enumerating objects: 4521820, done. remote: Counting objects: 100% (383009/383009), done. remote: Compressing objects: 100% (28645/28645), done. remote: Total 4521820 (delta 377295), reused 354364 (delta 354364), pack-reused 4138811 (from 1) Receiving objects: 100% (4521820/4521820), 1.64 GiB | 1.57 MiB/s, done. Resolving deltas: 100% (3593749/3593749), done. Checking objects: 100% (16777216/16777216), done. Updating files: 100% (91161/91161), done.
なんと、git clone が成功してしまった。原因は DIMM x 4 の中のどれかのモジュールだろうと判明しました。
git clone で、fatal エラーが起きる場合、メモリを疑ってみることも一つの方法かも。
うまくできれば、その後は、/usr/src にて、「make buildworld」 や 「make kernel」を実行することになりますが、シングルコアの Pentium III ではどれくらいかかるか？
ようやく、ソースビルドを試せる環境が出来上がりました。バージョンアップには、もう使えないものの、buildworld は出来そう。
早速 /usr/src にて、「make buildworld」コマンドを発行してみました。
お、遅い。ものすごく遅い。
Raspberry Pi2 の3/4コア使って44時間かかったわけですが、今回はシングルコアで、しかも、周波数は700MHz。72時間以上掛かるんじゃない？
FreeBSD/arm では、画面上を流れるメッセージが滅多に止まりませんでしたが、画面上に表示されるコンパイルの出力を目で追える。というか止まっている。今、PC本体を作業机の上に置いてビルド作業しているので、3日間このままにしておくのはちょっと無理。
その間、PCパーツの動作確認などが出来ないことになりますので、途中で中止しそうな気がする。