[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[debian-users:25326] Re: dpkg database broken? plz help...



 古澤です。

> 
> なるほど、euc-jp だったのですか。手元の spool の中でヘッダーを
> 書き換えてみたら読めるようになりました (なんだかわかんなかったから
> 読んでなかった)。
> 
> >   わざわざ読んでくださるとは…どうもありがとうございます。うーん、今まで
> > 誰も文句を言ってこないとは、私のような奴が多すぎるのでメーラがヘッダに書
> > いていることを素直に信じなくなっているのでしょうか…。
> 
> ふと思いついて http://lists.debian.or.jp/debian-users/200011/msg00307.html
> 見たら、こっちはちゃんと変換されてますね。
> 

 知人にもあいざま文字化けを指摘され恥をかきました。

  よく考えてみるとここしばらく同じ環境でメールを出していて、少し前の
debian-users への投稿も特に文字化けなどの不具合はなかったです。検証方法が
ないので断定は出来ないのですが、システムがきわめて異常な状態で出したメー
ルですので今回だけの失敗と思いたいです。まさか今まで全部文字化けメールを
出していたなんてことは。


# といったものの恥ずかしながら自分の設定は自分で完全に自信はもてていない
# のも事実です、mh とか自分で組み立てれば間違いないんですが。
# しばらく Mew に戻して今の環境についてゆっくり考えてみようと思います。
# 盲信はいけないのですが自分の扱うもののなかでは Mew が一番安心できるの
# で。



> >   2通目は debian-users までに一つクッションがあるのでそこで変換してくれ
> > ているようです。
> 
> これだけ読んでも状況がわからなかったです。
> 

 すこしづつ言葉足らずですみません。二通目はニュースグループから返信しま
した、長い間ニュースからの投稿はできなかったのですが最近になっていつのま
にか投稿できるようになっていることに気がついたのです(快適に使ってます)。

 くだんの文字化けメールも、自分が読んでいるニュース版 debian-users の方
では文字化けしないで読めていたため指摘されるまで気がつきませんでした。こ
のことから見てもニュースとメールの乗り入れ時に何かの変換がなされるようで
す。

 結局文字化けメールの原因は絞りきれないと思うのですが、とにもかくにも全
世界に文字化けメールを発信してしまったことは間違いありません、みなさまに
は大変ご迷惑をおかけいたしました。どうもすみませんでした。

> 
>  |  なく kernel-2.4.0test10 をインストールし、 いろいろ apt-get install し        
>  |  ていたところ、突如すべてのプログラムが Segmentation Fault を起こしはじ        
>  |   めたのであわてて再起動をかけました。ところが halt もコケてしまい目の前        
>  |  でカーネルがボロボロ崩れていくので、已むなく電源断して fsck をかけてか        
> 
> という時点で既にダメですね。
> 
> 「カーネルがボロボロ崩れていく」ようなシステムで fsck したらおそらく
> もう修復は不可能だと覚悟したほうが良いかと。
> 

 はい、駄目でした。

> もう手遅れですが、そういう場合はハードディスクを外して別のシステムに
> 接続して、とりあえず read only mount で救えるものだけ救うつもりで
> まず backup 取るとか。もしハードディスク自体は壊れていなくて (つまり
> ハードウェア的には問題無くて) 別パーティションにちゃんとしたシステムが
> あれば、そっちから起動して中身をバックアップする、でもいいですが。
> 
> というか、重要なシステムだったら、そもそもテスト版のカーネルをインストール
> するのは避けたほうがいいし、仮にテストするにしてもあらかじめバックアップを
> 取っておいたほうがいいような気がする。
> 

 まあ /home, /etc などは別ディスクにバックアップをとってあるのでそこは
助かりました。普通ならテスト版はいれない大人しい自分なんですけれど、
NVIDIA教徒に「悔しかったらテスト版カーネルをいれるんだね!」と煽られ
テスト版に尻込みする私にぼそりと「テスト10ならもう安定してるよ」と
駄目を押されてやってしまいました。

> で、バックアップした後、fsck かけるにしても、「壊れたシステム」から
> かけちゃダメでしょう。ちゃんと動くシステムでやらないと。必要なら
> そのために専用のシステム (partition) を新規インストールするとか。
> 
<略> 
> >   dpkg のデータベースは old を書き戻しただけでは足りないほど徹底的に壊れ
> > ていました。だいたい perse error がでるのです、例えば avaiable に
> > Version エントリがないっていわれる見てみると Veosion になっているとか、
> > Depends: がおかしいといわれて見ると改行が ^k(たぶん ^l の次のコード)にな
> > っているとか。不思議なことに壊れている部分はだいたい同じエントリなんです
> > よね、まあそんなこと分っても別に意味はないんです :-) 
> 
> こういう症状の時は、もう file system がダメですね。
> 

 別に簡単に投稿しますが、まさにファイルシステムのレベルで壊れていました。

> >   そうこうして十数個所を手で編集しなおし、動かしてみると今度は
> > /var/lib/dpkg/info/{*.list,*.prerm} あたりのファイルがまったく関係ないフ
> > ァイルの断片に変化している…。これらのファイルを元ファイルかろ気合いで作
> > 成し今度こそはと動かしたところ、やりました、ちゃんと動いているようです(
> > 午前3時)。さっそくカーネルを 2.2 に戻し再起動一安心しました。…ところが
> 
> ここで「カーネルを 2.2 に戻し」と書かれているということは、上記の
> 作業はすべてテスト版のカーネルを使って、壊れたシステムから起動した
> 状態で実行されていたわけですよね ?
> 

 そうです。

> 「順調に動作しているシステムが、何らかの原因で急に power down して、
>   そのために再起動時に fsck を必要とするようになった状況」
> 
> と、上記のような
> 
> 「テスト版のカーネルを使っていたところ突如すべてのプログラムが
>   Segmentation Fault を起こしはじめ、あわてて再起動をかけると
>   halt もコケてしまい目の前でカーネルがボロボロ崩れていくので、
>  已むなく電源断してしまった状況」
> 
> ではその後の対応に必要とされる慎重さが全然違ってきます。
> 
> 後者のような状況で、そのままその「壊れたシステム」から起動しようと
> するのは、ほぼ間違い無く「引導を渡す」ような行為だと考えて良いでしょう。
> 

「壊れた」->「壊した」

> 
> インストーラを起動して、Alt F2 でコンソールを開いて、そこから
> 作業する、というのが一般的な「壊れたシステムを復旧するための
> 手順」だと思います。これには fsck などのコマンドが用意されて
> いますから。
> 
>  # だから "rescue" という名前が付けられている。

 誤解を招く表現でしたが、「CD-ROMのカーネル」の方はインストールメディア
から Alt F2 したものです。しかし既に何度か壊れたシステムで fsck して
しまっていたので無意味なことでした。

 トラブル時に勢いで暴れると、おかしくないものまで壊してしまう。



> 
> >   最初から再インストールにむかっていれば簡単だったんでしょうが、まあそれ
> > は考えないで昼からの授業に出れるように眠ることにします。
> 
> お疲れさまでした。
> 
> > 以上永年(?)つれそった Debian システムからの最後のメールでした。
> 
> 次にインストールする際は rescue システムも最初から別パーティションに
> 用意しておくことをお勧めします。

 そうですね、rescue から tar で固めようとしたらアーカイブ作成機能が
削られたバージョンでうまくなかったです。resucueシステムを用意する意義は
大きいと実感しました。

> 
> 私の場合、カーネルの Magic SysRQ Key も効かないような状態で
> 突然システムがダウンした時 (例えば先日の XFree86 4.0.1d と
>  chips driver + HiQV chip の組み合わせ、みたいな) には、
> 電源 OFF の後、必ず別パーティションにある rescue 用のシステム
> から起動して fsck してます。
> 

 佐野さんの「正しい」手続きと比べると随分無茶苦茶やってきたんだなーと思
い知らされます。DRI を試しているとXがキーボードも利かない状態にハングアッ
プし、リモートからX殺しても入力が戻ってこないケースが多発していたのですが、
再起動時にたまーに見つかるファイルの不整合を何気なく修正してしまっていま
した。実際 test10, XF86 4.0.1 の組み合わせは DRI 実行時のクラッシュ以外
はまったく問題なく動作して一週間ぐらい使えていたのですが、継続的に繰り返
された不注意がシステムを少しづつ駄目にしていたようです。悪いのはカーネル
ではない。

 いいベータテスターになるのも大変なんですね。

> 最近いろいろ物騒なので、システムが crack されたかどうかを検査する
> ことが必要な機会もあるかもしれません。そういう場合のためにも、
> 別パーティション (別のディスクが使えるならそのほうがいいかも) に
> 「普段は決してマウントしない、緊急時専用のシステム」を、ある程度
> 使えるレベルに整備したツール類と一緒に用意しておくのが安心でしょう。
> 

 どうもありがとうございます、たいへん勉強になります。

 今自分のシステムだからこそ気軽に無茶苦茶できますが、昔の (?)人はま
ったく失敗の許されない厳しい環境で育ち慎重さを身に付けたのでしょうか。も
うそろそろ「滅茶苦茶」は止めたいんですが、なかなか‥