6月 21, 2012

Windows7をバックアップイメージ経由で移動

パラレルATA接続のハードディスクでWindows7を使っていたのだけど、いい加減速度が遅いのでシリアルATAのハードディスクに移動することにしました。

パーティションをコピーするツールを使ってコピーしてみたのですが、ブートの情報までコピーされないのか起動してくれない。
そこで以前、Windows7のバックアップを経由して別ディスクに移動したことがあるので、この方法で行ったところはまりました。

結論から言うと「バックアップの取得時と復元時に余計なドライブを繋ぐな」 ということ。
以下が流れ。

コントロールパネルのバックアップから、「システムイメージの作成」で余っているハードディスクにバックアップをとります。
そして新しいディスクを繋ぎ、回復ディスクから、修復モードを立ち上げます。
(どうでもいいけど、回復ディスクをUSBメモリに出来ませんかね、マイクロソフトさん)

Windowsのような画面が起動し、IMEの種類を選択したところで、
このバージョンのシステム回復オプションは、修復しようとするWindowsのバージョンと互換性がありません。このバージョンのWindowsと互換性のある回復ディスクを使用してください
と言われて先に進めなくなってしまう。
はて、バージョンが違うってどういうこと?回復ディスクは以前作ったやつで、サービスパックが当たっていないから?

ということで、再度回復ディスクを作り直してチャレンジ。
しかし改善しない。

ハードディスクを繋ぎ直したりしているうちに気がついたのが、データ用ドライブに昔システムが入っていて、そのバージョンを認識してエラーが出ている様子。
回復ディスクで起動するときは、システムが入る予定のドライブだけを繋ぐことで突破出来た。
(なんでこれから回復するっていうときに、別のドライブの残りかすを見てエラーにするんでしょうか、マイクロソフトさん。バックアップイメージと回復ディスクのバージョンを比較するべきでしょう)

なんとか復元対象のバックアップイメージを選択し、回復がスタートしたところですぐにエラー。
システムディスクの回復に使用できるディスクが見つかりません
ディスクが見つからないとはどういうことか。
復元開始直前に、復元対象から除外するディスクを選択出来る画面があったのですが、そこでは復元先ディスクが表示されていました。
もちろん除外対象にもなっていません。

ネットで検索してみたところ、どうやらバックアップ時に接続されていたディスクの容量からサイズが減るとこのエラーが出るらしい。
このとき、バックアップ時にデータドライブが繋がっており、バックアップ対象にはしていないのに回復時に存在しないため、容量が足りないと認識されていたようだ。
(何この仕様?)


結局、バックアップを取るときにはシステムドライブと、バックアップイメージ保存ドライブだけを繋いでバックアップ。復元時は、復元先ドライブと、バックアップイメージ保存ドライブ、CD/DVDドライブだけを繋いで起動するとよいようです。

もうちょっと分かりやすい仕様になりませんかね。せめてメッセージだけでも。マイクロソフトさん。

6月 15, 2012

tar.bz2なバックアップファイルが復元出来なかった(解決)

tar.bz2なバックアップファイルが復元出来なかった。
bzip2: Data integrity error when decompressing.
        Input file = (stdin), output file = (stdout)

It is possible that the compressed file(s) have become corrupted.
You can use the -tvv option to test integrity of such files.

You can use the `bzip2recover' program to attempt to recover
data from undamaged sections of corrupted files.

tar: アーカイブ中に予期せぬ EOF があります
tar: アーカイブ中に予期せぬ EOF があります
tar: Error is not recoverable: exiting now
70GBのファイルを20GBまで圧縮してあるのだが、どうやら壊れてしまったようだ。
bzip2recoverを使えということで、使ってみる。
   block 49998 runs from 108483591327 to 108485995530
   block 49999 runs from 108485995579 to 108488398408
   block 50000 runs from 108488398457 to 108490796940
bzip2recover: `all0609.tar.bz2' appears to contain more than 50000 blocks
bzip2recover: and cannot be handled.  To fix, increase
bzip2recover: BZ_MAX_HANDLED_BLOCKS in bzip2recover.c, and recompile.
50000ブロック以上には対応出来ないようだ。
コンパイルし直せとのこと。

http://www.bzip.org/
からソースをダウンロード

bzip2recover.cの真ん中ぐらいに
#define BZ_MAX_HANDLED_BLOCKS 50000
という記述があるので、これを増やすと良いらしい。

tar.bz2のファイルサイズは21,113,008,629なんだけど、どのくらいまで増やせば良いのだろう。
この進捗に表示されている108,490,796,940を調べてみる。
ソースを追いかけてみると、このfromとtoはbStartとbEnd、そして他の場所に
bStart[currBlock] = bitsRead;
という記述があることから、ビット表記らしい。
ファイルサイズをビット換算すると168,904,069,032。
8分の5ぐらいのところまで処理しているようなので、余裕を持って2倍にしてみる。
#define BZ_MAX_HANDLED_BLOCKS 100000
configureなどはないので、直接make。

再度bzip2recoverを実行。
ls
rec15610all0609.tar.bz2  rec31226all0609.tar.bz2  rec46842all0609.tar.bz2  rec62458all0609.tar.bz2  rec78074all0609.tar.bz2
rec15611all0609.tar.bz2  rec31227all0609.tar.bz2  rec46843all0609.tar.bz2  rec62459all0609.tar.bz2  rec78075all0609.tar.bz2
rec15612all0609.tar.bz2  rec31228all0609.tar.bz2  rec46844all0609.tar.bz2  rec62460all0609.tar.bz2  rec78076all0609.tar.bz2
rec15613all0609.tar.bz2  rec31229all0609.tar.bz2  rec46845all0609.tar.bz2  rec62461all0609.tar.bz2  rec78077all0609.tar.bz2
8万近いファイルが生成された。

これを結合しつつ展開
find . -name "rec*.bz2" | sort | xargs -n1 bzcat | dd bs=65536 | tar xvf -

all0609.pgbackup

bzcat: Data integrity error when decompressing.
        Input file = ./rec15012all0609.tar.bz2, output file = (stdout)

It is possible that the compressed file(s) have become corrupted.
You can use the -tvv option to test integrity of such files.

You can use the `bzip2recover' program to attempt to recover
data from undamaged sections of corrupted files.
どうやらrec15012all0609.tar.bz2がまだ壊れているようだ。
このファイルだけを再度bzip2recoverに掛けてみたが、エラーは消えず。
結局この部分だけを破棄することとなった。

6月 10, 2012

glibc 2.15のビルドがループする(未解決)

CentOS5.8にgcc 4.7が入っている環境で、glibc 2.15をビルドしようとすると、nptlのところで延々とループしてしまう現象に遭遇した。
検索してみると、「時計が狂ってるんじゃない?アハン?」「VMだったから狂ってたよ!イエアー」みたいな感じで解決してしまっていた。
しかし、うちの場合は実マシンに直接入ってるし、dateコマンドを叩いてみても正しい時刻が返ってくる。

途方に暮れていたところ、別の検索結果から、インストール先のincludeを消すか名前を変えたら上手く行ったよ、という書き込みを発見。
/usr/localにインストールしようとしているときに、/usr/local/includeの方を参照しちゃって、まずいことになるらしい。

早速、
mv /usr/local/include /usr/local/include_org
としてconfigureしてみると、ヘッダファイルが見つからないというエラー。
そ、そうか…。

元に戻して、configureをしてから/usr/local/includeをリネーム。
すると、gd.hが見つからないというエラー。
確かに、gd.hも/usr/local/includeに入っていた。

もう一度、configure --helpを見直すと、gdのインクルードディレクトリを指定するオプションがあった。
もしかして、このために?というようなオプション。

結局、以下のような手順で問題の箇所は通過出来た。

1.ソース展開
  tar jxf glibc-2.15.tar.bz2
2.展開したディレクトリに入る
  cd glibc-2.15
3.ビルドディレクトリを作る
  mkdir -p build
4.ビルドディレクトリに移動
  cd build
5.gdのインクルードディレクトリを参照するためのシンボリックリンクを用意
  ln -s /usr/local/include /usr/local/gd
6.configure
  ../configure --disable-sanity-checks --with-gd-include=/usr/local/gd
7.インストール先のincludeディレクトリをリネーム
  mv /usr/local/include /usr/local/include_org
8.シンボリックリンクの先が居なくなってるので張り直し
  rm -f /usr/local/gd
  ln -s /usr/local/include_org /usr/local/gd
9.make
  make

しかし、その後もmakeでエラーが頻発し、もう前にも後ろにも進めないという状態。
結局諦めた。


1.そもそもの発端は、MongoDBにアクセスするC++プログラムを書きたい。
2.標準で入っているboost 1.33では、古くてビルドが通らない。
3.boost最新版がgcc4.1でビルド出来ない。
4.gcc4.7を/usr/localに入れる。
5.phpが起動しなくなった。
6./lib64に入っているlibc.so.6(glibc 2.5由来)と/usr/local/lib64/libc.so.6(glibc 2.15由来)が衝突している(後者を読んで欲しいのに、前者が読まれる)

というようなことで、いろいろ環境を立ち直らせたかったのですが、gcc4.7はまだ早すぎたようです。

結局CentOS6.2を入れ直して標準のgccのバージョンが上がれば…と期待しつつ、システムを入れ替えることにしました。
アップグレードはサポート対象外とのことで、再インストールを予定しています。とりあえずはyumからのアップデートも試してみようかと思います。成功した報告はないらしいのですが。