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ならコレだ、というのがあれば教えてください。

No.2 ベストアンサー 回答者： cynthia4 回答日時： 2008/10/09 09:03

さて、どうしましょうか。

>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

Partition は壊れていない。
83 Linux　より ext3 でしょうが
Filesystem が壊れている様です。

# fsck /dev/hdc2
または、
# fsck.ext3 /dev/hdc2
をやるしかなさそうだが、直るかどうかは分からない。
ちょっと壊れているのではなく、FS として認識 していない。
駄目元で、やってみる。??

他の人が、他に良い方法をもしかして
投稿するかも知れない。待つ ??

data　の重要性があるなら
ddrescue を やった方がよい気もするが
対象の partition の 約1.5倍の容量が必要と言っているから
そう簡単にやれない。
http://japan.internet.com/linuxtutorial/20080523 …
/******
そう言えば 以前 RH9 の頃かな
よく 起動しなくなって、RH9　自身がfsck を起動したのだが
それで、直ったという記憶は無いですね。
*****/

この回答へのお礼

回答ありがとうございます。

fdiskの結果から「Filesystem が壊れている」のはどこでわかるのでしょうか？
hda1とhda3には「＋」が付いていますが、異常だと付かないのですか？
マウントの際、 -t ext3 は実行しましたがマウントはできませんでした。

# fsck /dev/hdc2
を実行したところ、何度もyesかnoかの選択を求められ、デフォルトであるyesを選んでいたのですが、
あまりに長いので途中で強制終了しちゃいました。
が、その後 mount -t ext3 /dev/hdc2 /mnt/hdc でマウントすることができました。
（ファイルシステムタイプは付けなくてもマウントできました）

マウントはできるようになりましたが、流石にカーネルパニックは直らなかったので、
データだけ救出してよしとします。
ありがとうございました。

余談ですが、Redhat9でもTurbo10でも、
起動時に停止して「fsckを実行しろ」とメッセージが出た場合は、
fsckを実行してもチェックしているようには見えましたが何も好転しませんでした。

お礼日時：2008/10/10 12:34

No.7 回答者： Lean 回答日時： 2008/10/11 18:36

＞ Filesystem state:　　　　　not clean

正常にアンマウントされなかったので「not clean」なのでしょう。

＞ Redhat9をインストールしたHDDが突然カーネルパニックと表示されて起動できなくなりました。

と質問にもあるから、正常にアンマウントされてはいないでしょうし。
一般的にUNIXでは、stateが「not clean」の状態はファイルシステムの整合性が取れていない状態になりますので、マウントを行おうとすると必ずエラーになります。
fsckを実行してファイルシステムの整合性をチェックすれば、stateが「not clean」でなくなる(cleanになる？)ので、マウントが行えるようになります。

この回答へのお礼

> 正常にアンマウントされなかったので

とありますが、このアンマウントはOSだかカーネルだかがシャットダウン時に行っていることですか？
起動後の/bootのディレクトリは、どこかのディレクトリをマウントしているんだと認識していますが、
その関係でシャットダウン時にアンマウントが必要なんでしょうか。
電源をブチっと抜くような落とし方をするとHDDがガリガリ言って死ぬ他に、
アンマウントができてなくて死ぬことがある、
という意味でしょうか。

お礼日時：2008/10/14 17:58

No.6 回答者： cynthia4 回答日時： 2008/10/10 14:11

>この結果から何が得られるのかはちょっと…。

Filesystem state:　　　　　not clean
以外は、正常の様です。
Super Block が、壊れているかどうか分かる。
壊れていなかったのか、復旧したのか分からないが

実は、壊れている状態を見た事がない。
もう何年もFSが壊れた事がないので。

mount 出来ない状態だったので言いませんでしたが
fsck は、mount した状態では、やってはいけません。
簡単に言えば、自分で自分のfsck は、やってはいけない。
system は、起動途中の、mount　されていない状態で
行う。または行える。
tune2fs 参照

この回答へのお礼

カーネルパニックをはじめとする、「起動しなくなる」状態は頻繁にお目にかかります。
その時の状態がどうなっていたのかはわかりませんけど。
fstabが何らかの原因で消えることがあるらしく、
それを復旧させることで（今回のように別ディスクからマウントして）復帰することがある、
という経験からの知識だけありました。
なのでマウントできないと手ぇ出せませんでした。

起動できずに止まり、Ctrl+Dキーでrebootしろ、と表示される場合は、
その前の文に「fsckをかけろ」と書いてあったように思います。
つまり自分自身に対してfsckを、とあったように見えましたができるわけなかったんですね（やってみたけど無反応でした）。

お礼日時：2008/10/14 17:54

No.5 回答者： cynthia4 回答日時： 2008/10/10 12:53

そんなことは、無いと思いますが、一応

id 0x83 は、ext2、ext3
他に、ReiserFS も そうらしい。
RH9 が ReiserFS で install 出来るかどうかは忘れてしまった。
多分試していると思いますが、念の為。

この回答へのお礼

補足ありがとうございます。

83だからext3というわけではないのですね。
試してみたところ、-t ext2 を付けてもマウントできました。
タイプを指定しないでマウントした場合は、mountコマンドで見たところ「type ext3」と表示されていました。
ReiserFSは、カーネルがサポートしてないそうで、反応しませんでした。

お礼日時：2008/10/10 13:24

No.4 回答者： cynthia4 回答日時： 2008/10/09 20:48

# /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はスーパーブロックの情報を表示させるとの記述は見つけましたが、
この結果から何が得られるのかはちょっと…。

お礼日時：2008/10/10 13:19

No.3 回答者： Lean 回答日時： 2008/10/09 19:11

ファイルシステムのスーパブロックが壊れているようなら、下記URLのページにあるようなスーパブロックのバックアップを使用してファイルシステムの修復、スーパブロックの再作成とかの方法はあるけど、どういう状態なのかはっきり分からないのでこれで復旧するかは...。

＠IT：壊れたパーティションを修復するには
http://www.atmarkit.co.jp/flinux/rensai/linuxtip …

この回答へのお礼

回答ありがとうございます。
復旧は無理そうですがデータ救出に関しては成功しました。

挙げていただいたサイトにあるような、
Give root passwrd for maintenance
(or type Control-D to continue):
という表示が出たことは過去に何度もあるのですが、
この状態からの復旧経験はありませんが、この状態ならマウントは可能だったのでデータは抜き出してきました。
（この表示が出た場合の原因が常に同じとは思えないので、常にマウント可能だとは限りませんけど）
この方法で復旧できたかもしれないわけですね。
機会があったら試してみようと思います。
KNOPPIXのDISCは持ってないので作らないといけませんが。
ありがとうございました。

お礼日時：2008/10/10 13:13

No.1 回答者： cynthia4 回答日時： 2008/10/08 15:54

# 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

よろしくお願いします。

補足日時：2008/10/08 20:14