
Ubuntu日本語フォーラム

ログインしていません。
私の方はHDDが認識できるので有れば当初から考えは変わりません。
HDDのフォーマットです。
MBRについてはパーティションを新たに作成することで必要な情報は書き込まれます。
MBRの起動部分の情報はブートローダーを入れる事で(OSのインストール作業)で書き込まれます。
HDDの認識が安定下もので有れば「CMOSクリア」や「ケーブルの確認」は必要有りません。
原因は突発的な電源遮断の為にファイルシステムに異常が出た可能性が大なので「testdisk」は効力を発揮しないでしょう。
必要なデータがある場合はライブCDからHDDをマウントすれば良いのですがLVMが邪魔をして出来ないかもしれません。
「fsck」は今回の症状からの修復コマンドですが「実行しない事」を強く奨めます。
壊れたファイルシステムの整合性を保つために異常な箇所を切り離して帳尻合わせしますので、より複雑怪奇に起動しなくなるか、上手く起動しても実用性が保たれているかどうかの賭的な要素が強く有ります。
今回のケースでは「100害有って一利有る時も有る」でしょう。
LVMの再構築は必要性が無い場合は避けた方が良いかもしれません。
この様な事態で暗号化されたディレクトリからのデータ救出方法を確保しようとされているメンバがいましたが、同じようにLVM構築機で不具合が発生したときの影響とデータ救出方の情報を得てからLVMでの運用をされた方が良いかも。
オフライン
私の経験談で、的を射てない可能性が高いです。
HDDがおかしくなりデータをあきらめ、ライブCDで起動してフォーマットをしたのですが、
HDDの領域がグチャグチャになってしまったらしく、できませんでした。
手持ちのソフト、および他のPCに接続して対処しようとしたのですが、古いのでダメでした。
そこで、自宅から一番近くにあるPC工房さんへ、不具合HDDを持ち込みました。
顛末はこちらです。
https://forums.ubuntulinux.jp/viewtopic … 604#p48604
不思議なことに、HDDが正常に復帰しました。
現在、快適に他のPCの心臓部として働いています。問題も皆無です。
オフライン
※規約違反により追放されたユーザの投稿は、ログインユーザにのみ表示されます。
オフライン
※規約違反により追放されたユーザの投稿は、ログインユーザにのみ表示されます。
オフライン
>HDDのフォーマットです。
①Gpartedで/dev/sdaを選択、フォーマット>ext4を選択
フォーマットを実行したのですが、失敗してしまいそれ以降/dev/sdaのファイルシステムがext4から不明になってしまいました。
②Gpartedで「デバイス」ー「パーティションテーブルの作成」
作成中に失敗のメッセージが出力されました。
上記①、②に共通していることは一度失敗するとデバイスを認識しなくなり、再起動すると新たにデバイスを認識する事です。
>HDDの領域がグチャグチャになってしまったらしく、できませんでした。
私のPCも似たような症状かもしれません、持ち込むしかないのでしょうか。。。
オフライン
基本的に空っぽにしているので、メーカー謹製ツールでZerofillして、不良クラスタを潰したとか、設定を安定側に振ったとか、そんなところが真相じゃないですかね?
実際の所フォーマットを掛けられてしまっているので、作業が明確にならないと実は誤魔化されたんじゃないかと思わなくもないです。
まぁ、代替セクタとの交換は仕様の範囲内なんですけど、代替されたセクタが増えないかはちょっと気をつけた方が良いような。
ブートコードの変更で何とかなるとはおもえないんだけどなぁ。
オフライン
※規約違反により追放されたユーザの投稿は、ログインユーザにのみ表示されます。
オフライン
#24でも書きましたが、HDDドライブを1台にし、「ドライブ全体を削除しインストール」を選択してインストールを実行する。
経験からですが、ubuntu9.10のインストール時のドライブのサーチ能力は非常に高くBIOSでHDDドライブをOFFに設定していたのを認識し、インストール可能ドライブとして表示
されたので、慌ててインストールを中止し、HDDの電源コネクタを外しその後インストールを実行しています。
Gpartedを使用してインストール前にパーティション操作をしたい時はntfsでフォーマトを薦めます。
オフライン
fjkさん
ご指摘の事例と同様で、私の1年も使用していないSATAのHDDは、Gpartedでパティションを操作したことで、
本当にグチャグチャになった様です。
パティションを変更はできるのですが、そのときフォ−マットの途中で止まってしまいます。
どうにもならなくなり、ショップに持ち込みました。
普通は、なにがしかのサポ−ト料金を取るようですが、そこは話の持って行きようで無料になります。
新しいHDDを購入したついでに、ちょっと調べてくれないかで。。。
チラッと見ただけなので名前は忘れましたが、物理フォ−マットに近いことを行う特殊なソフトがあるようです。
教えてくれと担当者に言いましたが、隠されてしまいました。
オフライン
パーティションテーブルは、MBRと同じブロックにあるそれだけです。
従って「どういじろうと」それがこんがらがることは無いです。見ての通り、四つ分の開始、終了位置の指定と少々の付随するデータしかないわけですから、それらの値が相互に矛盾を起こす以上のことは普通は起きません。
再帰構造を持つ拡張パーティションはその限りではないのですが、解放してしまって良いのなら、切り離せるのでこれも問題はないはずです。
testdiskを含むツールの類は、テーブルそのものではなくて、恐らくその辺りにあるであろうシリンダ境界を基準に「それっぽいデータを探し」て「テーブルを捏造し」ます。
で、経験則から言うと、どうもUbuntuのインストーラの類は「大きなお世話」でファイルシステムを作ろうとする場所の近辺にデータがないか探して、余計なことに見つけるとそれを有効な物として初期化を強行しない節があります。
8.04LTSでそうだったのですが、対処としては、領域の切り方をへんこうするか、別のFAT32等のファイルシステムを一度作り、残骸を上書きしてから、再度作らせようとすると素直に動作してくれるようです。
(明示的に操作を指定してわかってやってんのに適当に余計なことを推測で実行するのはWindows様か!と思ったことはUbuntuに関しては他にも有るのですけれどもw)、そんな事がありましたので「わざと上から別のファイルシステムを書いてやる」ことで、「何か有るみたいだからエラー出してやめてしまえ」という大きなお世話は回避できます。
方法としてはWindowsのインストールディスクでも、fdiskでもなんでもいいのですが、いったん空の別の(できればLinux標準ではない)ファイルシステムをダミーで作って痕跡を消してやると確実な気はします。
痕跡がなければいいのですから、当然zerofillなど、データを上から書いてしまえば同様の状況を作ることが出来ます。
また、パーティションテーブルではなく、データの痕跡に怖じ気づいて上からファイルシステムを構築することを躊躇するような動作が原因である場合、パーティションテーブルを弄っても何の効果もありません。
あと、ちょっと気になるのは、ブートフラグが二つ付いていること。
標準のチェインローダが色々HDDなり、パーティションなりあるけど、どこから起動したら良いんだろう?というときに参照するフラグですので、ドライブごとに一つはーいと手を挙げていて、且つ、余計なことをするBIOSが矛盾や問題を探そうと何か処理をした場合、結果は迷走する可能性が有りそうです。フラグ自体はパーティション構造を示す物ではないので、そのブートセクタに処理が遷移して、実行できればいいので、逆にフラグをいくつもたてるのは、問題の原因にはなっても、解決には繋がらないのではないかと。
本来は何もしないはずのBIOSが余計な気を回すことは意外と有るので、油断大敵な気はします。
現象が「ファイルシステムを作れない」ことが「セクタの障害」なら、代替セクタの割り当て。余計なお世話によって強行してくれないだけならデータの上書きによって解決しただけだと思うので、原因と、対処は明確にしないと間違った情報になって都市伝説が一つ増えてしまうことになりますね。
オフライン
fjk による投稿:
>HDDのフォーマットです。
①Gpartedで/dev/sdaを選択、フォーマット>ext4を選択
フォーマットを実行したのですが、失敗してしまいそれ以降/dev/sdaのファイルシステムがext4から不明になってしまいました。
②Gpartedで「デバイス」ー「パーティションテーブルの作成」
作成中に失敗のメッセージが出力されました。
上記①、②に共通していることは一度失敗するとデバイスを認識しなくなり、再起動すると新たにデバイスを認識する事です。
>HDDの領域がグチャグチャになってしまったらしく、できませんでした。
私のPCも似たような症状かもしれません、持ち込むしかないのでしょうか。。。
う~ん、試せる事を実行してから出してみるのも有かな。
・Gpartedで/dev/sda1 を削除のみを実行してエラーの確認。
・新規作成で失敗した場合「詳細」の▽マークを掘り下げてエラー内容をお願いします。
・不明なファイルシステム(黒ブチ)が/dev/sda1 である事を確認
・$ sudo fdisk -l で /dev/sda1 の存在を確認
・$ sudo badblocks -vs /dev/sda で不良セクタの確認
・$ sudo mkfs.ext3 -c /dev/sda1 もう一度デバイスのチェック後、フォーマット
・エラー表示の場合はGpartedのエラーと比較。
・Gpartedからパーティションを2つ以上切ってからフォーマットした結果をみてみる。
(これはシステムが原因の時には良いが、ライブCDからだと意味がないかな)
・/dev/sdb を先にフォーマットしてみる。
・3988さんの案、HDDを一つ外してフォーマットしてみる。
・/dev/sda のパーティションを削除した状態でMicrosft様のパーティションエディタ(インストールディスク)を試してみる。
オフライン
hir0 による投稿:
Microsft様のパーティションエディタ(インストールディスク)を試してみる。
/dev/sda のパーティションを削除した状態に関係なく、私の試行した方法
要はWindows XP_pro SP2をデ−タがなくなるのを覚悟で、HDDにインスト−ルする手段です。
この場合、標準ではSATAをサポ−トしてない古いOSのため、メ−カからdownloadしたドライバ−を
フロッピ−で導入します。
普通なら、すんなりntfsでフォ−マットできるのですが、この不具合がでたHDDは途中で
セクタ−書き込み不良エラ−が表示され、止まってしまいました。
不思議なことに、ショップにて比較的新しいマザ−ボ−ドおよび最新のWindows OSだと、何事もなく
ntfsでフォ−マットが完了しました。
よって、皆さんが使われている新しめの機種なら、問題なくformatできると思います。
オフライン
#オフトピ
普通なら、すんなりntfsでフォ−マットできるのですが、この不具合がでたHDDは途中で
セクタ−書き込み不良エラ−が表示され、止まってしまいました。
不思議なことに、ショップにて比較的新しいマザ−ボ−ドおよび最新のWindows OSだと、何事もなく
ntfsでフォ−マットが完了しました。
koisan1949さん、今晩は!
う~ん、一体何処が引っかかってダメだったのか、何処が良くて上手く機能したのか気になりますね。
やはりエラー文は予め用意された文の表示だから、多少は諦めずに抗ってみると吉なのかなぁ。
フォーマットのツールの性能差って有るのかなぁ。
結構にた問題でUSBデバイスでは遭遇したけどHDDだと頭を抱えちゃいますね、抜き差しとかデバイスファイルの変更とか大変だし怖いし、、、
「/dev/sda のパーティションを削除した状態」はExt形式が残っているとWindows側で認識できずに失敗するって話が有ったと思ったのだけど、「フォーマットするから関係ないよ」って以前メンバから教えてもらいました。
にも関わらず同じ事を繰り返す私の学習能力&記憶力の低さorz
それにしても上手く行くと良いのですが、、、
オフライン
こんにちは
同じ容量の内蔵HDDが2台あれば、LVMやRAIDを疑ってかかるのが普通ですが、ためしに、LiveCDで仮想端末から、"sudo dmraid -s"
とやってみてください。これで何か表示されればRAIDです。普通は1台のみLVMというのは考えにくいのです。
というのは、LinuxのRAIDで使っていたものを別の使い方をするとインストラーが認識できない場合あり(ただし、Fedora12、Ubuntu9.10)。
その場合は
① 一度NTFSでフォーマットしてから、再度解放すると、認識できるようになる。
② LiveCDで起動させ、"dmraid -rE"で『スーパーブロック』にあるRAID情報を削除しないとインストラーで認識しないとのこと。
(日経Linux2010年5月号10ページ)
さて、どうでしょうか。当たっていなかったらごめんなさい。
オフライン
liveCDから起動して以下を試してみました。
前回デバイスを認識しなかったことから再現性は低いと思います。
>sudo dmraid -s
no raid disks
>sudo fdisk -l
ディスク /dev/sda: 1000.2 GB, 1000204886016 バイト
ヘッド 255, セクタ 63, シリンダ 121601
Units = シリンダ数 of 16065 * 512 = 8225280 バイト
Disk identifier: 0xa1e2a1e2
デバイス ブート 始点 終点 ブロック Id システム
/dev/sda1 * 1 120858 970791853+ 83 Linux
/dev/sda2 120859 121601 5968147+ 5 拡張領域
/dev/sda5 120859 121601 5968116 82 Linux スワップ / Solaris
ディスク /dev/sdb: 1000.2 GB, 1000204886016 バイト
ヘッド 255, セクタ 63, シリンダ 121601
Units = シリンダ数 of 16065 * 512 = 8225280 バイト
Disk identifier: 0x00063bdd
デバイス ブート 始点 終点 ブロック Id システム
/dev/sdb1 * 1 121601 976760001 8e Linux LVM
>sudo badblocks -vs /dev/sda
全セクタが表示されつづけたので途中でストップしました。
一度HDDのパーティションテーブルなどを読みにいくと認識しなくなるようです。
試せそうな事は夜通し試してみようと思いますが
>ファイルシステムを作ろうとする場所の近辺にデータがないか探して、余計なことに見つけるとそれを有効な物として初期化を強行しない節があります。
とあるようにたまたま前回のファイルシステムが見つかった時は捏造し、見つからなかったら認識しないといった動作をしているように見えます。
>ファイルシステムを構築することを躊躇するような動作が原因である場合、パーティションテーブルを弄っても何の効果もありません。
なので色々試してダメでしたら、MBRのマスターブートロダーをGRUBが上書いていることが原因であると思いますのでMBRの再構築を実施したいと思います。
オフライン
そこで提案(確認)ですが、ubuntu9.04のLiveCDでは認識できますか。9.10のインストラーが認識できなくとも、9.04のインストラーが認識できれば、そこから9.10にアップグレードできますが。
オフライン
その発想はなかったですね
9.04のインストラーで認識するかどうかも合わせて試してみます。
オフライン
もうひとつ
badblocks -vsを直接使用することはあまり奨励されていないようです。
(http://www.linux.or.jp/JM/html/e2fsprog … cks.8.html)
e2fsckやmke2fs を使ってくださいのことです。
(http://www.linux.or.jp/JM/html/e2fsprog … sck.8.html)
(http://www.linux.or.jp/JM/html/e2fsprog … 2fs.8.html)
オフライン
※規約違反により追放されたユーザの投稿は、ログインユーザにのみ表示されます。
オフライン
昨日、いろいろ試してやっと復旧できました
最終的には下記の要領で復旧させました。
①ホームにMBRのバックアップを作成
>sudo dd if=/dev/hda of=mbr.img bs=512 count=1
>sudo dd if=/dev/hdb of=mbrb.img bs=512 count=1
※作業前に一応USBに作成したmbrとmbrbを退避
②MBRのzerofill
$ sudo dd if=/dev/zero of=/dev/sda bs=512 count=1
$ sudo dd if=/dev/zero of=/dev/sdb bs=512 count=1
③再インストール
④再インストール後に
>sudo fdisk -l
でデバイス情報が表示されている事を確認
Crushさんのおっしゃるとおり、どうもインストーラが残骸を見つけては「大きなお世話」で初期化を強行していないようでした。
残骸をzerofillしてから、再度ubuntuをインストールしてしまえば無事に再構築され問題なく動作しているように見えます(今のところはですが。。。)
>皆様
たくさんのアドバイスありがとうございました。
皆様のおかげで無事復旧できました、今回の件では多くのことを学びましたがやはり自分はまだまだ知識が足りないなといったことを痛感致しました。
今後もフォーラムなどを拝見してubuntuについて学んでいくつもりです。
オフライン