misc notes

FreeBSD Tips: Difference between revisions

Page Discussion

FreeBSD Tips (view source)

Revision as of 10:17, 6 March 2024

33,998 bytes added ,  6 March
no edit summary
No edit summary
No edit summary
 
(332 intermediate revisions by the same user not shown)
Line 1: Line 1:
*MacBook 6,1 (13-Inch, Late 2009) unibody polycarbonate white 再生計画 その4
*ethernetのmedia typeを明示的に設定
何故だか flow control が off になっていたので調べた
 
https://gihyo.jp/admin/clip/01/fdt/201104/08
http://www.jp.freebsd.org/QandA/HTML/2460.html
 
*ntpdで警告
<syntaxhighlight lang="text" enclose="div">
leapsecond file ('/var/db/ntpd.leap-seconds.list'): expired 19 days ago
</syntaxhighlight>
 
<syntaxhighlight lang="bash" enclose="div">
service ntpd fetch
fetch: https://www.ietf.org/timezones/data/leap-seconds.list: Not Found
</syntaxhighlight>
あらら...
 
/etc/rc.conf に
<syntaxhighlight lang="text" enclose="div">
ntp_leapfile_sources="https://data.iana.org/time-zones/data/leap-seconds.list"
</syntaxhighlight>
追加して、オッケー
 
*FreeBSD リハビリwメモ
やってみたらやっぱりそうだったｗ
<syntaxhighlight lang="bash" enclose="div">
protect -dip 1
</syntaxhighlight>
 
 
*FreeBSD リハビリwメモ
 
FreeBSD-EN-23:19.pkgbase
 
をソースからやると make packages でこける。KERNCONF=foo を指定している場合は、make packages KERNCONF=foo
 
あと ports からいれた モジュールはこけるので、make.conf から PORTS_MODULES を外しておく。
 
あぁそうか素カーネルでないと意味ないな。とりあえず作っておくか...
 
*MacBook6,1 (13-Inch, Late 2009) unibody polycarbonate white 再生計画 その8
14.0-p1 が安定して稼働してるので、このハードウェアにあった設定を見直していたら、以前放置していた iSight がサックリ稼働した。
<syntaxhighlight lang="bash" enclose="div">
portmaster multimedia/libuvc multimedia/webcamd
</syntaxhighlight>
 
<syntaxhighlight lang="conf" enclose="div">
webcamd_enable="YES"
webcamd_0_flags="-d ugen1.2"
</syntaxhighlight>
 
後は、/dev/video0 /dev/usb/1.2.* 等のパーミッションを devfs.conf でごにょごにょ か operator　webcamd の group に所属。
 
よい機会なので　Autoloading module は loader.conf で明示的に _load="YES" にした。
 
*FreeBSD リハビリwメモ
FreeBSD 14.0 が出たので 13.2-p5 から、古式ゆかしくソースから upgrade した。いろいろハマり所があったのでメモ。
 
'''この作業をする前に、あらゆる ports で入れたものを rc.conf で OFF にする。(ここ重要。base system が提供しているライブラリとの不整合等があるので upgrade して make delete-old-libs 後に確認する事)'''
'''(network系 daemon で crash (kernel panic) する。avahi-daemon は駄目っぽい。gdb がライブラリ不整合にハマっているので解析は後でする)'''
 
make buildworld, make kernel した後 reboot していったん single user mode で起動。ここで あらゆる filesystem に対して full-fsck する事。
(結構壊れている場合があり、それが問題を起こすパターンもあるらしい)
 
その single user で etcupdate -p して make installworld した後 reboot してまた single user mode で起動。もう一度 make kernel する。
(13.2 の libc のバージョンが古くて、最初の kernel をビルドする時に __cxa_thread_call_dtors: dtr 0xXXXXXX from unloaded dso, skipping のワーニングが出ていて気持ち悪いので、installworld 後に、改めて make kernel する)('''実際のところ、この場合も __cxa_thread_call_dtors が出た。(下にも書いたが)delete-old の後に、もう一度 make world して解消。''')
 
etcupdate -B で「コンフリクトしてるから駄目よ」と言われたら、とりあえず h -> mf で古いのを生かす。(/etc/group と /etc/master.passwd)(先頭のコメント行が不要になるので、あとで手修正する)('''root の shell が (t)csh から sh に変更されたのに注意。スパルタンな仕様に戻ったｗ これも大きな仕様変更かも''')、これがおわったらいよいよ reboot して multi user mode に突入。(root の login shell を /bin/sh にしてからいろんな作業をすべきなのかもね)
 
無事 マルチユーザーモードで上がってきたら check-old delete-old check-old-libs delete-old-libs (最後に check-old-dirs delete-old-dirs)
 
('''delete-old して、root の login shell を /bin/sh にした後 stage1, stage2 みたいに、2回目の天地創造ｗしたら __cxa_thread_call_dtors のワーニングが消えた。これからが本当の地獄^h^h世界だｗ''')
 
新しい世界wで、あらゆる ports の update する。(最初に pkg bootstrap -r)
 
kernel driver 関連でこの修正に対応できていないのは自分でなんとかするｗ ('''__cxa_thread_call_dtors のワーニングが消えた状態では、互換機能が動くのでなにもしないでヨシ''')
https://reviews.freebsd.org/rG2a99dd30dfaac98fea79f084b3a13c45199e1348
 
'''portsnap が削除された。'''git 使えてか...
<syntaxhighlight lang="bash" enclose="div">
git clone https://git.FreeBSD.org/ports.git /usr/ports
</syntaxhighlight>
やたらとバイナリーパッケージ推しになってるが、無視して老人会モードで逝くｗ (油断してたら、せっせと手インストールした ports かなりの数が消されてしまったｗ)
 
git pull のあと make index がいるのかね。fetchindex はまだ動作するね
<syntaxhighlight lang="bash" enclose="div">
cd /usr/ports
make fetchindex
</syntaxhighlight>
 
('''__cxa_thread_call_dtors のワーニングが消えた状態になったら''')過去にインストールした ports すべての再インストールが必須。 (portmaster の man page から)
 
('''最低限 /usr/local/etc のバックアップしておくこと。/usr/ports/distfiles 以下のソースもとっておく方がトラフィック削減でベター''')
<syntaxhighlight lang="bash" enclose="div">
cd /usr/ports/ports-mgmt/portmaster
make install clean
portmaster --list-origins > ~/installed-port-list
cd /usr/ports
git pull
portmaster -ty --clean-distfiles
portmaster -Faf
pkg delete -afy
rm -rf /usr/local/lib/compat/pkg
# Back up any files in /usr/local you wish to save,
# such as configuration files in /usr/local/etc
# Manually check /usr/local and /var/db/pkg
# to make sure that they are really empty
# Install ports-mgmt/pkg and then ports-mgmt/portmaster.
cd /usr/ports/ports-mgmt/pkg
make install clean
cd /usr/ports/ports-mgmt/portmaster
make install clean
# Remove both from ~/installed-port-list.
# もし独自のパッチがある場合はそれも確認。
portmaster --no-confirm `cat ~/installed-port-list`
</syntaxhighlight>
 
(ports-mgmt/portmaster devel/git devel/ccache devel/gdb sysutils/screen security/sudo sysutils/htop sysutils/topless devel/dbus sysutils/powerdxx sysutils/smartmontools)
 
これだけは先にインストールする。(今、(ccacheはいれたが)これを忘れて長時間の再ビルド中...最低でも screen は再インストールしておくべきだったと。何かあったときに attach できないおそれがｗ)
 
'''kernel panic は ieee80211 あたりだとわかった。(avahi を疑っていたのだが、deny-interfaces=wlan0 したらサックリ動く)(ieee80211_crypto_ccmp.c 辺り) MacBook用ｗの bwn は 13.x では超安定してたのだが 14.0 では不安定。何でだろ〜^3 いろいろ調べたら、いろんな ieee 802.11 系で同じ症状らしい。まぁ昔から FreeBSD は Wi-Fi(NFSもｗ) には冷淡だし...'''
 
(自分の環境は wlan に依存した構成になっているので、もう少し頑張る...)(修正がはいらないと駄目っぽいので、手持ちのOpenWrt機器のWi-Fi bridge経由でアクセスするか...)
(手持ちの Ralink MT7601U で試してみるが、ieee80211_crypto_ccmp 辺りで落ちているのなら同じかもね->ドライバーが無かった。実験中のドライバーはあるが...)
(まだブラックフライデー対応してたので、動きそうな古めのUSB Wi-Fiアダプターをいくつか買った。届いてからテストする)
 
tp-link TL-WN725N (Realtek RTL8188EU) が届いて、サックリ安定して動きました!!!! (if_rtwn_usb_load="YES"  rtwn-rtl8188eufw_load="YES")
(country=JP してるのだが、変わってない希ガス)(ports の security/wpa_supplicant 使えば JP を認識した。これいろいろヤバいかもね。)
 
最低限のカスタマイズ .shrc
<syntaxhighlight lang="sh" enclose="div">
set -I
set -E
</syntaxhighlight>
 
X11関連の設定も少し挙動が変わってた。fcitx が自動で起動しないので、~/.config/autostart/fcitx.desktop を作って Exec=/usr/local/bin/fcitx -r -d してオッケー
 
14.0 関連のリンク Errata 系
https://www.daemonology.net/blog/2023-11-21-late-breaking-FreeBSD-14-breakage.html
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260841
 
*FreeBSD リハビリwメモ
あーーーーーー kibana7 が削除されたが kibana8 が動かない! オワタ
 
openjdk は 17 に統一して、node は 18 に固定して kibana8 に手を加えた。
 
/usr/ports/textproc/kibana8/Makefile.local を作成
<syntaxhighlight lang="make" enclose="div">
BUILD_DEPENDS= npm-node18>=9.7.2:www/npm-node18
RUN_DEPENDS= ${LOCALBASE}/bin/node:www/node18
USES= compiler:c++17-lang cpe nodejs:18,build,run python:build
</syntaxhighlight>
 
 
elastic stack version 8 にあげていろいろホゲった。混乱の極みｗ いろいろ認証を必須にした結果ぐちゃぐちゃ&細かなバグいっぱい。
 
https://discuss.elastic.co/t/curl-against-an-encrypted-elasticsearch-instance-with-certificate-verification/251503
https://discuss.elastic.co/t/import-ca-cert-as-privatekeyentry-to-http-keystore-solve-unable-to-create-enrollment-token-error/313780
 
僕の知っている君じゃないｗ
 
最終的に filebeat の FreeBSD特有の不具合に阻まれたｗ
 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272701
 
go の FreeBSD 対応漏れ...もう少し遊ぶｗ
 
結局 filebeat は beats7 にはバージョンチェックがなさそうなので beats8 をやめて beats7 で逃げた。
 
*FreeBSD リハビリwメモ
いろいろ忙しかったので一月ぐらい ports の更新をサボってたら、まぁ大変。FreeBSD の ports も地獄ですなぁw
 
mozc 系での python3.10 の場合 AttributeError: module 'collections' has no attribute 'MutableSet' は、無理矢理FIX
 
/usr/ports/devel/py-gyp/files/patch-pylib_gyp_common.py を作成
<syntaxhighlight lang="diff" enclose="div">
--- pylib/gyp/common.py.oig
+++ pylib/gyp/common.py
@@ -494,7 +494,7 @@ def uniquer(seq, idfun=None):
# Based on http://code.activestate.com/recipes/576694/.
-class OrderedSet(collections.MutableSet):
+class OrderedSet(collections.abc.MutableSet):
  def __init__(self, iterable=None):
    self.end = end = []
    end += [None, end, end]        # sentinel node for doubly linked list
</syntaxhighlight>
'''./scripts/post-patch''' でうんぬんというやり方わすれた...
 
 
*Upgrade ミスってったようだ
13.2-RELEASE-p2 が出てので freebsd-update したが、そのあと ports でエラーが出た。ALLOW_UNSUPPORTED_SYSTEM を使えということで調べると、どうもシステム領域がちゃんと更新されていないようだ。(/usr/include/sys/param.h が古いのを発見)(おそらく 13.1 から 13.2 の更新のときミスったようだ) 仕方がないので、古式ゆかしいｗ make world をやってみた。(システムの cc が gcc から llvm clang に置き換わってるので、gcc よりもビルド時間がかかるかかる...)
 
昔々 mergemaster してたのが、 etcupdate に変わって、そこのところぐらいであとは同じだな。
 
メモ的に... etcupdate は結構よしなにやってくれるようなので、念のために
 
<syntaxhighlight lang="bash" enclose="div">
etcupdate diff > foo.diff
</syntaxhighlight>
 
しておいて、あとは引数なしで etcupdate 実行。そのあとはいつも通り check-old delete-old check-old-libs delete-old-libs
 
 
*MacBook6,1 (13-Inch, Late 2009) unibody polycarbonate white 再生計画 その7
ports build するときのかなり熱を持つ。古いCPUなら powerd++ が良いということで導入したが想定通りの動きでもう手放せないｗ
温度の閾値でCPUを clock down 出来る。
 
<syntaxhighlight lang="text" enclose="div">
powerdxx_enable="YES"
powerdxx_flags="-n min -a hiadaptive -b adaptive -H 80C:100C"
powerdxx_oomprotect="ALL"
</syntaxhighlight>
 
あと、おまじない的にこれもいるかも...
 
<syntaxhighlight lang="text" enclose="div">
debug.acpi.suspend_bounce=1
</syntaxhighlight>
 
年代物なので、CPUグリスがカピカピになってるにはずなので、補修しようかと調べたら、裏蓋をはずしただけで作業はできず、マザーボード外して裏側からヒートシンク外さないといけないことがわかったので、面倒くさいのでヤラナイｗ
 
*FreeBSD リハビリwメモ
GNU awk がほしくって whereis gawk したら、/usr/ports/japanese/gawk といわれて、これでおおはまり。
 
これじゃん /usr/ports/lang/gawk
 
japanese/gawk は version 3, lang/gawk は version 5
 
*FreeBSD リハビリwメモ
portsの名前が変わった影響がでた場合、MOVED の中身を見て、古い名前を pkg_deinstall -f {古い名前} で消してみると良いかも。今回ハマったのはこれで回避した。
<syntaxhighlight lang="bash" enclose="div">
pkg_deinstall -f atk at-spi2-atk
</syntaxhighlight>
<syntaxhighlight lang="bash" enclose="div">
has a missing dependency: atk
</syntaxhighlight>
っていくつかのportsででるが
<syntaxhighlight lang="bash" enclose="div">
portmaster -o accessibility/at-spi2-core accessibility/atk
</syntaxhighlight>
これで一件落着ｗ
 
*FreeBSD リハビリwメモ
freebsd-update でハマり中...仕方が無いので、
<syntaxhighlight lang="bash" enclose="div">
OK unload
OK load /boot/kernel.old/kernel
OK boot
</syntaxhighlight>
とりあえず、実験のあいだ kernel.old をどっかに保存する。カスタムカーネルをやめて GENERIC にするといけるので、カスタムカーネルをいろいろ試し中...
 
<syntaxhighlight lang="bash" enclose="div">
make kernel __MAKE_CONF=/dev/null SRCCONF=/dev/null KERNCONF=MACBOOK
</syntaxhighlight>
これでも駄目だった。
 
nvidia の kernel driver があかんようだ。loader.conf から外して、rc.conf に kld_list="/boot/modules/nvidia.ko" 追加して解決。ふぅぅぅぅぅ
 
何れにせよ "/boot/modules/" にある kernel module は rc.conf に記述したほうが安全かもね。駄目なのもあるけど。
 
*FreeBSD リハビリwメモ
protect の確認
<syntaxhighlight lang="bash" enclose="div">
ps aux -o flags
</syntaxhighlight>
flag の上から３番目
 
*FreeBSD リハビリwメモ
あら dig はデフォで無くなったのか drill が相当品 (unbound の tool なのね)
 
<syntaxhighlight lang="bash" enclose="div">
alias dig drill
</syntaxhighlight>
したｗ
 
なぜ今更な感じ何だが、avahi で IPv6 を resolve したときに link-local しか出ないのでいろいろあさった。(mDNS の仕様っぽいし、無理矢理 Global IPv6 にする方法もみつからなかった)
 
*FreeBSD リハビリwメモ
11.x 以降からいろいろ思想を変えてきてるっぽい。高速の外部記憶(SSD)とかが普通になってるんだったら、昔のようにswapを嫌わずに、主記憶を有効に使う方向に振りましょうとの感じか...
 
*FreeBSD リハビリwメモ
FreeBSD でも Linux みたいな過保護な実装するようになったんだなぁといろいろ調べた
rc.conf にこんなのが書けるっぽい
 
<syntaxhighlight lang="text" enclose="div">
elasticsearch_oomprotect="ALL"
</syntaxhighlight>
これ書いてたら、DB飛ばさなかったかもｗ
 
あら protect flag (P_PROTECTED) 立たないな。調査する...
 
*FreeBSD リハビリwメモ
ほーーーー FreeBSD で "OOM" とい文字列が...昔はこの言葉なかったよなぁ
 
<syntaxhighlight lang="text" enclose="div">
vm.pageout_oom_seq
vm.pfault_oom_attempts
</syntaxhighlight>
 
*FreeBSD リハビリwメモ
sambaが古いのが入ってしまってセキュリティ警告が出て install 出来ないのでデフォルトバージョンを変えた。
<syntaxhighlight lang="text" enclose="div">
DEFAULT_VERSIONS+=samba=4.16
</syntaxhighlight>
 
あとはおまじない
<syntaxhighlight lang="bash" enclose="div">
portmaster -o net/samba416 samba412
</syntaxhighlight>
 
 
*FreeBSD リハビリwメモ
rctl とかよさげかなぁと遊んでみたが、pcpu で deny すると、意識が飛び飛び状態で、これは駄目だ。throttle は使えないので、devctl で script 呼び出しかなぁ...まだ遊び中...
 
一秒に一回イベントがくる。条件が閾値超えだけなので使いづらい。
 
*FreeBSD リハビリwメモ
FreeBSD流 cpu microcode のアップデート
https://www.thomas-krenn.com/en/wiki/Update_Intel_Microcode_on_FreeBSD
一度やればそれでCPUにフラッシュされるのかと思ったらそうでは無いっぽい。 cpu_microcode_load="YES" はそのままにしないといけない。
 
*FreeBSD リハビリwメモ
あーこんなのやってたなぁ
<syntaxhighlight lang="text" enclose="div">
login.conf:# cap_mkdb /etc/login.conf
termcap:#  cap_mkdb -f /usr/share/misc/termcap /etc/termcap
</syntaxhighlight>
limit 解除するときにこれを忘れてハマった記憶がw
 
*FreeBSD リハビリwメモ
blacklistd なるものがあるらしい。(fail2ban 設定中に見つけたｗ) ports の postfix には blacklistd patch もあるので使えそう。遊んでみる。
 
やはり pf つかうのがナウいｗのかねぇ (fail2ban も pf で頑張り中...)
 
*FreeBSD リハビリwメモ
今も要るみたいね... /etc/make.conf に
<syntaxhighlight lang="text" enclose="div">
CFLAGS+=-DFD_SETSIZE=8192 -DSOMAXCONN=4096
</syntaxhighlight>
20年前よりは賢くやろうw
 
<syntaxhighlight lang="text" enclose="div">
/usr/src/sys/sys/socket.h:427:9: error: 'SOMAXCONN' macro redefined [-Werror,-Wmacro-redefined]
#define SOMAXCONN      128
</syntaxhighlight>
ってなるソースもあるのでもう少し工夫がいるか。 "-Wno-macro-redefined" はやりすぎかなぁ?
 
*FreeBSD リハビリwメモ
↓の検証をしていて
<syntaxhighlight lang="text" enclose="div">
vfs.ufs.dirhash_lowmemcount
</syntaxhighlight>
がカタカタ増えるのを見て、懐かしいなぁとｗ
 
find を sleep 入れて回し続けるというバッドハックをやってたｗ
 
<syntaxhighlight lang="bash" enclose="div">
#!/bin/sh
 
while true
do
    /usr/bin/nice -n 20 find / -ls -exec sleep 1 \;  >/dev/null 2>&1
done
</syntaxhighlight>
 
*FreeBSD リハビリwメモ
journaled soft-updates も課題を抱えているらしい。昨今のテラバイト級のストレージでショートファイルが多い場合に(単位時間内での処理過多で)、ジャーナルを食い潰して不具合を起こすらしい。
 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255799
この障碍が起きた場合は 3 回 fsck しないと復旧しないのが特徴。
 
回避策はいろいろ議論されている。
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253968#c15
<syntaxhighlight lang="text" enclose="div">
Kirk McKusick freebsd_committer 2021-06-22 06:07:48 UTC
 
We have had others report that they can reproduce the problem and that
1) disabling journaling (but keeping soft updates) makes the problem go away;
2) increasing the journal size moderates the problem;
3) the patch proposed in https://reviews.freebsd.org/D30041 helps to moderate the problem. This patch is hopefully in a final round of testing before being committed.
 
*** This bug has been marked as a duplicate of bug 255473 ***
</syntaxhighlight>
D30041 は MFC。13.1は適用
 
https://reviews.freebsd.org/D30041
<syntaxhighlight lang="text" enclose="div">
mckusick added a comment. May 17 2021, 6:43 PM
 
I have been working with folks on these two bug reports which I suspect are caused by this problem:
 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255473
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255799
 
The problem may be solved by simply having a bigger journal.
 
The size of the journal should be based on the number of operations that are expected to be done on it in a one-minute period. Unfortunately, tunefs has no direct way to compute this operation count since it knows neither how fast the disk can do transactions nor the capabilities of the system on which it will run. Tunefs is reduced to using the size of the filesystem as an indicator of how big to make the journal.
 
The journal size ranges from 4Mb (SUJ_MIN) to 32Mb (SUJ_MAX) where the maximum is hit for filesystems of 4Gb and above. The maximum journal size was set more than a decade ago and was based on the number of operations expected to be done in a one-minute period on systems of that era. By my estimates it needs to be about 10x larger to meet that criterion today.
 
The easiest way to test this theory would be to bump up SUJ_MAX to 350Mb in sys/ufs/ffs/fs.h and then recompile tunefs. Using the recompiled tunefs, disable journaled soft updates, remove the old .sujournal, then reenable journaled soft updates to get a bigger journal.
</syntaxhighlight>
SUJ_MAX 増やして tunefs をビルドし直して、一旦 "-j disable" してからマウントして .sujournal を消し、再度 "-j enable" して .sujournal を作り直す。.sujournal のサイズが増えていることを確認。念のため full fsck はしておくのがよいかも。← fsck は不要。(Journal timestamp does not match fs mount time っていわれる)
 
あら tunefs に -S オプションがある。こんな感じかな
<syntaxhighlight lang="bash" enclose="div">
tunefs -j enable -S 536870912 /dev/ada0p2
</syntaxhighlight>
 
<syntaxhighlight lang="bash" enclose="div">
-r--------  1 root  wheel    33554432 Jul 25 17:15 .sujournal
*
-r--------  1 root  wheel    536870912 Jul 25 17:19 .sujournal
</syntaxhighlight>
 
D30041 の適用は有効。しかしジャーナル不足の場合は、わかるぐらいオーバヘッドあり(unlink)。ジャーナルサイズを増やす事によりこの事象は解消できる。
 
*FreeBSD リハビリwメモ
いろいろ実験
<syntaxhighlight lang="bash" enclose="div">
camcontrol identify da0
smartctl -d sat /dev/da0 -s wcache,off
camcontrol identify da0
</syntaxhighlight>
 
<syntaxhighlight lang="bash" enclose="div">
smartctl -d sat /dev/da0 -g all
</syntaxhighlight>
 
 
<syntaxhighlight lang="bash" enclose="div">
kern.cam.da.0.flags: 0x3f40<WAS_OTAG,OPEN,SCTX_INIT,CAN_RC16,PROBED,DIRTY,ANNOUCNED>
kern.cam.ada.0.flags: 0x1be3bde<CAN_48BIT,CAN_FLUSHCACHE,CAN_NCQ,CAN_DMA,WAS_OTAG,CAN_TRIM,OPEN,SCTX_INIT,CAN_POWERMGT,CAN_DMA48,CAN_LOG,CAN_WCACHE,CAN_RAHEAD,PROBED,ANNOUNCED,DIRTY,PIM_ATA_EXT,UNMAPPEDIO>
</syntaxhighlight>
この flag って誰がどこで決めてるのかごそごそ調べてみる...
 
 
*FreeBSD リハビリwメモ
gpart メモ
<syntaxhighlight lang="bash" enclose="div">
gpart show da0
gpart delete -i 1 da0
gpart add -t freebsd-ufs -s 100G -a 4k da0
gpart add -t freebsd-ufs -s 831G -a 4k da0
gpart show da0
</syntaxhighlight>
 
 
*FreeBSD リハビリwメモ
あらためて softupdate 考 その2
 
外付け SSD をつかっていろいろ実験してみたが、結論はぐたぐた言わずに SU+J にしろ!
 
実験中 background fsck から復帰したボリュームを umount できない場合が多く、安全な運用方法は、background fsck が終了しだい reboot を早く行う事。
 
(復旧中のファイルシステムが固まったら、最悪電源断とか reboot -qn で一旦リセットするしかない)
 
まーグダグダ言わずに SU+J にしろ! (再)
 
UFS snapshot が使えないってとこも、結局運用上停止メンテと同じ手間だとおもうので、もう UFS snapshot は諦める事。(か ZFS にしたまえｗ)
 
自分自身の感想では ZFS は使いどころをよく考えで、使い分けるのがよさげ
 
 
*FreeBSD リハビリwメモ
いろいろ実験するためにアマゾンプライムデーで SanDisk Portable SSD を購入。
 
ses0 てなデバイスが見えたので、いろいろしらべた。smartd.conf みたら、
<syntaxhighlight lang="text" enclose="div">
# An ATA disk may appear as a SCSI device to the OS. If a SCSI to                                                         
# ATA Translation (SAT) layer is between the OS and the device then                                                       
# this can be flagged with the '-d sat' option. This situation may                                                         
# become common with SATA disks in SAS and FC environments.                                                               
# /dev/sda -a -d sat                                                                                                       
</syntaxhighlight>
とあり、
<syntaxhighlight lang="bash" enclose="div">
smartctl -d sat -a /dev/da0
</syntaxhighlight>
で確認できた。
 
*FreeBSD リハビリwメモ
あらためて softupdate 考
 
今リハビリ中のバージョンは 13.1-RELEASE で、インストール時に言われるままにパーティションきってファイルシステムつくると、こうなっている。
 
<syntaxhighlight lang="text" enclose="div">
tunefs: soft updates: (-n)                                enabled
tunefs: soft update journaling: (-j)                      enabled
tunefs: gjournal: (-J)                                    disabled
</syntaxhighlight>
 
<syntaxhighlight lang="text" enclose="div">
/dev/ada0p2 on / (ufs, local, soft-updates, journaled soft-updates)
</syntaxhighlight>
(実際には noatime は追加してます)
 
Webで過去の記事を見ているときに
<syntaxhighlight lang="text" enclose="div">
/dev/ada0p2 on / (ufs, local, journaled soft-updates)
</syntaxhighlight>
こうなってるのばかりで、なにか変更があったのかと、
<syntaxhighlight lang="text" enclose="div">
tunefs -n disable /dev/ada0p2
</syntaxhighlight>
してみたら、
<syntaxhighlight lang="text" enclose="div">
/dev/ada0p2 on / (ufs, local)
</syntaxhighlight>
となった。-j は soft update のオプション扱いなようで、"-n" + "-j" で journaled soft-updates ということらしい。
 
softupdate はどんな状態で落ちても、ファイルシステムの一貫性は保たれて、障碍後の boot 時に(正しく umount されていないと) Automatic file system check(fsck on boot) で軽く修復後はすぐに mount できてすぐに使える利点がある。preen モード(手動 fsck が必要な重大な問題が無い場合)での修復・回収可能な削除領域を復帰させる(ガベッジコレクション的) fsck は必要で、それを background fsck と呼ばれる方法で稼働中に行える。しかし、この処理は一旦スナップショットをとり、裏で fsck を実行する仕組みになっており、この仕組みが大容量ボリュームの場合はとても重くて遅く、不具合といってよいほどにとらえられている。(UFS snapshot とっている間はそのデバイスがロックされる。fsck中は処理が重い。)
運用上よくある回避策は、background fsck の起動を(停止ではなく)抑制して、負荷の少ない真夜中に bgfsck を実行させる。もしログに重大な警告があれば、スケジュールメンテナンスを行うといった対応になる。(どのタイミングで停止メンテをするかを選択のする余地が出来る)
 
/etc/rc.conf
<syntaxhighlight lang="text" enclose="div">
background_fsck_delay="-1"
</syntaxhighlight>
 
/etc/crontab
<syntaxhighlight lang="text" enclose="div">
0      4      *      *      *      root    /etc/rc.d/bgfsck forcestart
</syntaxhighlight>
 
 
あとはよくあったのは ストレージの I/O cache にだまされる問題。その場合は full fsck は必須。write cache は disable にするのが安全。(昨今のATAはこのあたりは気にしなく良いという話もある)
 
このあたりは過去の知識。
 
FreeBSD から離れていた間に実装された journaled soft-updates をいろいろつついて経験中...
 
journaled soft-updates は dump -L (ライブでの dump) は現在のところは動かない(というか UFS snapshot が使えない)ので、dump -L を使う運用では journal は使えない。
 
journal をオフにした場合(tunefs -j disable)は、必ず .sujournal を削除しないとまずいらしい。
<syntaxhighlight lang="bash" enclose="div">
# enter single user mode
tunefs -j disable /{デバイス}
mount -o rw  {デバイス} {マウントポイント}
# chflags noschg,nosunlnk {マウントポイント}/.sujournal
rm {マウントポイント}/.sujournal
umount {デバイス}
fsck -y {デバイス}
mount -o rw {デバイス} {マウントポイント}
</syntaxhighlight>
★訂正↑のオペレーション(chflags noschg,nosunlnk)はちゃんと -j disable にしていたら不要のはず。保護されている場合は disable 出来ていない事だ。
 
journaled soft-updates は background fsck は動かないので、それにともなう諸問題も無し。
<syntaxhighlight lang="text" enclose="div">
JOURNALED FILESYSTEM, CANNOT RUN IN BACKGROUND
</syntaxhighlight>
 
Netflix は FreeBSD のヘビーユーザで(コンテンツ配信用の)ファイルシステムは UFS + SU+J らしい。コンフィグやログ系は ZFS も一部はつかっているらしい。RAID は一切使っていないらしい。
 
関連リンク集
[https://lwn.net/Articles/339337/ Soft updates, hard problems]
[https://freebsd.seirios.org/doku.php?id=trouble:ufs_and_journal JournalしているUFSでfsckに失敗]
[http://zenno.com/pukiwiki/index.php?FreeBSD%2FSUJ%20%28Soft%20Updates%20Journaling%29 FreeBSD/SUJ (Soft Updates Journaling)]
[https://www.space-i.jp/wp/?p=2072 FreeBSDの .sujournal が邪魔の場合]
[https://footnote.hatenadiary.org/entry/20120729/1343531151 rsyncのためにSoft-Updates Journalingを切る。]
[https://www.knienieder.com/wp/remove-freebsd-journal/ Remove FreeBSD journal]
[https://vermaden.files.wordpress.com/2020/02/pbug-freebsd-enterprise-storage-2020-02-11-unified.pdf FreeBSD Enterprise Storage]
 
*FreeBSD リハビリwメモ
linux の世界ではもはや当たり前につかってる ccache を使ってみる。(私がコミットしている OSS project では ccache が無いと不便なぐらい)
 
"/usr/local/share/doc/ccache/ccache-howto-freebsd.txt" 見たら "WITH_CCACHE_BUILD=yes" だけでイケるぜって書いてたが実際はこんな感じで有効になった
<syntaxhighlight lang="text" enclose="div">
WITH_CCACHE_BUILD=yes
CCACHE_DIR=/var/cache/ccache
CCACHE_BIN=/usr/local/bin/ccache
</syntaxhighlight>
 
sloppiness については "time_macros, pch_defines" を設定してみた。(不具合は経験してなく、hit rate はあがるはず)
 
*FreeBSD リハビリwメモ
なぜ最初からこうなってないのか不思議なんだが.. make.conf に追加
<syntaxhighlight lang="text" enclose="div">
DEFAULT_VERSIONS+= bdb=18
</syntaxhighlight>
 
*FreeBSD リハビリwメモ
make config で設定したオプションがある場所
<syntaxhighlight lang="text" enclose="div">
/var/db/ports/<port>/options
</syntaxhighlight>
 
*FreeBSD リハビリwメモ
/usr/src/UPDATING や /usr/ports/UPDATING はちゃんと読め!
<syntaxhighlight lang="bash" enclose="div">
portmaster --check-depends
pkg check -sa
</syntaxhighlight>
でいろいろ出てきたら、ちゃんと対処
 
*MacBook6,1 (13-Inch, Late 2009) unibody polycarbonate white 再生計画 その6
kernel や kernel module の再構成の時に、ports で入った kernel module をビルドし忘れないように、
<syntaxhighlight lang="text" enclose="div">
PORTS_MODULES=x11/nvidia-driver-340 net/bwn-firmware-kmod
</syntaxhighlight>
これ系は /etc/src.conf ?
 
*MacBook6,1 (13-Inch, Late 2009) unibody polycarbonate white 再生計画 その5
内蔵 Touchpad の設定をいろいろいじくったが、MacOS で使い慣れている事ができないのがストレス。
 
Drag を MacOS と同じやり方にしたいが見つからず。ストレスフルなので、USB マウスを使っている。
 
*MacBook6,1 (13-Inch, Late 2009) unibody polycarbonate white 再生計画 その4
keymap いろいろ
keymap いろいろ


Line 16: Line 625:
Mac流のショートカットが一部動く。(手癖wのストレスは少しは解消)
Mac流のショートカットが一部動く。(手癖wのストレスは少しは解消)


*MacBook 6,1 (13-Inch, Late 2009) unibody polycarbonate white 再生計画 その3
作った keymap は custom という名前にしておくのが良いとわかった
 
*MacBook6,1 (13-Inch, Late 2009) unibody polycarbonate white 再生計画 その3
asmc モジュールを修正した。
asmc モジュールを修正した。
<syntaxhighlight lang="diff" enclose="div">
<syntaxhighlight lang="diff" enclose="div">
Line 56: Line 667:
    "TN1E", "TN1F", "TN1G", "TN1S", "Th1H", \
    "TN1E", "TN1F", "TN1G", "TN1S", "Th1H", \
</syntaxhighlight>
</syntaxhighlight>
<syntaxhighlight lang="text" enclose="div">
dev.asmc.0.sms.z: 262
dev.asmc.0.sms.y: 10
dev.asmc.0.sms.x: 1
dev.asmc.0.temp.memory_proximity: 46
dev.asmc.0.temp.palm_rest: 33
dev.asmc.0.temp.heatsink1: 60
dev.asmc.0.temp.mpc_die2: 72
dev.asmc.0.temp.northbridge0_proximity: 58
dev.asmc.0.temp.northbridge0_diode: 67
dev.asmc.0.temp.hdd_bay: 48
dev.asmc.0.temp.cpu_proximity: 63
dev.asmc.0.temp.cpu_package: 70
dev.asmc.0.temp.battery_2: 30
dev.asmc.0.temp.battery_1: 31
dev.asmc.0.temp.enclosure_bottom0: 30
dev.asmc.0.fan.0.targetspeed: 2000
dev.asmc.0.fan.0.maxspeed: 6200
dev.asmc.0.fan.0.minspeed: 2000
dev.asmc.0.fan.0.speed: 1996
dev.asmc.0.fan.0.id: Exhaust 
dev.asmc.0.%parent: acpi0
dev.asmc.0.%pnpinfo: _HID=APP0001 _UID=0 _CID=SMC-MCP
dev.asmc.0.%location: handle=\_SB_.PCI0.LPCB.SMC_
dev.asmc.0.%driver: asmc
dev.asmc.0.%desc: Apple SMC MacBook Core 2 Duo (13-inch, Late 2009)
</syntaxhighlight>
ちゃんと温度やファンの回転数はとれているが、とりあえず使い道はないｗ
ちゃんと温度やファンの回転数はとれているが、とりあえず使い道はないｗ


Line 64: Line 704:
</syntaxhighlight>
</syntaxhighlight>


*MacBook 6,1 (13-Inch, Late 2009) unibody polycarbonate white 再生計画 その2
*MacBook6,1 (13-Inch, Late 2009) unibody polycarbonate white 再生計画 その2
/etc/loader.conf に
/etc/loader.conf に
<syntaxhighlight lang="text" enclose="div">
<syntaxhighlight lang="text" enclose="div">
Line 75: Line 715:




*MacBook 6,1 (13-Inch, Late 2009) unibody polycarbonate white 再生計画
*MacBook6,1 (13-Inch, Late 2009) unibody polycarbonate white 再生計画
WiFi driver ではまる
WiFi driver ではまる
  [https://forums.freebsd.org/threads/bcm4322-wifi-card-freebsd-11-2-not-working.68103 BCM4322 - WIFI Card - Freebsd 11.2 not working]
  [https://forums.freebsd.org/threads/bcm4322-wifi-card-freebsd-11-2-not-working.68103 BCM4322 - WIFI Card - Freebsd 11.2 not working]
Line 97: Line 737:


FreeBSD 自体が現状では 802.11ac に対応していない。そのために TP-Link の新しい機種は TP-Link 側で 11n のみの設定にしても 11ac としてしか広報しないようで動かなかった...
FreeBSD 自体が現状では 802.11ac に対応していない。そのために TP-Link の新しい機種は TP-Link 側で 11n のみの設定にしても 11ac としてしか広報しないようで動かなかった...
*ほぼ 20 年ぶりに FreeBSD をホゲるw
なので、↓ の記述は 大昔なはなしです。(最後に触ったのは RELENG_8 かなぁ..)(今は 13.1-RELEASE) (初めて触ったのは 2.x の末期だな)


*Amazon EC2 の FreeBSD AMI がテスト中 (嬉!)
*Amazon EC2 の FreeBSD AMI がテスト中 (嬉!)
Retrieved from "https://www.egrep.jp/wiki/index.php/Special:MobileDiff/6500...7138"