FreeBSD 12.0-RELEASEに更新後、Samba 4.8を更新しようとしたら怒られた。

# portmaster samba48

===>>> Currently installed version: samba48-4.8.5_1
===>>> Port directory: /usr/ports/net/samba48

        ===>>> This port is marked IGNORE
        ===>>> Invalid perl5 version 5.24


        ===>>> If you are sure you can build it, remove the
               IGNORE line in the Makefile and try again.

Perl 5.24は不適切とな。例によって

/usr/ports/UPDATING

を見てみると、システムデフォルトのPerlバージョンは5.26 (20180330）を経て今は5.28（20181213）となっている模様。

20161103の記述に従い、Perlのバージョンを更新する。

まずは/etc/make.confにDEFAULT_VERSIONS+= perl5=5.28を追加。

# echo 'DEFAULT_VERSIONS+=  perl5=5.28' >> /etc/make.conf

Perl 5.24を5.28で置き換える。

# portmaster -o lang/perl5.28 lang/perl5.24

正常に終了したら、上記DEFAULT_VERSIONSは消しておｋ。

そののち、Perl 5.24の共有ライブラリに依存するパッケージを更新。

# portmaster -f `pkg shlib -qR libperl.so.5.24`

p5-なパッケージも更新しといた方が安全かも？

# portmaster p5-

これで無事Samba 4.8のビルドが通った。

遅ればせながら家鯖をFreeBSD 11.2-RELEASEから12.0-RELEASEへと更新した。

まずは現在の環境を最新にしておく（あまりに古いとメジャーバージョンアップに失敗することがあるため）

$ freebsd-version -ku
11.2-RELEASE-p7
11.2-RELEASE-p7

# freebsd-update fetch
# freebsd-update install
# reboot

ここで、ブートローダまでは起動するがカーネル読み込みでブラックスクリーンになる謎現象に2日ほど悩まされた。結局BIOS設定をデフォルト状態に戻したら直ったが、原因は恐らくデュアルCPUからシングルCPUに変えた事と思われる。うちの鯖は無駄にデュアルCPUだったので（ﾄﾞﾔｧ

最新になったか確認。

$ freebsd-version -uk
11.2-RELEASE-p10
11.2-RELEASE-p10

12.0-RELEASEへ更新する。 </code> # freebsd-update -r 12.0-RELEASE upgrade Looking up update.FreeBSD.org mirrors… 3 mirrors found. Fetching metadata signature for 11.2-RELEASE from update2.freebsd.org… done. (略) To install the downloaded upgrades, run “/usr/sbin/freebsd-update install”. </code>

システムのインストール

# freebsd-update install
Installing updates...
Kernel updates have been installed.  Please reboot and run
"/usr/sbin/freebsd-update install" again to finish installing updates.

「再起動して再度freebsd-update installせよ」とのことだが、ここで必ずサードパーティのkext（vboxdrvとか）を一旦無効化する。さもないと、再起動後のカーネル読み込みでクラッシュする場合がある。

# emacs /boot/loader.conf
hogehoge_load="YES"の行をコメントアウトするで～

再起動

# reboot

システムのバージョンを確認してみる。システムは更新され、ユーザーランドは古いままという事が分かる。

$ freebsd-version -ku
12.0-RELEASE-p4
11.2-RELEASE-p10

ユーザーランドを更新。procの所有権を変えようとしてエラーが出てるけど、まぁ気にしない。

# freebsd-update install
Installing updates...install: chown 0:0 ///proc: Operation not supported
install: chmod 555 ///proc: Operation not supported

Completing this upgrade requires removing old shared object files.
Please rebuild all installed 3rd party software (e.g., programs
installed from the ports tree) and then run "/usr/sbin/freebsd-update install"
again to finish installing updates.

再度システムのバージョンを確認。ユーザーランドが更新されていることが分かる。

$ freebsd-version -uk
12.0-RELEASE-p4
12.0-RELEASE-p5

ここまで来たら、pkg-static upgrade -fでインストール済みpackagesをすべて更新するのが正しいお作法。

なんだけれども、自分はportsでビルドしていく派なのでpkgだけ更新して、残りはちまちまportmasterする。

# pkg-static install -f pkg
pkg-static: Warning: Major OS version upgrade detected.  Running "pkg-static install -f pkg" recommended
Updating FreeBSD repository catalogue...
pkg-static: Repository FreeBSD has a wrong packagesite, need to re-create database
Fetching meta.txz: 100%    944 B   0.9kB/s    00:01
Fetching packagesite.txz: 100%    6 MiB   1.7MB/s    00:04
Processing entries: 100%
FreeBSD repository update completed. 31778 packages processed.
All repositories are up to date.
The following 1 package(s) will be affected (of 0 checked):

Installed packages to be REINSTALLED:
        pkg-1.10.5_5 (ABI changed: 'freebsd:11:x86:64' -> 'freebsd:12:x86:64')

Number of packages to be reinstalled: 1

3 MiB to be downloaded.

Proceed with this action? [y/N]: y
[1/1] Fetching pkg-1.10.5_5.txz: 100%    3 MiB   1.7MB/s    00:02
Checking integrity... done (0 conflicting)
[1/1] Reinstalling pkg-1.10.5_5...
[1/1] Extracting pkg-1.10.5_5: 100%
ldconfig: /usr/lib: ignoring directory not owned by root

んん～？/usr/libのオーナーがrootじゃないだとー？

$ ls -al /usr
total 177
drwxr-xr-x  18 6151  wheel   17 11月 23  2018 .
drwxr-xr-x  25 root  wheel   34  5月 29 01:20 ..
dr-xr-xr-x+  3 root  wheel    3 10月 19  2011 .zfs
drwxr-xr-x   2 6151  wheel  515  5月 29 00:39 bin
drwxr-xr-x   2 root  wheel    5  1月 29  2017 freebsd-dist
drwxr-xr-x  16 root  wheel   15 10月 22  2018 home
drwxr-xr-x  58 6151  wheel  344  5月 29 00:33 include
drwxr-xr-x  12 6151  wheel  710  5月 29 00:49 lib
drwxr-xr-x   5 root  wheel  720  5月 29 00:39 lib32
drwxr-xr-x   5 root  wheel    5  5月 29 00:49 libdata
drwxr-xr-x   9 root  wheel   68  5月 29 00:39 libexec
drwxr-xr-x  19 root  wheel   19 11月 15  2018 local
drwxr-xr-x   3 root  wheel    3  7月 13  2017 obj
drwxr-xr-x  72 root  wheel   92  5月 29 07:49 ports
drwxr-xr-x   2 root  wheel  305  5月 29 00:39 sbin
drwxr-xr-x  30 6151  wheel   30  5月 29 00:49 share
drwxr-xr-x  26 root  wheel   40  5月 29 00:34 src
drwxr-xr-x  15 root  wheel   18  7月 13  2017 tests

6151って誰だよ…。最早FreeBSD更新とは無関係になってきたので、続きは別記事で。

いつごろからか、PC起動時に「Another instance is running : 'WebCompanion.UI.AppCore.Services.InstallerService'のタイプ初期化子が例外をスローしました。」というダイアログが出るようになった。

特段気にもしてなかったが、いい加減うざい＆何か気持ち悪いので調べてみたところ、Web Companionとかいうアンチアドウェアを騙るアドウェアらしい。ググって出てきた情報を鵜呑みにしてるので間違ってるかもしれないが、自分が能動的に入れた記憶は一切ないのでお行儀の悪いソフトである事は間違いない。

Geek Uninstallerで強制削除すればアンインストールできるそうだが、自分の環境では「プログラムと機能」(アプリと機能）の一覧に出てこなかった。そういえば、結構前にアンインストールボタンを押したような気がしないでもない…。

とりあえず、C:\Program Files (x86)\Lavasoft\Web Companion\Applicationにアンインストーラがないかと覗いてみるも、それっぽいexeはなし。WebCompanionInstaller.exeがアンインストーラも兼ねてるかも？と思い実行してみたけど、やはりアンインストールは出来ず。だがしかし、プログラムと機能にWeb Companionが復活した笑。どうやら再インストール扱いになった模様。

あとはGeek Uninstallerで強制削除を実行。

全部にチェックを入れて「完了」！

それでも一部のファイルは残ったままで、消そうとしても「使用中で消せないよーん」と言われる。

コンピュータの管理を開き、サービスメニューから関連サービスと思われる「WC Assistant」を停止して、上記フォルダを手動で削除する。

多分これで完全に消えたはず？

• 「GeekUninstaller」アプリケーションのアンインストールを支援するソフト - 窓の杜
• 【ウイルス】Web Companionというソフトが知らない間にパソコンに侵入していましたｗｗｗというわけで削除します。
• スパイウェア対策ソフト「Ad-Aware」の使用は慎重に！ ( Windows ) - 悪代官の伏魔殿別館ブログ - Yahoo!ブログ

本日はFreeBSD関連ネタを2本お届け。

2017年10月に鳴り物入りで発表されたRAIDZ expansion、続報が無くてどうなってんじゃい！と思って調べてみたら、昨年4月の時点でFreeBSDのPhabricatorでプリアルファ版のコードがレビューに出されてた。

といっても、この1年何のレビューも行われてなくて世に出るのはまだ先かも？という印象。それより気になったのはSUMMARYに書いてある何気ない一言「On disk format will change, you will have to destroy your pools.」である。まーじーかー。まぁ仕方ないか…。

ここ2～3年で1万円前後の格安10GBASE-T対応NICが出回り、対応スイッチの価格もジリジリとではあるが下がり、ようやく10GbE環境が普及しだしそうな昨今、格安10GbEチップの定番AquantiaにはFreeBSD用ドライバが無くデーモン使いは地団駄を踏んでいた。

そんな中、たまたまFirst inexpensive 10GBase-T / NBASE-T card with FreeBSD drivers? | iXsystems Communityという記事を見つけ、それによればEdimax EN-9320TX-EがFreeBSDで使えるとのこと。10GBase-TだけではなくNBase-T対応なのも嬉しい。

このカードに搭載されているチップはTehuti TN9710Pってやつで、メーカーが公式にFreeBSD用のドライバを用意している模様。ダウンロードにはユーザー登録（無料）が必要っぽい。チップは違うけどLR-LINKのLREC6860BTも同じドライバで動くらしい。

FreeBSDで使える激安10GBase-T環境がなかなか出てこないことにしびれを切らし、光ファイバー系の方に行ってしまったワタクシには最早関係のないことですがね…。

家鯖(FreeBSD 11)とメインマシン(Windows 10)をConnectX-3の40GBASE-SR4で繋ぐようになって早5ヵ月。メインマシンをスリープ＆レジュームすると、40GBASE-SR4が再リンクアップせず、サーバ側のQSFP+トランシーバを抜き差しすると直る、という現象が発生することがあった。

その時は決まって、サーバ側のTXシグナルが出ていないという状況。

$ ifconfig -v mlxen0
mlxen0: flags=8947<UP,BROADCAST,DEBUG,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=ad00b9<RXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,VLAN_HWFILTER,VLAN_HWTSO,LINKSTATE,RXCSUM_IPV6>
        ether e4:1d:2d:74:16:e0
        hwaddr e4:1d:2d:74:16:e0
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
        media: Ethernet 40Gbase-CR4 <full-duplex> (autoselect)
        status: no carrier
        plugged: QSFP+ 40GBASE-SR4 (MPO Parallel Optic)
        vendor: Mellanox PN: MC2210411-SR4 SN: MEQSRIC0115 DATE: 2015-03-23
        compliance level: Unspecified
        nominal bitrate: 10300 Mbps
        module temperature: 40.00 C voltage: 3.22 Volts
        lane 1: RX: 0.57 mW (-2.37 dBm) TX: 0.36 mW (-4.38 dBm)
        lane 2: RX: 1.06 mW (0.26 dBm) TX: 0.37 mW (-4.30 dBm)
        lane 3: RX: 0.96 mW (-0.17 dBm) TX: 0.00 mW (-30.46 dBm)
        lane 4: RX: 1.12 mW (0.52 dBm) TX: 0.37 mW (-4.20 dBm)

スリープ＆レジュームで電気的に不連続状態になるメインマシン側がそうなるならまだしも、無関係なサーバ側がなんで死ぬのか全く意味がわからないのだが、結局のところQSFP+モジュールとNICとドライバの相性らしい。とりあえず10GtekのMellanox互換モジュールAMQ10-SR4-M1からAvago AFBR-79EQPZに変えて2ヵ月ほど経つが、今のところ再現はしていない。メインマシンの方は変わらずAMQ10-SR4-M1を使っていて特に問題なし。

やっぱりサーバ側の相性ということでFAで、直ったっぽい？