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

[debian-users:17938] Re: apt-get failed!

佐野＠浜松です。

すみません。Semi-gnus で書いた <y5ak8pkfke3.fsf@xxxxxxxxxxxxxxxxxxxx> が

  | Content-Type: text/plain; charset=SHIFT_JIS
  | Content-Transfer-Encoding: base64

となってしまっていて、Web の ML archive で見ると意味不明な記号の列にしか
見えなかったので、Mew から再送します。
 (それにしても、なんでこのメールだけこうなったんだろう ? 調べなきゃ)

 > 佐野＠浜松です。田村さんこんばんは。
 > 
 > In article <000401bf03b5$bc573920$1a7cd9ca@tochi>
 >  "Ippei Tamura" <ippei1@xxxxxxxxxxxx> さん writes:
 > 
 > > あまりに楽しいので、ついつい毎日ヤッていました。
 > 
 > # 実は自分自身ではパッケージ開発の必要が無ければあんまり potato を
 > # 使おうという気にはならないので、main のシステムは slink のまま
 > # だったりします。/dev/hda1 のほぼ base 状態の slink な rescue と
 > # /dev/hda3 の開発用 potato システム、そして /dev/hda5 のメイン環境
 > # である slink+ なシステムの 3 つが 6GB の HDD 上で同居しています。
 > # フロッピー起動が困難な機械では、rescue 用のシステムを独立した
 > # パーティションに置いておくというのも危険に対処するひとつの方法です。
 > 
 > > 復活の暁には、debian と清く正しいお付き合いをするつもりです（本気）。
 > 
 > これに懲りずに開発版の debug に協力してもらえれば、きっと potato も
 > 予定どおり freeze できることでしょう。
 >  (ホントか ? ^^;; ちなみに現在の予定は 11/1 フリーズらしい) 
 > 
 > > それにしても、巷の解説文書には、
 > > apt-get update　-> apt-get upgrade は書いてあっても、
 > 
 > それを見た時点で man apt-get して使えそうなオプションを調べるように
 > 心がけましょう。開発版のユーザーならベータテスターとしての心得を持たねば。
 > 
 > # などと追いうちをかけるヒドイ奴 < _o_
 > 
 > > 今朝も早朝より格闘して、現時点で判明したのは次の通りです。
 > > 
 > > ・shell は、/bin/bash と /usr/bin/tcsh が存在しています。
 > 
 > お、そうすると回復できる可能性が高いですね。
 > 
 > > 　ひょっとすると (none) ~# と表示されるのは、bash が
 > > 起動しているのでしょうか？
 > 
 > たぶん "/" (root file system) が read only でマウントされた状態に
 > なっているのだと思います。
 > 
 > まあ現在は調べることも不自由でしょうから、以下はとりあえず読んでおいて
 > うまく回復できたらまたじっくり調べてください。
 > 
 >  Linux カーネルは起動手順の終りに "/" (root file system) を read only で
 > マウントして、/sbin/init を実行しようとします。
 > 
 >  /sbin/init は /etc/inittab を参照して、そこに書かれている指示に
 > 従って動作します。
 > 
 >  /etc/inittab には
 > 
 >    # Boot-time system configuration/initialization script.
 >    # This is run first except when booting in emergency (-b) mode.
 >    si::sysinit:/etc/init.d/rcS
 > 
 > という記載があります。つまり、「最初の仕事」として /etc/init.d/rcS を
 > 実行しようとするわけです。
 > 
 > ところが、ここで /etc/init.d/rcS の先頭を見ると
 > 
 >   #! /bin/sh
 >   #
 >   # rcS           Call all S??* scripts in /etc/rcS.d in
 >   #               numerical/alphabetical order.
 > 
 > となっていて、最初の行で /bin/sh によって実行される script だと
 > 宣言しています。現在の状態では /bin/sh がありませんから、
 > この script は実行できません。 "BANG!" 
 > 
 > この状態では "/" が read only でマウントされた状態のままで、
 > その他の file system は /proc も含めてまったくマウントされていない
 > だろうと思います。ここで一般ユーザーとしてログインしようとしても、
 >  /home 以下にあるはずのそのユーザーの HOME ディレクトリがまだシステムに
 > 接続されていませんから、ログインできないわけです。
 > 
 >  Ctrl+Alt+Del キーを押した時の動作は /etc/inittab に
 > 
 >    # What to do when CTRL-ALT-DEL is pressed.
 >    ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now
 > 
 > と規定されています。通常ならここで再起動の動作が始まるはずですが、
 > 「異常事態」なのでおそらく
 > 
 >    # Normally not reached, but fallthrough in case of emergency.
 >    z6:6:respawn:/sbin/sulogin
 > 
 > こちらに移行しているのでしょう。 /sbin/sulogin は single user mode で
 > 利用される root 専用のログインコマンドです。
 > 
 > とりあえずこれでログインして、まず cat /etc/mtab してみましょう。
 > 最初の行の最後が ro になっていませんか ?
 > 
 > それから e2fsck -p /dev/hda1; e2fsck -p /dev/hda2; e2fsck -p /dev/hda3 を
 > 実行してみましょう。いくつかエラーメッセージが出ても、最後にちゃんと
 >  "Filesystem modified" となって終了して、その後 e2fsck を実行した時に
 >  "clean" と出るようなら OK です。
 > 
 > 次に手動で / をマウントします。この場合は mount /dev/hda1 /; ですね。
 > そして cd /bin; で /bin に移動し、ls -l *sh してください。
 > 
 > ここでもし sh が存在しなければ、 ln -s bash sh; を実行します。
 > 
 > それが終ったら、cd /; mount / -oremount,ro; を実行して、もし
 > エラーが出てもそのまま exit してください。その後通常の起動手順が
 > 始まるかもしれません。もし何も動かないようでしたら、その状態から
 >  ctl + alt + del で再起動させます。ここでもしまた sulogin の
 > プロンプトが出るようなら、またログインして telinit 2 を実行してみて
 > ください。

後で思ったんですが、 exit や telinit 2 の前に /etc/init.d/rcS; を
実行したほうがいいかもしれません。あるいは ln -s bash sh の実行後、
そのまま sync;sync;sync; shutdown -r now; で再起動させてしまったほうが
楽かも。

このへんは現物を見てその場で考えて行動することが多いので、
「確実な手順」というのはあまり思いつかないです。たいてい
なんかやっているうちに復活してくれるので。

 > > 　たしかに dpkg --configure --pending を実行しようとしても、
 > > 　/var 以下の hogehoge というファイルが無いと怒られてしまいます。
 > 
 >  dpkg を使えるようにするのは、/bin/sh が使えるようになってからです。
 > システムの回復には守るべき順番があります。途中を飛ばしていきなり
 > 先を急ぐと傷を深くする場合があります。
 > 
 > > 先述の df の結果を見る限り、怪しいような気がします。
 > > 
 > > 状況報告以上の通りですが、このダークサイドから逃れる術はあるでしょうか？
 > > 皆様からフォースのご加護があらんことを・・・・・・
 > 
 > たぶん、最初に /bin/sh が消えた時にリセットしてしまったことが
 > 敗因でしょうね。動作している状態なら cd /bin; ln -s bash sh; の
 > コマンド 2 つだけでおそらく回復できたものと思います。
 > 
 > Linux を含めた Unix 系システムでは root で rm -rf / を実行しても
 > 動作中のカーネルやデーモンは動作を続ける、ということを実験で確認
 > したレポートがたしか "http://www.sra.co.jp/people/katsu/"; (?) の
 > ページだったかな、どこかにあったはずです。「調子がおかしい」と
 > いうことに気がついた時点でまずやるべきことは原因の調査と対処です。
 > 原因を把握する前にシステムをリセットしてしまうとかえって対応を
 > 困難にします。
 > 
 > P.S.
 > 
 > なんで (none) login: を見て「 "/" が read only になっている」と
 > 連想したかというと、XFree86 のベータテストでサーバーがクラッシュ
 > した時に何度も見たことがあるから。「/bin/sh が無い」という状況は
 > あんまり経験がありませんが (先日が初めて) システムクラッシュ後の
 > 再起動時に fsck で失敗すると、よくそういう状態になります。
 > 
 > では、ご健闘を祈ります。 Good Luck!

読めないメールでごめんなさいでした (> all)

 > -- 
 >      ＃わたしのおうちは浜松市、「夜のお菓子」で有名さ。
 >     <xlj06203@xxxxxxxxxxx> : Taketoshi Sano (佐野　武俊)