統計数理研究所の丸山です。 Date: Wed, 01 Feb 2017 01:12:31 +0900 Subject: [FreeBSD-users-jp 96025] linprocfs and mfs on 10.3-RELEASE-p16
に書いた問題、PC-BSDで freebsd-update をやると変なことが起こる問題ですが、 結局Satoさんが仰ることが的を得ている、との判断に達しました。つまり、 PC-BSDの kernel は元祖FreeBSDのGENERIC kernel とは違っているのに、 /etc/freebsd-update.confを書き換えて freebsd の update server を使ったた めに起こったことでした。 試しに PC-BSD 10.3 の /boot/kernel をそっくり元祖 FreeBSD 10.3 のものに 置き換えて freebsd の update server を使ってupdate して見ると、私が2/1に 書いた linprocfs と mfs が mount できない問題は発生しないことが確認でき ました。 2/1に書いたこの問題が「再現できない」と一時は思ったのですが、それは次の ようなことをしたために一見問題が発生していないように見えたためでした。 - PC-BSD 10.3 で PC-BSDの update server(fbsd-update.pcbsd.org)を使って freebsd-update をやる -> freebsd-version は 10.3-RELEASE-p6 となる - 更に /etc/freebsd-update.conf を書き換えて元祖FreeBSDの update server (update.FreeBSD.org)を使って freebsd-update をやる -> freebsd-version は 10.3-RELEASE-p16となる これですと2/1に書いた現象は一応起きませんが、Satoさんの指摘を踏まえて考 えると、非常に怪しげなやり方、ということになるのでしょう。(この怪しげな 方法で何が起こっているかを解析してもあまり価値がないと思いますので、やめ ておきます。) この怪しげな方法と、もう一つ、PC-BSD10.3インストール後に /boot/kernel を 入れ替えてからfreebsd-update をやる方法というのも、取り敢えずの回避策と しては考えてみましたが、ここはちょっと手間をかけても最大限の安全策を取る ことにしました。それは、PC-BSDのインストーラーの /distにある *.txz をす べて元祖 freebsd10.3 の ncftp ...ses/amd64/10.3-RELEASE > pwd ftp://ftp.jp.freebsd.org/pub/FreeBSD/releases/amd64/10.3-RELEASE/ This URL is also valid on this server: ftp://ftp.jp.freebsd.org/pub/FreeBSD/releases/amd64/amd64/10.3-RELEASE/ ncftp ...ses/amd64/10.3-RELEASE > ls -l *.txz -rw-r--r-- 1 root wheel 70325324 3月 25 2016 base.txz -rw-r--r-- 1 root wheel 1432464 3月 25 2016 doc.txz -rw-r--r-- 1 root wheel 886184 3月 25 2016 games.txz -rw-r--r-- 1 root wheel 97807424 3月 25 2016 kernel.txz -rw-r--r-- 1 root wheel 17545052 3月 25 2016 lib32.txz に置き換えてPC-BSDのインストーラーを使って、丸々インストールをやり直す、 うというやりかたです。PC-BSD10.3のインストーラーのUSB版は PCBSD10.3-RELEASE-03-31-2016-x64-USB.img というもので、 # mdconfig -a -f PCBSD10.3-RELEASE-03-31-2016-x64-USB.img md0 # gpart show md0 => 3 8521344 md0 GPT (4.1G) 3 1600 1 efi (800K) 1603 32 2 freebsd-boot (16K) 1635 8517664 3 freebsd-ufs (4.1G) 8519299 2048 4 freebsd-swap (1.0M) # mount /dev/md0p3 /mnt # df /mnt Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/md0p3 4256990 3956914 -40483 101% /mnt # ls -alg /mnt/dist total 185644 drwxr-xr-x 3 root wheel 512 4月 1 2016 . drwxr-xr-x 24 root wheel 1024 4月 1 2016 .. -rw-r--r-- 1 root wheel 678 4月 1 2016 MANIFEST -rw-r--r-- 1 root wheel 70297356 4月 1 2016 base.txz -rw-r--r-- 1 root wheel 1431780 4月 1 2016 doc.txz -rw-r--r-- 1 root wheel 884216 4月 1 2016 games.txz -rw-r--r-- 1 root wheel 99627036 4月 1 2016 kernel.txz -rw-r--r-- 1 root wheel 17691380 4月 1 2016 lib32.txz drwxr-xr-x 7 root wheel 512 4月 1 2016 packages ですから、この入れ替えは簡単です。(10.2で同じことをやろうとすると、 PCBSD10.2-RELEASE-09-12-2015-x64-DVD-USB.iso なので、ちょっと面倒。)この やり方でちゃんとPC-BSDが動くかというと、ほぼ動きます。元々PC-BSDは FreeBSD+関連pkg+αなので、「α」の分だけ調整が必要になる可能性は覚悟の 上でやったわけですが、殆どそのまま動きました。今、普段持ち歩いている ThinkPad X230に「怪しげなp16」とこの「txz総入れ替えインストール版p16」の 両方が入っていて、いつでも比較できますが、今の時点で気が付いた差は /etc/rc.resume /etc/sysctl.conf だけです。 rc.resume は、PC-BSDでは # Check if we need to resume wpa_supp ifconfig | grep -q 'wlan0:' if [ $? -eq 0 ] ; then /usr/sbin/service netif restart wlan0 fi # Restart moused to fix suspend /etc/rc.d/moused restart が余分についていて、これ無しでは resume後にマウス(PS2)が効きません。 また PC-BSDの /etc/sysctl には kern.ipc.shm_allow_removed=1 というのがあって、これ無しでは chrome を起動したときに For correct operation, shared memory support has to be enabled in Chromium by performing the following command as root : sysctl kern.ipc.shm_allow_removed=1 To preserve this setting across reboots, append the following to /etc/sysctl.conf : kern.ipc.shm_allow_removed=1 と文句を言って、動きません。 長々と書いてしまいましたが、要するに PC-BSDのupdate server はメンテナン スがいい加減なので、 freebsdのupdate server を使うためには、こういうこと をせざるを得ない、ということです。昨年12月4日の時点では PC-BSD update: 10.3-RELEASE-p6 FreeBSD update: 10.3-RELEASE-p12 で、先週2月6日の時点では PC-BSD update: 10.3-RELEASE-p6 FreeBSD update: 10.3-RELEASE-p16 でした。つまり2ヵ月間で FreeBSD のupdate server はp12からp16に更新されて いるのにPC-BSDの方は変化がないわけで、メンテナンスが放棄されているように 見えます。これはPC-BSDのファンである私としては悲しいことですが、対策を取 らざるを得ません。 以上、報告でした。 Mon, 06 Feb 2017 20:46:06 +0900 (JST) Hiroki Sato <h...@allbsd.org> writes: >maruy...@ism.ac.jp (丸山直昌) wrote > in <ydlr33bybme....@samanta.ism.ac.jp>: > >ma> VIMAGE のことは忘れていました。 >ma> >ma> Date: Thu, 01 Sep 2016 14:04:04 +0900 >ma> Subject: [FreeBSD-users-jp 95966] FreeBSD と PC-BSDの違い >ma> >ma> に書いた通り、 10.3での元祖 FreeBSD と PCBSDの違いは >ma> >ma> usr/src/sys/amd64/conf/GENERIC PCBSD/usr/src/sys/amd64/conf/GENERIC >ma> usr/src/sys/netgraph/bluetooth/drivers/ubt/ng_ubt.c >ma> >ma> だけで、少ないとは言え違うので、可能性だけ言えば、動かなくなる機能はある >ma> わけですが、私は jail は使っていないので、まあこのままFreeBSD プロジェク >ma> ト側の freebsd-update サーバを使ってみます。 PC-BSDの update サーバーは >ma> 手抜きでどうしようもありません。 > > VIMAGE が入っている場合、jail を使っているかどうかと関係なく > ネットワーク周りのコードがごっそり変わりますので、 > 不具合はこれからも出ると思います。 > > 先のメールにあった > >ma> link_elf_obj: symbol vnet_entry_ifnet undefined > > は、グローバル変数である ifnet の参照(カーネルモジュールの > リンク時のシンボル解決)に失敗していることを示しています。 > > linprocfs は proc/net/dev をサポートするために ifnet を使います。 > ifnet の構造体は VIMAGE がある場合とない場合とで大きく異なります。 > 具体的には、ある場合は vnet_entry_ifnet という名前に置き換えられ、 > ない場合は ifnet という名前のままです。 > > そのため、linprocfs.ko を読んだ時点で上記のエラーが出るという情報から > 推測すると、PC-BSD に含まれている linprocfs.ko と > FreeBSD プロジェクトがリリースしている GENERIC カーネルとを > 組み合わせた場合なのだと思います。GENERIC カーネルには > vnet_entry_ifnet が定義されていませんので、カーネルモジュールの > ロードに失敗します。 > > なぜ再現しないのかはわかりませんが、 > 「freebsd-update によってカーネル本体だけ差し替えられた」という > 想像が正しいなら、カーネルモジュールのうち、ifnet を参照するものは > 全滅しています。これには linprocfs だけでなく、 > ipfw や pf, if_vlan などが含まれますので、影響は大きいです。 > > 自己責任で使われるのは自由だと思いますが、 > メーリングリストに報告しても有益なアドバイスを得られる可能性は > 非常に低いのではないでしょうか。 > >-- Hiroki -------- 丸山直昌@統計数理研究所 _______________________________________________ freebsd-users-jp@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-users-jp To unsubscribe, send any mail to "freebsd-users-jp-unsubscr...@freebsd.org"