青木@名古屋です。 On Tue, 27 Feb 2024 20:50:36 +0900 Tomoaki AOKI <junch...@dec.sakura.ne.jp> wrote:
> 青木@名古屋です。 > > On Tue, 27 Feb 2024 19:42:35 +0900 (JST) > Hiroki Sato <h...@allbsd.org> wrote: > > > 佐藤です。 > > > > Shigeki Yoshida <sh...@iamas.ac.jp> wrote > > in <CAOL1=qjgn_dfv9k6gsnhnxhnjar92d9zpy8jbmwx5nxpkpb...@mail.gmail.com>: > > > > sh> 最近 12.4 から 13.2 にアップグレードしたのですが、2, 3 台目の HDD がマウントできなくなりました。 > > sh> > > sh> root@shige1:/etc # mount /dev/ada1s1e /mnt > > sh> mount: /dev/ada1s1e: Invalid fstype: Invalid argument > > sh> > > sh> この時 messages には以下のようなメッセージが10回くらい繰り返し書かれています。 > > sh> > > sh> Feb 26 17:38:56 shige1 kernel: UFS1 superblock failed: fs->fs_old_cpg > > (89) > > sh> != 1 > > sh> (1) > > sh> Feb 26 17:38:56 shige1 kernel: UFS1 superblock failed: fs->fs_old_spc > > sh> (4096) != > > sh> fs->fs_fpg * fs->fs_old_nspf (364544) > > sh> Feb 26 17:38:56 shige1 kernel: UFS1 superblock failed: fs->fs_old_ncyl > > sh> (38159) ! > > sh> = fs->fs_ncg (429) > > > > 上記のメッセージは、UFS のスーパーブロックに書かれている情報に > > 矛盾があることを示しています。13.2 以降では情報のチェックが厳しくなったため、 > > 今までマウントできていたものがマウントできなくなることがあります。 > > > > 表示されている fs_old_cpg や fs_old_spc 等でマウントできなくなる症状は、 > > 次の PR でも報告されています。 > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264450#c21 > > > > FreeBSD の古いリリース（9 以前）で作成された UFS1 の一部に、 > > 矛盾したパラメータが設定されているケースがあることが分かっています。 > > > > しかし、これらのパラメータは実際にはほぼ使われておらず、矛盾した値であっても > > マウントして読み書きする使い方で支障が生じることはありません。 > > PR にも経過が書かれていますが、値を厳密にチェックしても害のほうが大きいため、 > > 15-CURRENT では 2/20 でチェックを緩和する変更が入りました。 > > 今後の 13, 14 系にも、同じ変更が入ります。 > > > > ファイルシステムパラメータの値の矛盾を修正すれば良いのですが、 > > 手動で直接バイナリデータを変更するくらいしか手段がありません。 > > fsck 等のツールでパラメータを自動修正することはできませんし、 > > カーネルが行なっているエラーチェックを回避する方法も、残念ながら用意されていません。 > > 13, 14 系にチェック緩和の変更が反映されても、現状で厳しいチェックを > > 行なっている 13.2R 等は、この問題に対応する Errata Notice が出るまで使えないままです。 > > > > パラメータに矛盾があるファイルシステムになってしまっていることは > > 確かですから、面倒でも新しくファイルシステムを作成し、 > > dump + restore 等で中身を移すのが将来的にも安心かと思います。 > > > > -- Hiroki > > やっぱりそうでしたか。 パーティションテーブルの問題ではなさそうなので > fsckあたりを追っかけて何らかのOPTION等無いか探しかけて手に負えなくなって > 断念していました。 > > 件の修正はこれ[1]でしょうか？ stable/13へのMFCを経てのreleng/13.3への > MFSは13.3-RELEASEに間に合うのでしょうか？ > > 自力でsrcから更新できて、このコミットを手動でcherrypickして問題ないなら > 待たずに再構築してしまうのも手ですが。 > > ＃ 私の場合、git cherrypickを使わずcgitの当該コミットのページで > ＃ author行から末尾のボーダー直前までをエディタにcopy&pasteした > ＃ ものをパッチとして当て、次のsrcの更新時はgit pullの前にgit stash > ＃ しておき、更新後git stash applyで戻しています。 MFCされたものが > ＃ あればgit stashの前にpatch -Rで切り戻すのですが、たまに見落として > ＃ conflictの手修正を迫られます。 ならローカルで独自のbranch切って > ＃ 処理しろと言われそうですが、未だgitの仕組みを把握しきれていないので > ＃ 手許のcommitログが手違いで本家と矛盾する状況の方が恐いのです。 > ＃ n番号がズレたりしたら他の方との話が無茶苦茶になるので。 > > [1] > https://cgit.freebsd.org/src/commit/?id=b241767f8ef38f9ca7c109fe2fccd11ccbfaa4f0 > > -- > 青木 知明 [Tomoaki AOKI] <junch...@dec.sakura.ne.jp> 件の修正コミットがstable/14 [2]とstable/13 [3]にMFCされましたね。 ただ、13.3-RELEASEについては3月1日にRELEASE準備のコミット[4]が されていてRELASEのタグも打たれてしまった[5]ので、後々-p1等の 更新が入るときに一緒に入るか、重要性を考えて巻き直されるかが 微妙ですね。 一応、記憶違いがなければ過去に一旦リリースの ビルドが済んでしまってから緊急の更新を入れてやり直したことが あったと思いますので、Colinも難しい判断を迫られているかも しれません。 ※-p1等のパッチレベル更新は、次の同ブランチからのリリース (14.0→14.1等のレベル）のようにstableからブランチされる の【ではなく】、原則セキュリティ修正やそれ以外の重大な 問題の修正のコミットだけを選んで取り込む（Cherry pick） 形なので、リリースエンジニアリングチーム(RE)やセキュリティ オフィサー(SO)の判断次第ですね。 確か現在はどちらも Colinが仕切っていたと思いますが。 [2] https://cgit.freebsd.org/src/commit/?h=stable/14&id=fdfb8e783c3e8606d1294f9772fbd1496994b581 [3] https://cgit.freebsd.org/src/commit/?h=stable/13&id=8c6964b779cecbcf42475c896e5c61df192b80b9 [4] https://cgit.freebsd.org/src/commit/?h=releng/13.3&id=80d2b634ddf0b459910b54a04bc09f5cbc7185a7 [5] https://cgit.freebsd.org/src/tag/?h=release/13.3.0https://cgit.freebsd.org/src/tag/?h=release/13.3.0 -- 青木 知明 [Tomoaki AOKI] <junch...@dec.sakura.ne.jp>
