トップページ » 3.1.Linux/UNIX » 第５章 サーバー移設時のトラブルシューティング
3.1.Linux/UNIX
第５章 サーバー移設時のトラブルシューティング
本章は前章「Fedora Core2サーバーの移設」の続きとなる。 私が過去にサーバー移設作業を行った中で発生したトラブルについて書いておこうと思う。
Fedora Core 2に限った事ではなく、私が過去に使用してきた、又は現在使用中であるRedhat系のOS（Redhat 7,8,9,ES等)にも関係する話になる。
あくまで私が過去に経験した事だけなので、トラブルシューティングと言うには内容が薄いものかもしれないが、自分の防備録としても残しておきたい。
MBRの破損
ハードディスク移設後に起こりえる問題の一つ目はマスターブートレコード（以下MBR）の破損だ。 恐らくGhostでクローニングしている限り起こることはまずないと思うが念のため簡単に紹介しておく。 まずクローニングが問題なく終了していることと、移設したＰＣの全ての配線が間違いないことを確認しておく。 この状態でGRUBすら起動しない場合はMBRの破損の可能性があるかもしれない。
MBRとはＰＣがハードディスクを読み込む際、真っ先に読む場所だ。 この部分が破損していると当然の事ながら起動できない。
この場合の対処法としては、旧環境、つまりクローニング元ハードディスクのMBRを再度コピーする。 まず旧環境にクローニング元のハードディスクを戻して、通常通り起動するか再確認してみよう。 起動するようならMBRのコピー作業を行う。
まずは旧環境のシェルを立ち上げてMBRを吸い出そう。 今回は例としてフロッピーディスクに吸い出すことにする。 旧環境にフォーマット済みのフロッピーディスクをセットして
su -
mount /mnt/floppy
dd if=/dev/hda of=/mnt/floppy/mbrbackup bs=512 count=1
umount /mnt/floppy
これでフロッピーディスクにmbrbackupというファイル名でMBRが吸い出される。
続いてこのフロッピーディスク中のMBRを新環境に持って行く必要があるのだが、新環境はそれ自体では起動しない状態にあるので、別の方法で起動しなければならない。
通常、Fedora Core 2をインストールしたときに作成することを推奨される起動ディスクを使用したりするのだが、私の場合別のページでも書いたとおり、この手の作業をする場合はKNOPPIXを使用する。 ここでもKNOPPIXでの作業を前提として説明する。
まずは新環境のCDドライブにKNOPPIXを挿入してリブート。 起動したら先ほど作成したフロッピーをセットし、シェルを起動後次のようにタイプする。 ちなみにここではコピー先のハードディスクがプライマリのマスター(/dev/hda)にセットされている場合を仮定している。
su -
mount /mnt/floppy
dd if=/mnt/floppy/mbrbackup of=/dev/hda bs=446 count=1
umount /mnt/floppy
最初にルートになっているが、KNOPPIXの場合ルートになるためのパスワードは無しとなっている。
これで旧環境のMBRが新環境にコピーされたはずだ。 新環境からCD及びフロッピーディスクを抜いた上でリブートし動作チェックしてみよう。
GRUBの破損
Fedora Core 2の場合、標準のブートローダーはGRUBとなるが、このGRUBが破損して起動しないケースもある。 特にGhostのバージョンによってはクローニング後GRUBが破損する事がある。 この現象は私も過去に経験した。 詳細はシマンテックサイト中のDocument ID:2000042113083825、Cannot start Linux with GRUB boot loader after restoring an image of a disk or partitionをご覧頂きたい。
この際の症状は、通常起動時に「GRUB」と表示されるはずの部分が「G」だけしか表示されずにそのまま停止状態に陥る。 この様な状態に陥った場合、GRUBの再構築が必要となる。
まずはGRUBの起動ディスクから作成しよう。 以下にFedora Core 2で行う例を示す。 旧環境のシェルを起動し、空のフロッピーディスクをセットした上で
cd /boot/grub
cat stage1 stage2 | dd of=/dev/fd0
これでGRUB起動ディスクは作成されるだろう。
続いてGRUB再構築の準備を行う。 旧環境の/etc/grub.confを表示してみよう。 以下はFedora Core 2で見たgrub.confの例だ。
# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE: You have a /boot partition. This means that
# all kernel and initrd paths are relative to /boot/, eg.
# root (hd0,0)
# kernel /vmlinuz-version ro root=/dev/hda2
# initrd /initrd-version.img
#boot=/dev/hda
default=0
timeout=10
splashimage=(hd0,0)/grub/splash.xpm.gz
title Fedora Core (2.6.6-1.435.2.3)
root (hd0,0)
kernel /vmlinuz-2.6.6-1.435.2.3 ro root=LABEL=/ rhgb quiet
initrd /initrd-2.6.6-1.435.2.3.img
title Fedora Core (2.6.6-1.435.2.1)
root (hd0,0)
kernel /vmlinuz-2.6.6-1.435.2.1 ro root=LABEL=/ rhgb quiet
initrd /initrd-2.6.6-1.435.2.1.img
title Fedora Core (2.6.6-1.435)
root (hd0,0)
kernel /vmlinuz-2.6.6-1.435 ro root=LABEL=/ rhgb quiet
initrd /initrd-2.6.6-1.435.img
title Fedora Core (2.6.5-1.358)
root (hd0,0)
kernel /vmlinuz-2.6.5-1.358 ro root=LABEL=/ rhgb quiet
initrd /initrd-2.6.5-1.358.img
この中のカーネルの１ブロックをメモしておこう。 例えば上の例では
title Fedora Core (2.6.6-1.435.2.3)
root (hd0,0)
kernel /vmlinuz-2.6.6-1.435.2.3 ro root=LABEL=/ rhgb quiet
initrd /initrd-2.6.6-1.435.2.3.img
の部分等だ。
メモを取り終わったら先ほど作成したGRUBの起動ディスクを新環境にセットし、フロッピーディスクから起動して欲しい。 暫くするとGRUBのプロンプトが表示されるはずだ。 それに対し先ほどメモした内容を入力していく。 そして最後にbootと入力して欲しい。
root (hd0,0)
kernel /vmlinuz-2.6.6-1.435.2.3 ro root=LABEL=/ rhgb quiet
initrd /initrd-2.6.6-1.435.2.3.img
boot
これでrootシェルが起動するはずなので、続けて以下の通り入力して欲しい。
/usr/sbin/grub-install /dev/hda
このコマンドを実行するとGRUBが再インストールされるはずだ。 後は新環境をリブートして正常に起動するか確認してみよう。
CPUアーキテクチャの違い
移設の際に気を付けなければならない事として、移設元と移設先のCPU種別がある。 例えば移設元がPentiumで移設先がAthlonだとするとクローニングしただけでは間違いなく起動しない。 これはCPUのアーキテクチャが違うため、旧環境のKernelがインストールされたままの状態では至極当然の事となる。
これが例えばPentium2からPentium3又は4へのアップグレードであれば、問題なく移設できるだろう。 これはPentium3/4はPentium2等過去のCPUとの互換性を保っているからだ。
しかしこれがダウングレードとなると話は一転する。
私が過去に経験した例を挙げると、VIA C3とPentium3の移設作業でのトラブルというのがある。 これはSUMICOM導入当初の話になるのだが、サーバー用途という事もあり、当初省電力、低発熱のVIA C3 800MHzを装着してRedhat8を新規にインストールした。
しかしある程度時間がたつにつれ、様々なソフトウェアをインストールしたこともあり、もう少しCPUパワーが欲しくなってきた。 そこでPentium3 1Gに換装することにしたのだ。 SUMICOMはSocket370で、VIA C3とPentium3の両方をサポートしていた。 アーキテクチャで言うとVIA C3はi586でPentium3はi686となる。 当然換装する時点ではi586のKernelがインストールされていた。
Pentium3はC3からみると上位互換のCPUに当たるため問題なく起動した。 動作スピードも早くなり、それからしばらくの間は快適に使用していた。 （この時点でもi586だ）
しかし季節は巡り、やがて夏にさしかかる頃である。 気温が高くなりつつある中、徐々にCPUの発熱が気になるようになってきた。 ２４時間休むことなく稼働させているサーバーだ、やはり発熱は気になる。 私は夏場の間だけC3に戻すことにした。
ところがCPUを換装した直後からRedhatが起動しなくなったのである。 何故だろうと原因を追及していくと、その答えはRedhat Networkにあった。 Redhatではバージョン7.2当たりからup2dateによるソフトウェアの自動（又は半自動）アップデート機能が装備されるようになった。 それまではアップデート作業は手動で行う必要があったので、私はこれは便利とばかりにすぐに飛びついた。
実はこれが裏目に出たのだ。 Kernelのアップデートがリリースされたときに、up2dateが自動的にCPUを識別しi686に切り換えた上でアップグレードしてくれていたのである。 この動作は通常であれば正解で喜ばしいことなのだが、今回に限っては大きなお世話的な事になってしまった。
この時の対処方はもうあまり記憶に残っていないのだが、確か一旦Pentium3に戻し普通に起動させた後、現在インストールされているKernelと同じバージョンのi586.rpmを強引に上書きインストールした上でC3に換装した覚えがある。 この時はこれで事なきを得た。
しかしこんな単純な方法ではうまくいかないケースもあるのだろうと思う。 例えば私が今回Fedora Core 2をインストールしたIQ3601ではCPU自体がオンボードとなっているため、上のような逃げの手法はとれない。 やるとしたらRPMデータベースは無視してKernelをソースからコンパイルする等の方法になるのではないだろうか。
移設作業は慎重に
今回ご紹介した移設時のトラブル事例はほんのごく一部にしか過ぎないだろう。 実際に作業をし始めると、その時々でまったく予想のつかない自体に追い込まれたりするものである。
今回２回にわたって移設に関する記事を書いてきたが、これらの記事を読んで移設をしようと考えられた方がいるとしたら、こういうトラブルにあわない様、移設前は色々と検証してからのぞむことをお願いしたい。
慎重に慎重を期す。 これは作業の効率は悪くなるが、そこは自宅サーバーなのである。 決して早く作業する必要性もないのだ。 壊してしまったのでは元も子もない。
実行される方は是非じっくりと腰を据えて作業して頂きたい。
投稿日 : July 29, 2004
この記事に関する言及
このエントリーのトラックバックURL:
http://akionweb.com/mt-tb.cgi/61
コメント
私もIQ3601を購入したので、このページを参考にさせていただきました。
(ノート＋外付けHDDで自宅サーバを運用してきたんですが、この夏でＨＤＤを２台壊してしまったんで...)
ところで、Fedora Core2を最初からインストールしてみたのですが、どうも再起動をかけるとシャットダウン後に再起動がかからずハングしてしまいます。何かあった際にリモートで再起動できずに不便なのですが、AKIさんはこのような症状に遭いませんでしたか？
投稿者 あすろ : September 26, 2004 11:15 AM
あすろさんこんにちは。
あれれ？ 私の場合はそのような現象は起こったことはありませんよ。
私もローカルは勿論、sshでリモートからリブートすることも多々あるのですが、一度も復帰できないケースはありませんでした。
Fedora Core 2という事ですので、ほぼ同じ環境のはずですが・・・ 違う点として考えられるのはメモリ、ハードディスクといったところでしょうかね。
参考にならないと思いますが・・・すいません。
投稿者 AKI ON WEB : September 26, 2004 11:26 AM
このページに対する感想、意見をお寄せ下さい。
おことわり
当サイトに掲載している全ての情報は、全て当サイト管理者が個人的、実験的に試した事、又は独自に調査したものです。 従ってその情報に誤りがある可能性も多分にあります。 当サイトの情報をそのまま鵜呑みにされませんようお願い申し上げます。 また当サイトの情報を元に作業されたりする場合はそれをご理解頂いた上で、あくまで自己責任の元で行ってください。
トップページ » 3.1.Linux/UNIX » 第５章 サーバー移設時のトラブルシューティング
