- ベストアンサー
Redhat9のHDDにマウント
TurboLinux10DesktopをインストールしたHDDと、 Redhat9をインストールしたHDDがあります。 Redhat9をインストールしたHDDが突然カーネルパニックと表示されて起動できなくなりました。 データだけでも救出したいので（復旧するスキルは持ち合わせていないので）、 Turbo10をインストールしたHDDをプライマリに、 Redhat9をインストールしたHDDをセカンダリに接続し、 Turbo10上からRedhat9のHDDへマウントし、 中のデータをTurbo10側にコピーしよう、と考えました。 過去に同じ操作でTurbo10からTurbo10へのデータのコピー等の経験があり、できると思ったのですが、 Turbo10からRedhat9へマウントしようとすると「ファイルシステムタイプを指定する必要があります」と言われてマウントできません。 （Turbo10からTurbo10へのマウントの場合は自動で何かが選択されたらしく、ファイルシステムタイプを指定せずにマウントできました） ファイルシステムタイプとはどのようにすればわかるのでしょうか。 とりあえず、manコマンドの -t の項にあったファイルシステムタイプは全て試してみたのですが、 セカンダリに繋いだHDDへはマウントできませんでした。 （/sbin/fdisk -l にて、セカンダリのHDDがデバイスとして認識しているのは確認済みです） ファイルシステムタイプを調べる方法、 もしくはRedhat9ならコレだ、というのがあれば教えてください。
- みんなの回答 （7）
- 専門家の回答
質問者が選んだベストアンサー
その他の回答 (6)
- Lean
- ベストアンサー率72% (435/603)
＞ Filesystem state: not clean 正常にアンマウントされなかったので「not clean」なのでしょう。 ＞ Redhat9をインストールしたHDDが突然カーネルパニックと表示されて起動できなくなりました。 と質問にもあるから、正常にアンマウントされてはいないでしょうし。 一般的にUNIXでは、stateが「not clean」の状態はファイルシステムの整合性が取れていない状態になりますので、マウントを行おうとすると必ずエラーになります。 fsckを実行してファイルシステムの整合性をチェックすれば、stateが「not clean」でなくなる(cleanになる？)ので、マウントが行えるようになります。
お礼
> 正常にアンマウントされなかったので とありますが、このアンマウントはOSだかカーネルだかがシャットダウン時に行っていることですか？ 起動後の/bootのディレクトリは、どこかのディレクトリをマウントしているんだと認識していますが、 その関係でシャットダウン時にアンマウントが必要なんでしょうか。 電源をブチっと抜くような落とし方をするとHDDがガリガリ言って死ぬ他に、 アンマウントができてなくて死ぬことがある、 という意味でしょうか。
- cynthia4
- ベストアンサー率51% (186/358)
>この結果から何が得られるのかはちょっと…。 Filesystem state: not clean 以外は、正常の様です。 Super Block が、壊れているかどうか分かる。 壊れていなかったのか、復旧したのか分からないが 実は、壊れている状態を見た事がない。 もう何年もFSが壊れた事がないので。 mount 出来ない状態だったので言いませんでしたが fsck は、mount した状態では、やってはいけません。 簡単に言えば、自分で自分のfsck は、やってはいけない。 system は、起動途中の、mount されていない状態で 行う。または行える。 tune2fs 参照
お礼
カーネルパニックをはじめとする、「起動しなくなる」状態は頻繁にお目にかかります。 その時の状態がどうなっていたのかはわかりませんけど。 fstabが何らかの原因で消えることがあるらしく、 それを復旧させることで（今回のように別ディスクからマウントして）復帰することがある、 という経験からの知識だけありました。 なのでマウントできないと手ぇ出せませんでした。 起動できずに止まり、Ctrl+Dキーでrebootしろ、と表示される場合は、 その前の文に「fsckをかけろ」と書いてあったように思います。 つまり自分自身に対してfsckを、とあったように見えましたができるわけなかったんですね（やってみたけど無反応でした）。
- cynthia4
- ベストアンサー率51% (186/358)
そんなことは、無いと思いますが、一応 id 0x83 は、ext2、ext3 他に、ReiserFS も そうらしい。 RH9 が ReiserFS で install 出来るかどうかは忘れてしまった。 多分試していると思いますが、念の為。
お礼
補足ありがとうございます。 83だからext3というわけではないのですね。 試してみたところ、-t ext2 を付けてもマウントできました。 タイプを指定しないでマウントした場合は、mountコマンドで見たところ「type ext3」と表示されていました。 ReiserFSは、カーネルがサポートしてないそうで、反応しませんでした。
- cynthia4
- ベストアンサー率51% (186/358)
# /sbin/dumpe2fs -h /dev/hdc2 で、super block の 状態が分かる。多分
お礼
コマンドを実行してみました。 （fsckコマンドでマウントはできるようになった後ですが） Filesystem volume name: / Last mounted on: <not available> Filesystem UUID: ec03b35c-62af-4bf6-ba07-07b6d3b3ee1b Filesystem magic number: 0xEF53 Filesystem revision #: 1 (dynamic) Filesystem features: has_journal filetype needs_recovery sparse_super Default mount options: (none) Filesystem state: not clean Errors behavior: Continue Filesystem OS type: Linux Inode count: 9912320 Block count: 19816177 Reserved block count: 990808 Free blocks: 19496922 Free inodes: 9912425 First block: 0 Block size: 4096 Fragment size: 4096 Blocks per group: 32768 Fragments per group: 32768 Inodes per group: 16384 Inode blocks per group: 512 Filesystem created: Thu Feb 9 17:55:27 2006 Last mount time: Fri Oct 10 11:45:41 2008 Last write time: Fri Oct 10 11:45:41 2008 Mount count: 4 Maximum mount count: -1 Last checked: Thu Feb 9 17:55:27 2006 Check interval: 0 (<none>) Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) First inode: 11 Inode size: 128 Journal inode: 8 Default directory hash: tea Directory Hash Seed: 2352efc1-3535-430f-bf66-9ffe9f838f8b オプションの-hはスーパーブロックの情報を表示させるとの記述は見つけましたが、 この結果から何が得られるのかはちょっと…。
- Lean
- ベストアンサー率72% (435/603)
ファイルシステムのスーパブロックが壊れているようなら、下記URLのページにあるようなスーパブロックのバックアップを使用してファイルシステムの修復、スーパブロックの再作成とかの方法はあるけど、どういう状態なのかはっきり分からないのでこれで復旧するかは...。 ＠IT：壊れたパーティションを修復するには http://www.atmarkit.co.jp/flinux/rensai/linuxtips/728fixpartition.html
お礼
回答ありがとうございます。 復旧は無理そうですがデータ救出に関しては成功しました。 挙げていただいたサイトにあるような、 Give root passwrd for maintenance (or type Control-D to continue): という表示が出たことは過去に何度もあるのですが、 この状態からの復旧経験はありませんが、この状態ならマウントは可能だったのでデータは抜き出してきました。 （この表示が出た場合の原因が常に同じとは思えないので、常にマウント可能だとは限りませんけど） この方法で復旧できたかもしれないわけですね。 機会があったら試してみようと思います。 KNOPPIXのDISCは持ってないので作らないといけませんが。 ありがとうございました。
- cynthia4
- ベストアンサー率51% (186/358)
# fdisk -l の内容を書いて下さい。
補足
回答ありがとうございます。 以下が /sbin/fdisk -l の結果です。 現在操作中のプライマリTurbo10が/dev/hda*で、 マウントしたい対象は /dev/hdc2 です。 相手もTurbo10であれば、mount /dev/hdc2 /mnt/hdd というオプションの無いコマンドでマウントできました。 Disk /dev/hda: 80.0 GB, 80026361856 bytes 255 heads, 63 sectors/track, 9729 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/hda1 * 1 8 64228+ 83 Linux /dev/hda2 9 24 128520 82 Linux swap /dev/hda3 25 9729 77955412+ 83 Linux Disk /dev/hdc: 82.3 GB, 82348277760 bytes 255 heads, 63 sectors/track, 10011 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/hdc1 * 1 13 104391 83 Linux /dev/hdc2 14 9881 79264710 83 Linux /dev/hdc3 9882 10011 1044225 82 Linux swap よろしくお願いします。
関連するQ&A
- バッファローの親機とWTC-1167USをマニュアルどおり接続し、接続できません。
- WTC-1167USの再接続方法について教えてください。
- WTC-1167USの設定に必要な手順について教えてください。
お礼
回答ありがとうございます。 fdiskの結果から「Filesystem が壊れている」のはどこでわかるのでしょうか？ hda1とhda3には「＋」が付いていますが、異常だと付かないのですか？ マウントの際、 -t ext3 は実行しましたがマウントはできませんでした。 # fsck /dev/hdc2 を実行したところ、何度もyesかnoかの選択を求められ、デフォルトであるyesを選んでいたのですが、 あまりに長いので途中で強制終了しちゃいました。 が、その後 mount -t ext3 /dev/hdc2 /mnt/hdc でマウントすることができました。 （ファイルシステムタイプは付けなくてもマウントできました） マウントはできるようになりましたが、流石にカーネルパニックは直らなかったので、 データだけ救出してよしとします。 ありがとうございました。 余談ですが、Redhat9でもTurbo10でも、 起動時に停止して「fsckを実行しろ」とメッセージが出た場合は、 fsckを実行してもチェックしているようには見えましたが何も好転しませんでした。