実際に遭遇したトラブルを解決した際の記録:

#Knoppixを有効活用する

discドライブ、今ではUSBやネットワークさえあれば、 「起動しなくなった」システムを起動し、いじることが出来る便利ツール。 「インストールすること無く使える手軽なLinux」以上に便利なレスキューツールとして活躍する。

How to get

日本語版なら独立行政法人産業技術総合研究所から各種バージョンが入手可能。

How to boot

CD / DVDの場合、ディスクを挿入後計算機を起動、ディスクからブートする様に設定する。 設定はBIOS、ハードウェアに依存する。 ほとんどの場合BIOSが起動する数秒の間に「F11: Boot utility」といった表記で知らせてくれるので、それに従う。 その後は自動的にXまで立ち上がる。途中で以下の様なオプションを指定することが可能:

起動オプション説 明
knoppix lang=us言語、キーボードを設定。cn,de,da,es,fr,it,nl,pl,ru,sk,tr,tw,us
knoppix desktop=twmデスクトップマネージャを指定。fluxbox,icewm,kde,larswm,twm,wmaker,xfce
knoppix screen=1280x1024X Window Systemで使用する画面解像度を指定
knoppix xvrefresh=60X Window System使用時の垂直同期を60Hzに指定
knoppix xhrefresh=80X Window System使用時の水平同期を80Hzに指定
knoppix 3ランレベルに3を指定
knoppix floppyconfig保存した環境をフロッピディスクから読み込んでKNOPPIXを起動
knoppix myconf=/dev/sda1保存した環境を指定したデバイスから読み込んでKNOPPIXを起動 例)環境を保存したデバイスが/dev/sda1の場合
knoppix myconf=scan自動的に保存された環境設定を探し読み込んで起動
knoppix home=/dev/sda1ホームディレクトリを指定したデバイスから読み込む。例)ホームディレクトリを保存したデバイスが/dev/sda1の場合
knoppix home=scan自動的に保存されたホームディレクトリを探し読み込んで起動
knoppix noscsiSCSIドライバを組み込まないで起動
knoppix nopcmciaPCMCIAドライバを組み込まないで起動
knoppix nousbUSBドライバを組み込まないで起動
knoppix noswapスワップファイルを使用しないで起動
knoppix nofirewirefirewireドライバを組み込まないで起動
knoppix noagpAGPドライバを組み込まないで起動
failsafeハードウェアの自動検索をほとんどキャンセル
expert一段階ずつ確認しながら起動
knoppix26 OR linux26カーネル2.6を起動(標準はカーネル2.4)
knoppix bootfrom=/dev/hdxx/xxx.isoハードディスクにコピーしたCDイメージファイルで起動
knoppix xmodule=fbdevX Window Systemで正常に表示されない場合(フレームバッファでX起動)
fb1024x768X Window Systemで正常に表示されない場合(上記の解像度指定)
knoppix xmodule=vesaX Window Systemで正常に表示されない場合(VESA対応)

How to use

rootになる

パスワードは聞かれない:

su

sshdの起動

レスキューを行う際に、ネットワーク越しにデータのバックアップ・転送が出来れば大変便利である。 sshdを起動することで、ssh, sft, rsyncの使用が可能になる。

手動でsshdを起動する。その後passwordの設定をする:

su
/etc/init.d/ssh(d) start
passwd

プログラムの追加

CD / DVDの様に書き込み不可な環境で起動するが、一時的にデータの書き込みが可能である。 つまり、プログラムの追加が可能である:

apt-get update
apt-get install lvm2

knoppixをレスキューCDとして使う場合、必要なプログラムがデフォルトで組み込まれていない場合がある。 その場合でも、ネットワークにつながっていれさえすれば、このように新たなプログラムを追加することが可能である。

#参考にしたサイト

SELinuxが有効になっているパーティションが予期せぬ変更を受け、正常に立ち上がらなくなった。

問題

ディスクがクラッシュしfsck等で修復したパーティションが、正常に起動しなくなった。 ディスクは正常に動作しているようであるが、何らかの原因により正常にアクセスできなくなっていた。 その際「audit, avc, denied, mount, fstab, fsck」の様な単語を含むエラーが出る。

調べてみた結果、ディスクを修復したことにより、selinuxのlabelが書き換えられ、 それをselinuxが不正な操作と判断したことにより、起動できなくなっていたことが判明した。

解決法

labelの再作成

labelを再作成する。そもそも正常に起動しない為、先ず「single user mode」で起動する:

  1. grub boot画面が出た時点で、編集のために「e」とタイプ。
  2. 選択しているboot labelの設定ファイルの項目リストが表示される。
  3. kernelで始まる行を選択して、boot entryを編集するために、「e」とタイプ。
  4. kernelの行の最後に「single」と入力。
  5. エンターキーをタイプし、編集モードを抜けて、その後もう一度「b」をタイプしbootさせる。

read only modeでディスクがマウントされているので、

mount -a -o remount /

で/etc/fstabデフォルトの設定でremountする。

その後SELinuxのラベルを再作成する:

fixfiles relabel

OR

/sbin/fixfiles relabel

別解:そもそもSELinuxを使わない

そもそもSELinuxを使用しなければ、こんなことは起こらない。 セキュリティは大事だが、それにより研究の効率が著しく落ちてしまっては元も子もない*1

設定ファイル (/etc/selinux/config) を以下の様に書き換える:

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#       enforcing - SELinux security policy is enforced.
#       permissive - SELinux prints warnings instead of enforcing.
#       disabled - SELinux is fully disabled.
# SELINUX=enforcing
SELINUX=disabled
# SELINUXTYPE= type of policy in use. Possible values are:
#       targeted - Only targeted network daemons are protected.
#       strict - Full SELinux protection.
SELINUXTYPE=targeted

なお、有効にする場合は「SELINUX=enforcing」とする。

ファイル(ディスク)システムがおかしくなり、ファイルがディレクトリになっていたりする。

問題

落雷による停電により計算機ノードが不正に落ちてしまった。 その後正常に立ち上がらなくなってしまった(17分の1の確率・・・)。 エラーとしては

/usr/bin/rhgb-client: symbol lookup error ...

と言った感じ(共有ライブラリ関連のエラー)。 当初は「/usr/bin/rhgb-client」の問題*2かと思われたが、 よく調べてみると特にこのプルグラムに限ったことではない=問題があったプログラム、 ファイルがたまたま起動プロセスに関わるものだったにすぎないことが分かった。

結局原因は、予期せぬダウンによるファイルの異常であった。 例えば、あるプログラムに使用されるライブラリ

/usr/lib64/gconv/MIK.so

は本当はファイルであるが、これディレクトリに変わってしまっていた。 その結果プログラムがライブラリをロードできず、正常に起動しない。

今回は問題は、「/usr/bin/rhgb-client」に関係するライブラリ(の幾つか)がディレクトリ変化してしまった為、 起動プロセスが正常にすすまなくなってしまったのが原因である。

解決法

0 fsckによるファイルの修復・チェック

knoppixで起動する。対象のパーティションがLVMであったため、追加のパッケージをインストール:

su
modprobe dm-mod
apt-get update
apt-get install lvm2

正常に認識されているか確認:

  • volume groupをactivateする:
    lvm vgchange -ay
  • logical volumeの確認:
    lvm lvscan
  • volume groupの確認:
    lvm vgscan
  • report information about logical volumes:
    lvm lvs

fsckを実行:

fsck -(p)vf -t ext3 /dev/VolGroup00/LogVol00

「-t」オプションであらかじめ調べておいたファイルタイプを指定。

1 不良セクタのチェック

不良セクタもチェックしておく:

badblocks -s -o /root/target_partition_bad_blocks.txt /dev/VolGroup00/LogVol02

もし不良セクタが見つかったならば、不良セクタを登録しておく:

fsck -l /root/target_partition_bad_blocks.txt /dev/VolGroup00/LogVol02

(今回のトラブルでは、不良セクタは見つからなかった)

2 欠損ファイルのチェック

fsckで異常が見つかり、修復を試みた結果「lost+found」が作成されたかを調べる。 先ず始めにread-onlyでmountする:

mkdir -p /mnt/target_root
mkdir -p /mnt/target_root/usr
mkdir -p /mnt/target_root/local
mount -t ext3 -r /dev/VolGroup00/LogVol00 /mnt/target_root
mount -t ext3 -r /dev/VolGroup00/LogVol02 /mnt/target_root/usr
mount -t ext3 -r /dev/VolGroup00/LogVol05 /mnt/target_root/local

今回は「/usr/lost+found」に多くのファイルが見つかった。こんな感じ:

lrwxrwxrwx  1 chinoney cmb      16 Aug 21 22:28 #1541497 -> libwrap.so.0.7.6
lrwxrwxrwx  1 chinoney cmb      18 Aug 21 22:28 #1541499 -> libsasl2.so.2.0.22

つまり「/usr」パーティションに異常があったことになる。 ちなみに「/usr/bin/rhgb-client」は「/usr」以下のファイルであり、ライブラリもその内の1つが「/usr」以下で見つかる:

ldd /usr/bin/rhgb-client
	libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x00000037ad200000)
	libpopt.so.0 => /usr/lib64/libpopt.so.0 (0x00000037b6000000)
	libc.so.6 => /lib64/libc.so.6 (0x00000037a8a00000)
	librt.so.1 => /lib64/librt.so.1 (0x00000037ace00000)
	/lib64/ld-linux-x86-64.so.2 (0x00000037a8200000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00000037a9600000)

「/usr/bin/rhgb-client」だけが問題であれば「/usr/lib64/libpopt.so.0」だけを修復(どっかからかコピーする)すればいいが、 たまたまであって他のファイルがおかしくなっていないとは言えない。 なので、「lost+found」を覗きながら、どのファイルに異常が出たのかを調べる、、、。

3 欠損ファイルのコピー

面倒なので*3、 既に存在する「/usr」を削除し、正常な計算機から持ってきてコピーする。 スクリプトを自分で書いたり、「rsync」等を使うことで「欠損したファイルをコピーし、 おかしくなってしまったファイル(ディレクトリになってしまったり)は正常なファイルで上書きする」等で来そうだが、 少なくとも「rsync」をいろいろと弄ったが実現は出来なかった(-avz --update --size-only等々のオプションでは無理だった)。 一応データのバックアップをとっておく(修復前の方が良かったか?)。

以下「knoppix = 修復される計算機」、「node = 構成が同じ正常に動いている計算機」、 「backup = バックアップ先計算機」で作業を行う。

先ず始めにrsyncでバックアップをとる:

knoppix: rsync -avz -e ssh --progress /mnt/target_root/ backup:/path_to_backup_root/

次に書き込み可でmountし直す:

knoppix: cd
knoppix: umount /mnt/target_root/usr
knoppix: umount /mnt/target_root/local
knoppix: umount /mnt/target_root
knoppix: mount -t ext3 -o defaults /dev/VolGroup00/LogVol00 /mnt/target_root
knoppix: mount -t ext3 -o defaults /dev/VolGroup00/LogVol02 /mnt/target_root/usr

壊れている「/usr = /mnt/target_root/usr」を削除する:

knoppix: cd /mnt/target_root
knoppix: rm -rf ./usr/* ./lib/* ./lib64/*

(./libと./lib64はオマケ、、、「オマケ」で消してもいいのか?)

nodeから正常なファイルをコピーして来る:

node: su
node: rsync -avzu -e ssh --progress /usr/ root@knoppix:/mnt/target_dir/usr/
node: rsync -avzu -e ssh --progress /lib/ root@knoppix:/mnt/target_dir/lib/
node: rsync -avzu -e ssh --progress /lib64/ root@knoppix:/mnt/target_dir/lib64/

(「元」側の最後のスラッシュに注意。必ず「--dry-run」を付けて、一度は何が起こるかをテストする。) (knoppix上からでも出来るが、方向を認識しやすくする為に、敢てnode上で作業した。)

最後に行儀よくumount:

knoppix: cd
knoppix: umount /mnt/target_root/usr
knoppix: umount /mnt/target_root

4 起動

通常通り起動する。もしSElinuxが有効になっている場合は、一時的に無効にするかここを参考にしてrelabelを行う。 何故ならば、上での作業は「不正にディスクが操作された」と見なされるからである。

(今回は、この方法で修復できたようだ。)


*1 勿論、セキュリティを蔑ろにするという意味ではない。SELinuxを使わずにセキュリティが保たれているのが前提である。
*2 Red Hat系でよく見る、起動プロセスをGUIで表示するプログラム
*3 根拠はある。壊れた計算機はclusterのnodeに過ぎない。つまりhostname系の設定ファイル以外に個性は無い。