- - PR -
/bin のクラッシュ
投稿者 | 投稿内容 | ||||
---|---|---|---|---|---|
|
投稿日時: 2005-06-06 10:10
おはようございます。
なんというか、壮絶なミスですね…。ご愁傷様です。 ( @IT の連載では /dev/nst0 とあった所を /dev/hda0 にかえるとは… )
一般的に、HD/CD の起動順序と、Master/Slave は関係ないように思います。 BIOS 設定の中に、Boot Sequence (起動順序) を変更するところがあるのではないでしょうか? さて、上手く CD起動ができたら、復旧を試みる前に、現状のディスクのスナップショットを取ることをお奨めします。何回でもやり直しがきくようになりますから。 具体的には、“dd if=/dev/hda0 of=バックアップ先ファイル名”として、パーティションのダンプを取る訳ですね。( バックアップ先は、データ保存用に使用していた hda1 内に確保するのが良いでしょう … 決して“of=/dev/hda1”では無いですよ ) hda0 には、バックアップファイルを格納していたのですよね? ( tarアーカイブか何かでしょうか? ) であれば、思いつく復旧方法としては、 ・e2fsck をして、lost+found に退避されたファイルから、バックアップデータに相当するものを探す ・debugfs をして、バックアップデータに相当するファイルを探す でしょうか…。いずれにしても、代替スーパーブロックを指定しないといけないでしょうね。( スーパーブロックは破壊されているでしょうから ) 上手く復旧できたら、是非手法をまとめて教えて頂きたいです。 それでは。 追記:単純に dd コマンドでパーティションのダンプを取ると、容量が膨大になりそうですね。gzip, bzip2 等の圧縮も絡めた方が良いかもしれません。 “dd if=/dev/hda0 | gzip > バックアップ先ファイル名”のように。 [ メッセージ編集済み 編集者: angel 編集日時 2005-06-06 11:00 ] | ||||
|
投稿日時: 2005-06-06 10:49
あ、/bin だけだからたいした分量は無いので、破壊されてるのは
Group 0 だけでしょうね。 ファイルシステムがext2だとして、の話ですが。 バックアップスーパーブロックを使えば後ろのほうのブロック グループはとくに問題なく拾い出せるんじゃないかしら。 | ||||
|
投稿日時: 2005-06-07 11:33
angel様、ぽんす様
詳しいアドバイス本当にありがとうございます スーパーブロックに関しては、知識がなかった為、 Webで色々検索いたしましたが、メモリ上で作用する ファイルシステムを管理する為の上位層だという事がわかりました。 ありがとうございます。 CD起動は、BIOS上CDの優先順位が上になっていたのですが、 起動しませんでした。しかし以下のようにケーブルを差し替えたら、 うまく起動させることができました。 <before> motherboad[0]---->CD-ROM---->HDD motherboad[1] <after> motherboad[0]---->CD-ROM---->なし motherboad[1]---->HDD------->なし まず、KNOPPIXを使用してみた感じを報告いたします。 クラッシュした本体のHDの構成は約20GB+スワップ+20GBというような パーティション構成でしたが、KNOPPIXにて、二つの20GBのHDは ”パーティションの認識?”という形では認識しておりました。 →デスクトップに ・Hard Disk Partition [hdd1] ・Hard Disk Partition [hdd3] という形でアイコンが表示されています。 oot@ttyp0[/]# dir /home/knoppix/Desktop CD-ROM\ [cdrom] KNOPPIX.desktop Trash hdd3 Floppy Knoppix-J hdd1 sample_japanese root@ttyp0[/]# しかしマウントされているドライブをdfでみてみると knoppix@ttyp0[dev]$ df -k Filesystem 1K-ブロック 使用 使用可 使用% マウント位置 /dev/root 2471 1094 1377 45% / /dev/cdrom 819200 711216 107984 87% /cdrom /dev/cloop 2064208 2033352 0 100% /KNOPPIX /dev/shm 819200 711216 107984 87% /cdrom2 /ramdisk 806948 6460 800488 1% /ramdisk /dev/hdd3 19675056 193208 18482392 2% /mnt/hdd3 knoppix@ttyp0[dev]$ というようになっていて、hdd1に関してはシステム的に はうまく認識はしていないようです。 また、認識されているhdd3ですが、中身は何故か空になっており、 2%の使用があり、/以下のディレクトリが書き込まれていました。 (おそらくKNOPPIXが、何度か起動しているうちに使用したと思われます。) knoppix@ttyp0[hdd3]$ dir /mnt/hdd3 bin cdrom etc initrd lib media opt root srv tmp var boot dev home initrd.img lost+found mnt proc sbin sys usr vmlinuz knoppix@ttyp0[hdd3]$ dir /mnt/hdd3/home/ knoppix@ttyp0[hdd3]$ それ以外は空の状態になってしまっておりました。 [quote]さて、上手く CD起動ができたら、復旧を試みる前に、現状のディスクのスナップショットを取ることをお奨めします。何回でもやり直しがきくようになりますから。 具体的には、“dd if=/dev/hda0 of=バックアップ先ファイル名”として、パーティションのダンプを取る訳ですね。( バックアップ先は、データ保存用に使用していた hda1 内に確保するのが良いでしょう … 決して“of=/dev/hda1”では無いですよ ) [/quote] dd if=/mnt/hdd1 | gzip > /mnt/hdd3/bkup-hdd1 という形でスナップを試みましたが、 root@ttyp0[hdd3]# dd if=/mnt/hdd1 | gzip > /mnt/hdd3/bkup-hdd1 dd: reading `/mnt/hdd1': ディレクトリです 読み込んだブロック数は 0+0 書き込んだブロック数は 0+0 0 bytes transferred in 0.001403 seconds (0 bytes/sec) bash: /mnt/hdd3/bkup-hdd1: 読み込み専用ファイルシステムです root@ttyp0[hdd3]# dd if=/mnt/hdd1 of=/mnt/hdd3/bkup-hdd1 dd: opening `/mnt/hdd3/bkup-hdd1': 読み込み専用ファイルシステムです とhdd3は何故か、読み込み専用ドライブとして認識されておりました。 後ほど、バックアップ先にUSBーHDDなどを接続できるかどうか 検証してみようかと思います。 問題の、認識されていない[hdd1]の方ですが、 何か対処を行なう良い方法はありそうでしょうか? 宜しくお願いいたします。 (ただ今、時間がない為、また後ほど検証結果をお伝えさせて頂きます。) それでは失礼いたします。 [ メッセージ編集済み 編集者: 虎エモン 編集日時 2005-06-07 12:21 ] |