[FreeBSD-users-jp 94076] 9.1-R and qjail
戸川です。 9.1-RELEASEの配布物がFTPサイトに置かれはじめたので、qjailを使って jailを作ってみようと思ったのですが、エラーで挫折しています。 環境は root@kotoko:/usr/jails # uname -a FreeBSD kotoko.vegalta.org 9.1-RELEASE FreeBSD 9.1-RELEASE #12: Sat Dec 8 14:30:46 JST 2012 r...@kotoko.vegalta.org:/usr/obj/usr/src/sys/GENERIC amd64 です。 まず、qjail installを試みたところ、 root@kotoko:/usr/jails # qjail install (中略...fetchの出力) The base RELEASE distribution files are populating the fulljail. Est LT 1 minute elapse time for this to complete. The lib32 RELEASE distribution files are populating the fulljail. Est LT 1 minute elapse time for this to complete. Basejail newjail are being populated. Est LT 1 minute elapse time for this to complete. Error: Installation of sys failed. ということで、sysのインストールでエラーで止まってしまいます。 次に、qjail install -cを試したのですが、 root@kotoko:/usr/jails # qjail install -c [: -ge: unexpected operator Starting to clone host directory tree to fulljail. Est LT 3 minute elapse time for this to complete. Note the hosts /usr/src /usr/ports /usr/local directory trees are NOT being cloned. Error: Installation of proc failed. root@kotoko:/usr/jails # ということで、procのインストールで止まってしまいます。 (最初のtestのエラーも気になります) どなたか解決策がおわかりの方はいらっしゃいませんか? よろしくお願いします。 以上です。 -- TOGAWA Satoshi t...@puyo.org
[FreeBSD-users-jp 94077] Re: graid3 の復旧
いとうといいます． メタデータの格納位置と構造がおおよそわかったので，時間がとれたときに チャレンジしてみようかと思います． 結果をご報告いたします． 結論から申し上げますと，ほぼヨミ通りにメタデータを細工するだけで graid3 の復旧ができました．ヨミと異なっていたのは以下のとおりです． - md_dflags は 0 だった(正常) - 値が変わっていたのは md_genid だった - シングルユーザーモードで起動した時に見えていた HDD のモノは 0 - 見えていなかった HDD のモノは 7 - 通常はブロバイダ内ですべて同じ値が格納されている - md_genid が最大値と異なる HDD は使用されない ということのようで，メタデータを書き換える個体の数を減らすために， - 見えていた HDD の md_genid を 0 に - ハッシュ値を計算しなおして md_hash[] をその値に メタデータを書き換えることで無事に復旧できました(只今最終チェック中)． なお，今回の作業でディスクエディタを探したのですが，大変良い物を見つけ たので，ご紹介いたします(Windows 版ですが)． HxD http://mh-nexus.de/en/ 元々はバイナリエディタのようなのですが，管理者権限で動作させることで ハードディスクもエディットできるものです． 範囲指定したデータの MD5 を計算して表示してくれる機能があり，ハッシュ 値計算にそのまま利用でき，作業が簡略化できました． 今回は，大変お騒がせしました． # zfs とかだと，こうはいかないんだろうなぁ 2012年12月13日 17:07 Yoshiharu ITO yochy4...@gmail.com: いとうといいます． たびたびすいません． メタデータの格納位置と構造がおおよそわかったので，時間がとれたときに チャレンジしてみようかと思います． が，ちょっと先になりそうですので，もしこれよりもまっとうな方法をご存知の 方がいらっしゃいましたら，お知らせいただけると嬉しいです． 以下，メモになります． - メタデータはプロバイダが管理している領域の最終セクタに格納されている - GEOM::RAID3 で探せば見つかるだろう - sys/geom/raid3/g_raid3.h にある stuct g_raid3_metadata がメタデータ の構造だが過去のモノも含めると 3 通りあるようだ - それを見分けるのは md_version である - ディスクの状態を示すのは md_dflags である - これの G_RAID3_DISK_FLAG_BROKEN が立っているのだろう - メタデータの有効性を確認するためのハッシュ値も格納されているからメタ データをいじったらハッシュ値も更新しておかないとダメ 2012年12月13日 13:42 Yoshiharu ITO yochy4...@gmail.com: いとうといいます． 大変申し訳ありませんが，お知恵を拝借できないでしょうか． 当方 HDD 5 台で graid3 を運用しておりました． やんごとなき理由からハードウエア構成変更のため SATA ケーブルの抜き差し を含む作業を行った後に，シングルユーザーモードで起動確認を行いました． すると，こともあろうに SATA ケーブルの接続ミスで 2 台 HDD が見えない状態 になってしまっていて，RAID3 が DEGRADED するどころか，その時に見えてい た HDD 全てが broken したことになってしまい，最終的に too few valid components. と graid3 プロバイダすら起動しなくなってしまいました(ここポイント)． データ部へのアクセスは行なっていないわけですから，メタデータ部だけを何とか すれば復旧するのでは，つまり graid3 label をするだけでいいのかなぁと考えて みたりもしておりますが # g_raid3_metadata って HDD のどこに格納されてるんだ とか探してみたり このような状態から復旧させる，よい方法は無いでしょうか． 以上，よろしくお願いいたします． -- よっちい -- よっちい -- よっちい
