最近の変更サイトマップ

FreeBSD 11からfreebsd-bootパーティションが64KBじゃ足りなくなった件

タイトルの通りでござる(ヽ´ω`)

SSDの入れ替えでパーティション作り直し中、例によってブートコードの書き込みを行おうとしたらgpart: /dev/ada15p1: not enough spaceと怒られた。

# ''gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada15''
gpart: /dev/ada15p1: not enough space

パーティションは入れ替え前の丸コピーであるからして、FreeBSD 10から11に更新した際、ブートコードの更新を忘れてたって事になる。FreeBSD 11にしてから5ヶ月経つというのに今まで気付かなかった…むしろ、よく古いブートコードで起動できてたなっていう。

一応ちゃんと調べてみたが、やはりFreeBSD 11.0-RELEASEで/boot/gptzfsbootの容量が87KiBに増加し、同頑張っても64KBのパーティションには収まらなくなった。エラッタにも、以下のようにしっかりと記載があった(ヽ´ω`)

[2016-10-21] The size of the GPT enabled ZFS boot blocks (/boot/gptzfsboot) has increased past 64K. Systems upgraded from older releases may experience a problem where the size of the existing “freebsd-boot” partition is too small to hold the new gptzfsboot.

さて、これはどうしたもんかね…。まぁどうしたもこうしたもパーティションを拡大するしかないわけだが、ブートパーティションはディスクの先頭にあり、その直後にシステム&データパーティションが続くというのが一般的な構成で、実際うちもそうだから拡大の余地は残ってないのだよ。特にFreeBSD 8/9時代にRootOnZFS環境を作って乗り継いできた人の大半に当てはまるんじゃなかろうか。

ディスクの後ろに空きがあるなら、そっちにfreebsd-bootパーティションに新設するってのが一番手っ取り早いか…。なんか凄い気持ち悪いのと、ブートローダの容量の壁(ディスクの先頭○GB以内に配置しないといけない系のやつ)にハマりそうな気がしなくもないが、2017年にもなって流石にもうないか?gpartのマニュアルによると、freebsd-bootパーティションは他のFreeBSD系パーティションの前か後ろに配置しなければならないそうなので、環境によっては完全に詰む可能性あり。

どうせ作り直すならばfreebsd-bootパーティションを超でっかくしたくなるが、最大545KBまでという制限もあるので要注意。起動時にfreebsd-bootパーティション全体がメモリに読み込まれるそうだが、容量的に古のコンベンショナルメモリの関係なのかしら?ゆとりの僕にはわかんないんです(・ω<)

これを機にUEFIブートに乗り換えるってのもありかなー。こっちはこっちでESPを確保しなければならないので、全く同じ問題を抱えてるわけですがね…。

ZFSと雖も不意の電源断でデータが破損する事がある

ちょっと前に家鯖が絶不調で、3.5インチHDD×4台のzpoolにアクセスするとフリーズする現象に見舞われていた。そのフリーズたるや生半可なものではなく、電源ボタン長押しすら受け付けず、コンセントぶっこ抜いた上に暫く放置してからじゃないと電源すら入らないというレベル。

すわ、電源ユニットが死んだか!?と思い早速手配し交換すべくサーバを開腹したところ、電源ファン前のフィルタが埃で目詰まりしていた。不調だったのは単に埃のせいで廃熱がままならず、サーマルプロテクションが動いてただけなんじゃないか疑惑。ま、もう電源買っちゃったし交換しときましたがね…。

こんな感じで、HDD×4台のRAID-Zは比較的短期間のうちに5〜6度に渡る不意の電源断にさらされたわけだが、いくら堅牢なZFSとはいえ流石に耐えられなかったようで。回復不能なエラーが発生し、ファイルが1つお亡くなりになってしまった。

$ sudo zpool status -v
パスワード:
  pool: zdata
 state: ONLINE
status: One or more devices has experienced an error resulting in data
    corruption.  Applications may be affected.
action: Restore the file in question if possible.  Otherwise restore the
    entire pool from backup.
   see: http://illumos.org/msg/ZFS-8000-8A
  scan: scrub repaired 0 in 64h6m with 2 errors on Sun Mar  5 06:42:20 2017
config:

    NAME         STATE     READ WRITE CKSUM
    zdata        ONLINE       0     0     2
      raidz1-0   ONLINE       0     0     4
        ada5p1   ONLINE       0     0     0
        ada4p1   ONLINE       0     0     0
        ada3p1   ONLINE       0     0     0
        ada2p1   ONLINE       0     0     0
    logs
      mirror-1   ONLINE       0     0     0
        ada15p4  ONLINE       0     0     0
        ada11p4  ONLINE       0     0     0
    cache
      ada11p5    ONLINE       0     0     0

errors: Permanent errors have been detected in the following files:

        /zdata/path/to/broken_file.wmv

scrub中にも電源断が起こったため、このような残念な結果になってしまったのだろう。初回scrubが出来ていれば、恐らくデータが壊れることはなかったと思う(個人的な経験に基づく推測)。

幸いにして死んだファイルはあ〜ん♡な動画だったため大した影響はなかったが、バックアップの重要性を考えさせられる良い機会となった。……とは言ったものの、個人でTBレベルの現実的なバックアップって難しいんだよなぁ。HDDにせよLTOにせよ、その都度引っ張り出してくるようでは面倒になってその内バックアップしなくなるのは目に見えてるし、かといって繋ぎっぱなしじゃバックアップの意味が薄れるし。流行のクラウドは容量も然る事ながら、自分の管理外の場所にデータを置くってのが信用できないし。

あ〜ん♡データの維持もなかなか大変である。

portmasterでPHP 5.5をモジュール含め一括でPHP 7.1に更新する

家鯖のPHPを5.5から7.1に更新した。

バージョン毎にportsが分かれているソフトを更新するときは、portmasterの-oオプションを使ってportmaster -o 置き換えるports(新バージョン) 置き換えられるports(旧バージョン)とする。そうしないと「php55-5.5.38 conflits with php71-7.1.1 (installs files into same place)」という具合に怒られる。

# sudo portmaster -o lang/php71 php56

PHPの場合、付随するモジュールも更新する必要があり、基本的には同じ方法で行う。しかし、1つずつportmaster -oしなきゃならなくて地味に面倒なんすよね(´・ω・`)。いい方法がないものかとネットを彷徨っていたら(この時間で手作業で更新できた説)、Stack Overflowに素敵な回答を発見。元のスクリプトだとdistfile削除プロンプトの入力待ちが正しく処理できなかったため、ちょっと改造させて貰った。

$ awk -vPATTERN="55" -vREPLACEMENT="71" \
'BEGIN { while (("pkg query -x %o \"/(mod_)?php" PATTERN "(-|$)\"" \
| getline name) > 0) { oldname = name; sub(PATTERN, REPLACEMENT, name); print "ALWAYS_SCRUB_DISTFILES=dopt portmaster --no-confirm -o " name " " oldname } }' \
| sudo sh

統廃合などで必ずしもモジュールが1対1で対応しなかったり、php-extensionパッケージは上手く扱えなかったりで、エラーなしで一発更新という訳にはいかないのが玉に瑕。でもこのスクリプトで更新作業はかなり楽になるハズ。PATTERNREPLACEMENTはお使いの環境に応じて書き換えてね(ゝω・)v

参考サイト

portsnapにautoなるコマンドが実装されてた

portsnapのmanを見ていたら、autoなる見知らぬサブコマンドが目に止まった。普段からportsnapとお戯れになっている人ならコマンド名から挙動の予想がつくと思われるが、portsツリーの状況に応じてサブコマンドをイイ感じに発行してくれるモードのようだ。FreeBSD 11から実装されている模様。

今までは

  • 初回はfetchしてextract
  • 2回目以降はfetchしてupdate
  • cronモードのときはupdateのみ

といった具合に人間様がコマンドを使い分ける必要があったが、これからはとりあえずportsnap autoしておけば良さそう。便利便利。

FreeBSD 11-STABLEでVirtualBox復活(`・ω・´)

3回に渡ってお送りしてきたFreeBSD 11.0-RELEASEでkern.proc.pathnameに失敗してVirtualBoxが動かない問題だが、無事解決。予想通り11-STABLEで問題なく動いた。

うちのデジタルデータ保管を一手に担っている結構重要な家鯖だし、STABLEを追いかける元気もないので、早いところ11.1-RELEASE出ないかしらー。これまでのマイナーリリース間隔から見るに、まだまだ先っぽいけど……。

start.txt · 最終更新: 2016-05-07 17:46 by decomo
CC Attribution-Noncommercial-Share Alike 3.0 Unported
www.chimeric.de Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0