反省である。
最大の原因は作成したインストールメディアがFreeBSD13だったことだ。移行予定のHDのFreeBSDは12だったのである。安易にだいじょうぶだろう、と考えたのがまちがいだった。インストールメディアから作成したmicroSDのFreeBSDにHDの中身をいれると、bootしなくなるのである。
ZFSのバージョンとか、色々、あるらしい。
などと いっているけれど、これは単純にオペミスだったかも。
というのも
gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 2 da0
みたいな感じでブートコードをupdateしたのだけれど、これってよくよく考えたらMBR用じゃね？
実際のbootにはUEFIを使っているから、 それ用のブートコードをupdateをしなければ、いけなかったはず。今さら試してみる気にはなれないけれど。FreeBSD13にupdateするとき、否が応にも試すことになるだろうけど。
結局、microSDカードのスロットが空いてしまっている。
予定ではそこからbootして、うひょひょひょひょっ、と喜色満面の予定だったのだが。
ただこのスロットは埋めておきたい。
いつもの貧乏性からだけでなく、何もいれていないと、FreeBSDの起動に時間がかかるからだ。なぜだか、知らないが——WindowsもUbuntuもだいじょうぶだったのに、bootのときに、このスロットを確認しにいくのである。何度もTimeoutしてもしつこく。
なのでとりあえず、microSDカードをいれておきたい。
ところが壊れたmicroSDカードも手元にないし、使えるものをただ、いれておくというのも忍びない。
そうだ。
mirrorにしよう。
microSDカードを使おうと試行錯誤していたとき、USBメモリとmicroSDカードをstripeにしたことはあるのだけど、これはうまくいかなかった。bootの途中で、microSDカードを認識できないので、stripeに失敗するからだと思う。mirrorならうまくいくんじゃないか。
そこでmirror用にmicroSDカードを購入した。
boot用のmicroSDカードと同じ128Gのものである。mirrorは同じサイズにしなければ、いけないからだ。なんか、貧乏性でいろいろ、工夫しているのに、金が出ていくな。
届いたmicroSDカードにFreeBSD12をinstall。
インストールディスクからbootしたあと、zroot2をimportして
$ sudo zpool attach zroot2 da0p4 mmcsd0p4
しばらくしてエラーがでた。
smallなんとかかんとか。
あれ？
$ gpart show da0
=> 40 250560432 da0 GPT (119G)
40 409600 1 efi (200M)
409640 1024 2 freebsd-boot (512K)
410664 984 - free - (492K)
411648 4194304 3 freebsd-swap (2.0G)
4605952 245952512 4 freebsd-zfs (117G)
250558464 2008 - free - (1.0M)
$ gpart show mmcsd0
=> 40 249737136 mmcsd0 GPT (119G)
40 409600 1 efi (200M)
409640 1024 2 freebsd-boot (512K)
410664 984 - free - (492K)
411648 4194304 3 freebsd-swap (2.0G)
4605952 245129216 4 freebsd-zfs (117G)
249735168 2008 - free - (1.0M)
同じ128GのmicroSDカードなのにサイズがちがうじゃないか。
しかも新しく購入した方が小さい。逆ならリサイズしてなんとか、なったのに。mmcsd0p4をいくら拡張してもda0p4のサイズにならない——頭を抱えてしまった。da0の方が破損したときに、mmcsd0のmicroSDカードからbootできるようにしたいので同じような構成したのだが。
あきらめることも含めて検討した結果、swap領域を小さくしてmmcsd0p4をサイズ拡張した。
$ sudo gpart delete -i 4 mmcsd0
mmcsd0p4 deleted
$ sudo gpart delete -i 3 mmcsd0
mmcsd0p3 deleted
$ gpart show mmcsd0
=> 40 249737136 mmcsd0 GPT (119G)
40 409600 1 efi (200M)
409640 1024 2 freebsd-boot (512K)
410664 249326512 - free - (119G)
$ sudo gpart add -a 4k -t freebsd-swap -s 1G mmcsd0
mmcsd0p3 added, but partition is not aligned on 4194304 bytes
$ gpart show mmcsd0
=> 40 249737136 mmcsd0 GPT (119G)
40 409600 1 efi (200M)
409640 1024 2 freebsd-boot (512K)
410664 2097152 3 freebsd-swap (1.0G)
2507816 247229360 - free - (118G)
$ sudo gpart add -a 4k -t freebsd-zfs -s 117G mmcsd0
mmcsd0p4 added, but partition is not aligned on 4194304 bytes
$ gpart show mmcsd0
=> 40 249737136 mmcsd0 GPT (119G)
40 409600 1 efi (200M)
409640 1024 2 freebsd-boot (512K)
410664 2097152 3 freebsd-swap (1.0G)
2507816 245366784 4 freebsd-zfs (117G)
247874600 1862576 - free - (909M)
$ sudo gpart resize -s 245952512 -i 4 mmcsd0
mmcsd0p4 resized
$ gpart show mmcsd0
=> 40 249737136 mmcsd0 GPT (119G)
40 409600 1 efi (200M)
409640 1024 2 freebsd-boot (512K)
410664 2097152 3 freebsd-swap (1.0G)
2507816 245952512 4 freebsd-zfs (117G)
248460328 1276848 - free - (623M)
$ gpart show da0
=> 40 250560432 da0 GPT (119G)
40 409600 1 efi (200M)
409640 1024 2 freebsd-boot (512K)
410664 984 - free - (492K)
411648 4194304 3 freebsd-swap (2.0G)
4605952 245952512 4 freebsd-zfs (117G)
250558464 2008 - free - (1.0M)
これでmmcsd0p4とda0p4は同じサイズになったのでattach。
$ sudo zpool attach zroot2 da0p4 mmcsd0p4 Make sure to wait until resilver is done before rebooting. If you boot from pool 'zroot2', you may need to update boot code on newly attached disk 'mmcsd0p4'. Assuming you use GPT partitioning and 'da0' is your new boot disk you may use the following command: gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da0 $ $ zpool status zroot2 pool: zroot2 state: ONLINE status: One or more devices is currently being resilvered. The pool will continue to function, possibly in a degraded state. action: Wait for the resilver to complete. scan: resilver in progress since Mon Jun 21 13:13:29 2021 21.7G scanned at 208M/s, 1.19G issued at 11.4M/s, 21.7G total 1.18G resilvered, 5.48% done, 0 days 00:30:45 to go config: NAME STATE READ WRITE CKSUM zroot2 ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 da0p4 ONLINE 0 0 0 mmcsd0p4 ONLINE 0 0 0 errors: No known data errors
同期してしまうのにしばらくかかった。
かなりはまった。
最大の原因は作成したインストールメディアがFreeBSD13だったことだ。移行予定のHDのFreeBSDは12だったのである。安易にだいじょうぶだろう、と考えたのがまちがいだった。インストールメディアから作成したmicroSDのFreeBSDにHDの中身をいれると、bootしなくなるのである。
ZFSのバージョンとか、色々、あるらしい 1。
お得意のddディスク丸ごとコピーもだめで、うまくいくこともあるのだが、HDを作成したときにすでにおかしくなっているところがあることに気づき、FreeBSD12のインストールディスクをつくりなおすことにした。
以下の手順は記憶にたよって書いているのでまちがいがあるかもしれない。
・インストールメディアからmicroSDにFreeBSDをinstall。このとき、pool名をでデフォルトではなく、zroot2に。
HDの中のFreeBSDのpool名がzrootになっているからである。
・インストールメディアからインストールメニューを立ち上げ、shellへ。
・zroot、zroot2をimport
zpool import -fN zroot zpool import -fN zroot2
・zrootにsnapshotを作成。
zfs snapshot -r zroot@snap999
・HDの中身をZFSのsend/resvで、microSDへ流しこむ。
zfs send -pR zroot@snap999 | zfs recv -uvdF zroot2
>> 参考先
・microSDから起動を確認。
ただし、/etc/fstabの中のswapのデバイス定義がHDになっているのでswapなしの状態になっている。
12と13で作成したbootディスクはBIOS(EFI？)から見え方がちがっていたので、ずいぶんかわっていたのかもしれない。
単純に、microSDカードを突っこんだUSBアダプタからbootすれば、いいだけじゃね？
それなら、と考えたのはType-Cにしようか、ということだった。
BeelinkS1にはType-Cの口がある。MacBookAirにもある。それだったらType-Cでしょ。
ユーザのコメントにかなり熱くなるというのが、かなり不安材料だ。
HDの過熱が嫌でやっていることなのに。
microSDカードから直接、bootできないので色々、考えた。
USBメモリからならboot可能なので、そちらでbootしてmicroSDカードのシステムに切り替えることはできないだろうか。あるいは最低でもuser領域をmicroSDカードに持つということはどうだろう。
ところが試行錯誤していて気づいたのだが、どうもmicroSDカードの中を認識するタイミングがboot後でないとだめらしい。単純にはうまくいかない。
ほとんど、あきらめていたのだけれど。
よくよく考えたら。
単純に、microSDカードを突っこんだUSBアダプタからbootすれば、いいだけじゃね？
どうせUSBスロットはひとつ、消費されているわけなんだし。
突っ伏してしまった。
1週間近く、やっていたことは何だったんだ。
すっかり忘れていた。
BeelinkS1でmicroSDカードを使おうと、HDからデータを移そうとして。
ZFSのことである。
コマンドを忘れたとか、というレベルではなく、概念そのものをすっかり失念していて、おかげで 以前、いじったときの記事を読んでも意味がさっぱりわからない。自分で書いたのに。
そもそもzpool importをデータのimportだと勘違いしていた。
zpool export XXXXX | zpool import YYYYY
とか、やって動かないなぁ、と。
アホだ。
zpool importはデータのimportではなく、システムに指定したpoolを認識させるためのものだった。それがわかってちょこちょこやっていたのだけど。
単純にzpool importすると、mountされてしまう。
どういうタイミングだったのか、よくわからないのだが、何度か、ルートをすっ飛ばして/binが消えてしまって身動きできなくなってしまった。
zpool importしないと、poolにたいする操作ができないし。
mountしないでimportする方法はないものか。グーグル先生にたずねてもわからず、ないものか、とあきらめかけたところ、真面目にmanマニュアルを読んでいったら見つけた。
zpool import -N XXXXXX
「-N」ですか。
これですこしは自由になれたかな。
BeelinkS1のmicroSDカードの抜き挿しがままならない。
それなら挿しっぱなしにするしかないか——というわけで、microSDカードにFreeBSDをinstallしてそこからbootしようと目論んだ。HDからFreeBSDを立ち上げると、過熱がひどいのだ。HDが排熱を邪魔しているからだろう。今までにも二台、 SSDをだめにしている。
ところがbootしなかった。
BIOSのメニューを見ても、どうもmicroSDカードを認識していないようなのだ。
いろいろやってみたが、解決せず。これは根本的にできないのではないか。そんな気がする。
Ubuntuをいれていたときの残骸のGRUBから確認してみてもmicroSDカードの中のgpartを見ることができなかった。HDの方はちゃんと見えるのに。
これはあれか？
HDからFreeBSDを立ち上げてmicroSDカードを拡張ディスクとして使うという流れか？
でも、それだと、過熱問題を解決できないんだよなぁ。
連休ということもあったひさしぶりに RaspberryPiのFreeBSDをrebuildした。
エラーがでた。
kernelのlinkのときに落ちた。
device not spaceなんたらかんたら——ああ、これはあれだ。デバイスの容量が足りないというやつだ。
で、どのデバイスが？
/tmpだろうとあたりをつけた。
/tmpはtmpfsでメモリ上にマップされているので、50Mほどしか、ない。
めずらしく正解で、うまくrebuildできたのだけれど、ふとAmazonでmicroSDカードで調べてみたら128Gが3,000円を切っていた。うそん。何がショックかって 先代のMacBook Airの内蔵ディスクが128Gだったのだ。
ということは何？
FreeBSD on RaspberryPiは128Gにできるってこと？
そう思ったらAmazonでポチってしまっていた。
そのあとに、 microSDカードの書き込み上限はモノによっては1000回程度だということを知る。
あわててtmpfsを有効にする。swapも殺しておいた方がいいかもしれない。
それにしても128Gが書き込み上限1000回だったら泣けるな。
とりあえず、FreeBSD入りの32Gを128GのmicroSDにコピる。
$ sudo dd if=/dev/mmcsd0 of=/dev/da0 bs=1m
3時間以上、かかった。4時間かもしれない。
ちゃんとbootした。
growfsをYESにしていたので自動で拡張されるか、と思ったけれど、そんなことはなかった。
$ df -h Filesystem Size Used Avail Capacity Mounted on /dev/ufs/rootfs 28G 19G 6.9G 74% / devfs 1.0K 1.0K 0B 100% /dev /dev/msdosfs/MSDOSBOOT 50M 14M 36M 28% /boot/msdos tmpfs 50M 8.0K 50M 0% /tmp $
試行錯誤とマニュアルと首っ引きで、拡張する方法を探す。
growfsコマンドでいきそうなのだけど、gpartを使う必要があるようだ。
$ gpart show
=> 63 250560449 mmcsd0 MBR (119G)
63 2016 - free - (1.0M)
2079 102312 1 fat32lba [active] (50M)
104391 61335609 2 freebsd (29G)
61440000 189120512 - free - (90G)
=> 0 61335609 mmcsd0s2 BSD (29G)
0 57 - free - (29K)
57 61335552 1 freebsd-ufs (29G)
$ sudo gpart resize -i 2 mmcsd0
mmcsd0s2 resized
$ gpart show
=> 63 250560449 mmcsd0 MBR (119G)
63 2016 - free - (1.0M)
2079 102312 1 fat32lba [active] (50M)
104391 250456121 2 freebsd (119G)
=> 0 250456121 mmcsd0s2 BSD (119G)
0 57 - free - (29K)
57 61335552 1 freebsd-ufs (29G)
61335609 189120512 - free - (90G)
$ sudo gpart resize -i 1 mmcsd0s2
mmcsd0s2a resized
$ gpart show
=> 63 250560449 mmcsd0 MBR (119G)
63 2016 - free - (1.0M)
2079 102312 1 fat32lba [active] (50M)
104391 250456121 2 freebsd (119G)
=> 0 250456121 mmcsd0s2 BSD (119G)
0 57 - free - (29K)
57 250456064 1 freebsd-ufs (119G)
$ sudo growfs /
Device is mounted read-write; resizing will result in temporary write suspension for /.
It 's strongly recommended to make a backup before growing the file system.
OK to grow filesystem on /dev/ufs/rootfs, mounted on /, from 29GB to 119GB? [yes/no] yes
super-block backups (for fsck_ffs -b #) at:
61547712, 62829952, 64112192, 65394432, 66676672, 67958912, 69241152, 70523392, 71805632, 73087872,
74370112, 75652352, 76934592, 78216832, 79499072, 80781312, 82063552, 83345792, 84628032, 85910272,
87192512, 88474752, 89756992, 91039232, 92321472, 93603712, 94885952, 96168192, 97450432, 98732672,
100014912, 101297152, 102579392, 103861632, 105143872, 106426112, 107708352, 108990592, 110272832,
111555072, 112837312, 114119552, 115401792, 116684032, 117966272, 119248512, 120530752, 121812992,
123095232, 124377472, 125659712, 126941952, 128224192, 129506432, 130788672, 132070912, 133353152,
134635392, 135917632, 137199872, 138482112, 139764352, 141046592, 142328832, 143611072, 144893312,
146175552, 147457792, 148740032, 150022272, 151304512, 152586752, 153868992, 155151232, 156433472,
157715712, 158997952, 160280192, 161562432, 162844672, 164126912, 165409152, 166691392, 167973632,
169255872, 170538112, 171820352, 173102592, 174384832, 175667072, 176949312, 178231552, 179513792,
180796032, 182078272, 183360512, 184642752, 185924992, 187207232, 188489472, 189771712, 191053952,
192336192, 193618432, 194900672, 196182912, 197465152, 198747392, 200029632, 201311872, 202594112,
203876352, 205158592, 206440832, 207723072, 209005312, 210287552, 211569792, 212852032, 214134272,
215416512, 216698752, 217980992, 219263232, 220545472, 221827712, 223109952, 224392192, 225674432,
226956672, 228238912, 229521152, 230803392, 232085632, 233367872, 234650112, 235932352, 237214592,
238496832, 239779072, 241061312, 242343552, 243625792, 244908032, 246190272, 247472512, 248754752,
250036992
$
$ df -h
Filesystem Size Used Avail Capacity Mounted on
/dev/ufs/rootfs 116G 19G 87G 18% /
devfs 1.0K 1.0K 0B 100% /dev
/dev/msdosfs/MSDOSBOOT 50M 14M 36M 28% /boot/msdos
tmpfs 50M 24K 50M 0% /tmp
$
なんとか、なった。
そもそも128GということはBeelinkS1にインストールしてあるFreeBSDよりも大きい。
それだったらBeelinkS1にmicroSDカードをセットしてそこから使えばいいじゃん——と思ったのだけれど、どういうわけか、うちのBeelinkS1はmicroSDカードが挿しこめないのだった。なんと不良品だったのか。今さらだが。
BeelinkS1にいれておいたUbuntuをUPDATEしたら起動しなくなってしまった。
rescueモードもだめで、インストールしなおしているうちに、イラッとしてきて——40GのハードディスクにいれておいたFreeBSDと交換した。Ubuntu用に使っていたSSDはかなり熱くなっていた。
これが原因とは思えないが、BeelinkS1の熱の溜り方は半端なさすぎる。
今後はハードディスク一択にしておこう。
別に何かに使うわけじゃないのだけど。
正月にUbuntuをいじっているときに気づいたのだけれど。
ssh -Y
が使えた。
きっとUbuntu Serverだからだろう、と思っていたのだけど、「Ubuntu 18.04.3 LTS」で試してみたら使えるようになっていた。以前、使えなかったのは何だったんだろう。
とても助かるけれど、それなら 机の上にBeelinkS1をもってくることはなかったなぁ。
不安はもろもろあったのだけれど、BeelinkS1の 内蔵ディスクを128Gにした。
それでようやく重い腰をあげて 本格的に使おうか、と26Gもあるファイルをscpでコピーしていたら突然、動かなくなった。sudoも効かない。何？ 何？ 何が起きたの？
何が起きているのか、さっぱりわからず、いろいろやってみていたら——あれ？ ホームディレクトリが空っぽになっている。
ZFSがまた、ぶっ壊れた。
ところが翌日になると、うまく動いた。
また、熱ダレだったか、と思って使っていると、ふたたび、おかしくなった。
やはりだめだ。
とりあえずBeelinkS1はWindows10として使うか。
でもhome editionなのでRDPが使えない。
クライアントとして使うしかない。しかたないのでマシン本体を机の上にもってきた。これがほんとのデスクトップ。なんちゃって。でももしかしたら使えるかもしれないので、FreeBSDをいれていたSSDにフォーマットをかけた。
20GのDドライブができた。
——？
128Gじゃない。
何度、見直してみても20G。やりなおしても20G。ほんとうに壊れてしまっていたらしい。
しかたがない。
問題はWindows10とMacのやりとりだ。
もちろんネット的にはつながる。けれど、26Gなんて馬鹿でかいファイルの転送はさすがに時間がかかりすぎるので外部記憶装置が必要だ。
昔、使っていたお立ち台をひっぱりだす。
160Gのハードディスクを突っ込んでNTFSでフォーマット。
これでMacとWindows10でやりとりできるはずだ。
Macにつなげて試した——ところがreadonlyだった。書きこめない。昔、読み書きができたように思っていたのだけど。どうやらかんちがいだったらしい。うーん、これはこまった。これじゃ、Windows10からMacへの一方通行しかできないじゃないか。今、やりたいのは逆方向のMacからWindows10なのだが。
なのでexFATでフォーマットしなおした。
これなら両方で読み書きできる。
FreeBSDのSSDを納めていたスロットにはもうひとつ余っている128GのSSDをいれた。
これはNTFSでフォーマットしてDドライブとして使うことにした。
ほか、いろいろと設定をしているうちに、Macから操作ができないことに嫌になって、思わず、以前いれた Ubuntuをインストールしてしまった。128GのSSDに。
UbuntuならVNCでMac上に表示できるからMacから操作できる。
いちいちディスプレイをスイッチする必要がなくなる。
いい考えだと思ったのだけれど、UbuntuはexFATを認識してくれなかった…… 1。
それで頭に来てお立ち台のハードディスクをNTFSでフォーマットしなおしてしまった。
UbuntuはNTFSを読み書きできるけど、Macはreadonlyなんだから、元の黙阿弥ではないか。
——なんでおれは後戻りのできない性格なんだろう……。
でも勝算はなくもなかった。
Windows10はできないけれど、UbuntuはHFS+を読めるのである。readonlyだとしても。
当然、MacはHFS+を読み書きできる。
実はお立ち台はもう一台あってそれは現役でMac用に使用中。フォーマットはHFS+。
２台あるお立ち台はいずれもMac、Ubuntu間では一方通行だけど、互い違いなのでデータの往復が可能なのである。
ちょっと面倒ではあるけれど。
きっと方法はあるのだろうけど、FreeBSDなら一生懸命探すのにUbuntuだと、見当らない、というだけであきらめてしまう。よくない傾向だ。
BeelinkS1のFreeBSDにVirtualBoxを「pkg install」した。
installしたときに、設定方法が表示されたのでその通りにやれば、よかったのだけど、ゲストOSにメモリが1Gしか、割り当てることができなくて死んだ。
Message from virtualbox-ose-5.2.34:
–
VirtualBox was installed.You need to load the vboxdrv kernel module via /boot/loader.conf:
vboxdrv_load="YES"
You also have to add all users to your vboxusers group in order to use vbox.
% pw groupmod vboxusers -m jerry
Reboot the machine to load the needed kernel modules.
Bridging Support:
===============For bridged networking please add the following line to your /etc/rc.conf:
vboxnet_enable="YES"
USB Support:
==========For USB support your user needs to be in the operator group and needs read
and write permissions to the USB device.% pw groupmod operator -m jerry
Add the following to /etc/devfs.rules (create if it doesn't exist):
[system=10]
add path 'usb/*' mode 0660 group operatorTo load these new rule add the following to /etc/rc.conf:
devfs_system_ruleset="system"
Then restart devfs to load the new rules:
% /etc/rc.d/devfs restart
Troubleshooting:
==============Running VirtualBox as non-root user may fail with a fatal error
NS_ERROR_FACTORY_NOT_REGISTERED. In this case delete tmp.vbox-*-ipc file.If you experience "Network: write Failed: Cannot allocate memory" errors
try to increase net.graph.maxdata in /boot/loader.confIf you are using AIO, then increase these limits (PR#168298):
vfs.aio.max_buf_aio=8192
vfs.aio.max_aio_queue_per_proc=65536
vfs.aio.max_aio_per_proc=8192
vfs.aio.max_aio_queue=65536
To check if AIO is used use: kldstat -v | grep aioCheck wiki page for known issues and troubleshooting:
http://wiki.freebsd.org/VirtualBoxPlease report any problems to emulation@. Thanks!
$
内蔵ディスクをSSDに換装してすぐにbootしなくなった。
あれ？
どうやら内蔵ディスクをbootディスクと認識していないようだ。おかしいなぁ。もしかしたらパーティションの拡張をしたときになんか、やっちゃったのかなぁ 1。
とりあえず、bootコードをぶちこむ。
gpart bootcode -p /boot/boot1.efifat -i 1 ada0
Beelink S1のディスクは いろいろあってハードディスクにしていたのだけれど、容量が40Gしかない。やはり128Gある、SSDに交換しよう。どうすれば、いいかな……。
FreeBSDのインストールUSBからBeelink S1を立ち上げて、ddコマンドで40Gの中身を丸ごとコピーすることにした。内蔵ディスクの40Gから 「ORICO USB3.0 HDDスタンド」へ接続した128Gへ。
dd if=/dev/ada0 of=/dev/da0 bs=1m
内蔵ディスクをSSDに取り替えてboot。
立ち上がった。ZFSは勝手に空きを使ってくれるんだよね……と思っていたらあれ？
$ df -h df -h Filesystem Size Used Avail Capacity Mounted on zroot/ROOT/default 26G 7.0G 19G 27% / devfs 1.0K 1.0K 0B 100% /dev zroot/var/mail 19G 200K 19G 0% /var/mail zroot/var/audit 19G 88K 19G 0% /var/audit zroot/usr/ports 20G 696M 19G 3% /usr/ports zroot/usr/home 20G 318M 19G 2% /usr/home zroot/usr/src 19G 88K 19G 0% /usr/src zroot/tmp 19G 6.4M 19G 0% /tmp zroot 19G 88K 19G 0% /zroot zroot/var/crash 20G 614M 19G 3% /var/crash zroot/var/log 19G 700K 19G 0% /var/log zroot/var/tmp 19G 88K 19G 0% /var/tmp $
40Gしか認識してねえ。
zpool online -e zroot /dev/ada0p4
でもだめで、
$ zfs list zfs list NAME USED AVAIL REFER MOUNTPOINT zroot 14.7G 19.2G 88K /zroot zroot/ROOT 11.5G 19.2G 88K none zroot/ROOT/default 11.5G 19.2G 6.95G / zroot/tmp 10.3M 19.2G 6.39M /tmp zroot/usr 2.47G 19.2G 88K /usr zroot/usr/home 1.78G 19.2G 318M /usr/home zroot/usr/ports 706M 19.2G 696M /usr/ports zroot/usr/src 144K 19.2G 88K /usr/src zroot/var 624M 19.2G 88K /var zroot/var/audit 144K 19.2G 88K /var/audit zroot/var/crash 615M 19.2G 614M /var/crash zroot/var/log 6.36M 19.2G 700K /var/log zroot/var/mail 2.18M 19.2G 200K /var/mail zroot/var/tmp 496K 19.2G 88K /var/tmp $
認識してくれない。うーむ。
$ gpart show ada0
gpart show ada0
=> 40 78140080 ada0 GPT (119G)
40 409600 1 efi (200M)
409640 1024 2 freebsd-boot (512K)
410664 984 - free - (492K)
411648 4194304 3 freebsd-swap (2.0G)
4605952 73533440 4 freebsd-zfs (35G)
78139392 728 - free - (364K)
gpartで見てみると、なるほど。ada0は119Gあるのに、zfsの領域を35Gしか、認識していない。これか。調べてみると、gpartにはresizeというサブコマンドがある。こうか？
$ sudo gpart resize -i 4 ada0
sudo gpart resize -i 4 ada0
ada0p4 resized
$ gpart show ada0
gpart show ada0
=> 40 250069600 ada0 GPT (119G)
40 409600 1 efi (200M)
409640 1024 2 freebsd-boot (512K)
410664 984 - free - (492K)
411648 4194304 3 freebsd-swap (2.0G)
4605952 245463688 4 freebsd-zfs (117G)
うまくいった。
けれど、これだけではまだ、足りなくてZFSの方で認識してくれてなかった。なのであらためて。
zpool online -e zroot /dev/ada0p4
$ zfs list zfs list NAME USED AVAIL REFER MOUNTPOINT zroot 14.6G 98.7G 88K /zroot zroot/ROOT 11.5G 98.7G 88K none zroot/ROOT/default 11.5G 98.7G 6.96G / zroot/tmp 10.4M 98.7G 6.39M /tmp zroot/usr 2.46G 98.7G 88K /usr zroot/usr/home 1.77G 98.7G 315M /usr/home zroot/usr/ports 706M 98.7G 696M /usr/ports zroot/usr/src 144K 98.7G 88K /usr/src zroot/var 624M 98.7G 88K /var zroot/var/audit 144K 98.7G 88K /var/audit zroot/var/crash 615M 98.7G 614M /var/crash zroot/var/log 6.39M 98.7G 720K /var/log zroot/var/mail 2.09M 98.7G 200K /var/mail zroot/var/tmp 504K 98.7G 88K /var/tmp $
いきましたね。よかったよかった 1。
実はいつか、わからないけどbootコードを壊してしまっていたのだった。
三日間、CPUをぶん回したらpostgresがおかしくなった。
また、アクセスできないデータブロックが発生している。これはUbuntuのときも発生したことで、最後にはSSDがreadonlyになってしまった。前回もやはり三日目ぐらいだった。
だめか。
今回はすこしちゃんと見てみる。
zpool status -v
やはりerrorがでていた。しかもバックアップからデータをもどしてね、みたいなメッセージつき。
バックアップなんてとってねーし。
postgresのデータブロックだけではなく、ほかにもいろんなファイルが壊れている模様。
——これはだめだ。
せめてバックアップをとっていれば。すっかり頭になかった。
やはりSSDでの連続運用は無理があるのかも——というわけであらためてハードディスクを持ち出してきてFreeBSD12をインストールしなおす。
今回はある程度、設定したところでバックアップをとることにした。
ZFSのことはよくわかっていないので泥縄で学ぶ。「ZFS - スナップショットいつやるか?今でしょ!」とか、これとか、これ。フルバックアップをとったあと、「zfstools」をインストールして１時間ごとにsnapshotをとるようにする1。
しかし、これでもなお、三日でおかしくなるようだったらどうしよう。
ま、今回はバックアップがあるわけだけど。
ちなみにpkgだとzfstoolsは「/usr/local/sbin」の下にインストールされていた。
とりあえず、手元にあるMacBook AirからRaspberryPiで何かするにはBeelink S1を踏み台にしてRaspberryPiに入る必要がある。
たいした手間でもないし、ま、いいか、と思っていたのだけど、「ssh -Y」でいけんじゃね？
と思って。
ssh -Y ほげほげ 'ssh -Y ほげほげ２ emacs'
ってやったらほげほげ２のemacsをMacBook AirのＸ上に表示できた。
すばらしい。
調べてみると、多段sshという方法があるらしいのだけど、こちらはうまくいかなかった。何かミスっているのか、環境的にできないのか。
ssh_exchange_identification: Connection closed by remote host
ま、「ssh -Y」はうまくいっているし。モチベーション低し。Beelink S1のsshdあたりの設定かな、とは思うのだけれど。
さらにEmacsのtrampでもあっさりアクセスできたし。
/ssh:ほげほげ|ssh:ほげほげ２:/home/yamada/
ためしにハードディスクに換えてみようと、Beelink S1の筐体をあけた。
SSDがものすごく熱くなっていた。
もともとBeelink S1には冷却ファンがついていないし(たぶん)、筐体の密閉度も高い。熱くなりやすい構造なのだけど、CPUの発熱のせいだけではなく、もしかすると、SSD自体がけっこう発熱していたのかもしれない。そんな熱さだった。
これはハードディスクにしたくらいでだいじょうぶ、というものじゃないな。
/sbin/sysctl hw.acpi.thermal.tz0.temperature
で、チェックしてみてもあっさり50度越えしている。
これはやはり冷却ファンをつけるしか、ないか。
というわけで装備した。
そういえば 「HyperSpec」もpkgにあったので。
sudo pkg install clisp-hyperspec-7.0
で、インストール。
インストール先は
pkg list clisp-hyperspec-7.0
で、確認してemacsのinit.elに定義した。
(setq common-lisp-hyperspec-root "file:/usr/local/share/doc/clisp-hyperspec/HyperSpec/")
ふむ。だじょうぶそうだ。
Threadごとにconnectionを管理できるようにしたからだいじょうだと思っていた。たしかにThread二つまでは何ともなかった。それを四つにしたらおかしくなった。
いきなりPREPAREがすでに使われている、とエラーになる。
——？
どうして二つで動いていたものが、四つだと動かなくなる？
しかもすぐに起きることもあれば、しばらくたってから起きることもある。同じ処理をくりかえしているにもかかわらず。
三日、考えこんだ。
使っているライブラリも疑った。
どうデバックすれば、いいかも思いつかない。タイミングで発生しているのはあきらかで——それを補足するのはどうすれば、いいのだろう。ソース百遍。
三日目にしてようやく気づいた。
threadごとに管理しているconnectionはハッシュテーブルを使っている。
同時にこのハッシュテーブルにアクセスされたらどうなるんだろう？
あっ、まずいかもしれない。
ハッシュテーブルがthreadセーフなら別だが——。
どうやれば、それがわかるのか、わからなかったのでとりあえず対処した。
「with-lock-held」で処理を排他1。
それでエラーはいちおう起きなくなったように見えた。が、それは頻度が極端に減っただけで起きるときには起きる。あれ？
これがわからない。謎だ。
同じPREPAREがすでに使われているというエラーなのだが——たぶんthreadセーフじゃないところがまだ、どこかに残っているのだろう。あるいは使っているライブラリかもしれない。むずかしい。
これを避ける方法にはsqlを発行しているところをハッシュテーブルのときのように排他処理をかければ、いいのだが……それだと並列処理の意味がなくなってしまう。
threadひとつだけの場合とかわらないからだ。
まったくthreadで動くようにしたらthreadにした意味自体がなくなってしまう、という……。
なんて厄介な2。