前のページ 次のページ 目次

7. いくつかの落とし穴

7.1 make clean

通常のアップグレードの後,新しく構築したカーネルが奇妙な動作をするときは,新 しいカーネルをコンパイルをする前にmake cleanし忘れた可能性がありま す。症状はいろいろで,システムが完全にクラッシュしてしまったり,I/Oが変だっ たり,あるいは速度が遅かったりするかもしれません。make depも忘れず にしてください。

7.2 巨大あるいは遅いカーネル

カーネルが多量のメモリを使いこんだり,あまりに巨大だったり,あるいはせっかく 新しい786DX6/440を投入してやったというのにコンパイルがいつまでたっても終わら ないという場合は,いらないものまでカーネルに組みこんでしまっているかもしれま せん(デバイスやファイルシステムなどです)。いらないものは組みこまない,メモ リを浪費することになるからです。カーネルが巨大化して,もっとも目立つ症状は, 頻繁にメモリとディスクの間でスワップが起こるというものです。ディスクがあんま りうるさい場合で,かつハードディスクに停止する際にジェット機の着陸時のような 音のする古い富士通のEaglesを使用していない場合は,カーネルの設定を調べてみま しょう。

カーネルがどれくらいメモリを消費してるかは,/proc/meminfoあるいは ‘free'コマンドの``total mem''からマシンに搭載しているメ モリ量を差し引くことでわかります。‘dmesg'を実行する(あるいはカー ネルのログファイルを見る)ことでもわかります。このような行があるはずです:

Memory: 15124k/16384k available (552k kernel code, 384k reserved, 324k data)

私の386(若干ジャンクを組み合わせたようなものですが)ではこう表示されます:

Memory: 7000k/8192k available (496k kernel code, 384k reserved, 312k data)

7.3 カーネルをコンパイルできない

コンパイルできない場合,パッチ当てに失敗していたり,カーネルソースがどこか壊 れているのかもしれません。gccのバージョンが違っていたり,gccそのものが壊れて いるのかもしれません(例えばインクルードファイルがおかしいなど)。Linusが READMEで説明しているシンボリックリンクが,正しく設定されているか確 認して下さい。通常,標準のカーネルをコンパイルできない場合,特定のツールを再 インストールする必要があるかもしれません。

あういは,たぶんあなたは1.2.xのカーネルをELFのコンパイラ(gcc 2.6.3および それ以降)でコンパイルしようとしているのかもしれません。コンパイルの最中に so-and-so undefinedというメッセージが大量に出て来たら,これがきっ と原因なんでしょう。ほとんどの場合対処法は極めて簡単です。 arch/i386/Makefileの先頭に以下の行を追加してください:

AS=/usr/i486-linuxaout/bin/as
LD=/usr/i486-linuxaout/bin/ld -m i386linux
CC=gcc -b i486-linuxaout -D__KERNEL__ -I$(TOPDIR)/include
それからもう一度make depmake zImageを実行してください。

極めて,極めてまれなことですが,ハードウェアの問題でgccがクラッシュすること があります。エラーメッセージは``xxx exited with signal 15''というような感じ になり,一般に大変ミステリアスに見えます。このことについては言及しませんが, 一度わたしも遭遇したことがあります - 原因は不良のキャッシュメモリで,コンパ イラがランダムに酔っ払い状態になることがありました。問題に遭遇したら,まず gccを再インストールしてみてください。外部キャッシュをオフにしたり,RAM容量 を減らしてみたらカーネルコンパイルがうまく行く場合は,この辺を疑ってみるべ きでしょう。

7.4 新しいバージョンのカーネルでブートしていないようだ

LILOを実行していなかったり,LILOの設定が正しくありません。以前私が遭遇したの は設定ファイルの問題でした。`boot = /dev/hda'ではなく `boot = /dev/hda1'と書いていました(これは本当に紛らわしいですが, 一旦動作する設定ファイルを作ったら後は変更する必要はありません)。

7.5 LILOを実行し忘れた,あるいはまったくブートできない

ええっ!ここでの最善の策はフロッピーディスクから起動し,別のブート可能なフロ ッピーを作ることです(`make zdisk'などとします)。どこにルート (/)のファイルシステムがあるか,またそのファイルシステムの種類 (ext2やminixなど)を知っている必要があります。以下の例では /usr/src/linuxというソースツリーが,どのファイルシステムに存在す るか,その種類,また通常はどこのマウントされているかも知っていなければなり ません。

以下の例では,//dev/hda1にあり,また /usr/src/linuxが存在するファイルシステムは/dev/hda3で 通常は/usrにマウントされています。どちらもext2ファイルシステム です。/usr/src/linux/arch/i386/bootに存在する,動作するカーネル イメージはzImageと呼ばれます。

もしちゃんと動作するzImageが存在するなら,それを新しいフロッピー で使用できる,というのがこの復旧法の考え方です。これよりうまくいくかどう かは定かではありませんが(これはどのようにしてシステムを破壊したかにより ます),別の方法については例の後に説明します。

まず,boot/rootディスクの組み合せか復旧ディスクから起動し,動作するカーネル を持つファイルシステムをマウントします:

      mkdir /mnt
      mount -t ext2 /dev/hda3 /mnt

mkdirしたときにディレクトリはすでに存在するといわれても,無視して ください。続いて動作するカーネルイメージが存在するディレクトリへcd します。以下のことに注意してください:

/mnt + /usr/src/linux/arch/i386/boot - /usr = /mnt/src/linux/arch/i386/boot
フォーマットしたディスクをドライブ``A:''に入れ(断じてbootやrootあるいは復旧 ディスクではありませんよ!),カーネルイメージをフロッピーへダンプし,フロッ ピーがルートファイルシステムになるよう設定します:

      cd /mnt/src/linux/arch/i386/boot
      dd if=zImage of=/dev/fd0
      rdev /dev/fd0 /dev/hda1

/cdし通常は/usrであるファイルシステムをアンマ ウントします:

      cd /
      umount /mnt

これで,作成したフロッピーから通常通りシステムをリブートできるはずです。リブ ート後,liloを実行すること(あるいは失敗の原因の除去)を忘れずに行ってくださ い!

上述の通り,もう一つ一般的な対処法があります。動作するカーネルが偶然/ に存在した場合(例えば/vmlinuz),それをブートディスクに使用するこ とができます。先に述べた条件をすべて満たしていて,かつカーネルイメージが /vmlinuzである場合,上の例をすべてこれにあうように変更するだけです: /dev/hda3/dev/hda1へ(/ファイルシステムです), /mnt/src/linux/mntへ,そしてif=zImageif=vmlinuzへ変更します。どうして/mnt/src/linuxになるか, という注意に関してはこの場合関係ありません。

LILOを大きなドライブ(1024以上のシリンダを持つもの)で使用すると,問題が 生じることがあります。LILO mini-HOWTOなどに,この問題に関する情報がありま すので参照してください。

7.6 `warning: bdflush not running'という警告が出る

これは深刻な問題であるかもしれません。リリース1.0以降のカーネル(94年の4月 20日前後)から,ファイルシステムのバッファを定期的に消去する`update' というプログラムが修正/取り替えられました。`bdflush'のソースを入手 し(カーネルソースを取ってきたところで見つかるはずです),インストールします (恐らくインストールは古いカーネルの下で実行したほうがよいでしょう)。インス トールの際に自動的に`update'としてインストールされ,リブートの後新 しいカーネルはもう不平をいわなくなるはずです。

7.7 未定義のシンボルがあるとメッセージが出て,コンパイルできない

おそらくELFコンパイラ(gcc 2.6.3およびそれ以降)と,1.2.x(あるいはそれ以前) のカーネルソースを使用しているのでしょう。通常の解決法は,以下の3行を arch/i386/Makefile:

AS=/usr/i486-linuxaout/bin/as
LD=/usr/i486-linuxaout/bin/ld -m i386linux
CC=gcc -b i486-linuxaout -D__KERNEL -I$(TOPDIR)/include

これで,1.2.xカーネルをa.outライブラリを使用してコンパイルできます。

7.8 IDE/ATAPI CD-ROMドライブが動作しない

どうも奇妙なことに,多くの人がATAPIドライブを使用できないと言っていますが, たぶん多くの問題点があるのでしょう。

もしCD-ROMだけがあるIDEインターフェースに装着されているのなら,それは ``master''あるいは``single''の位置にジャンパを付けなければなりません。 おそらく,これがもっともありがちな間違いでしょう。

Creative Labsは現在,IDEインターフェースを彼らのサウンドカードに取り付けて います。しかしこのことが面白い問題を引き起こします。中にはIDEインターフェー スが1個しかないという人もいますけど,多くの人の場合はマザーボード上に2つの IDEインターフェースが内蔵されていることでしょう(通常はIRQ15です)。だから, 一般的な方法はサウンドブラスタのインターフェースを3番目のIDEポートにするこ とです(IRQ11です)。

これは,3番目のIDEインターフェースをサポートしないバージョン1.2.xのlinuxで 問題となります(1.3.xシリーズのどこかからサポートが開始されましたが,それ は開発版のカーネルであり,さらに自動検出でないことを覚えておいてください)。 この問題に対処するには,いくつかの選択肢があります。

すでに2番目のIDEポートがあるなら,それを使わないことにするか,そのポートに 2つのデバイスを接続しないようにするかです。ATAPIドライブをサウンドカードか ら取り外し,2番目のインターフェースに接続します。それからサウンドカードの インターフェースを無効にします。これでなんとかIRQを節約できます。

2番目のインターフェースがないなら,サウンドカードのインターフェース(サウ ンドカードのサウンド部分ではありません)をIRQ15,すなわち2番目のインター フェースになるようジャンパで設定します。そうすれば動くはずです。

何らかの理由で,どうしてもいわゆる「3番目」のインターフェースでなければな らない場合,あるいは他の問題がある場合は,1.3.xのカーネル(例えば1.3.57は 3番目のインターフェースをサポートしています)を入手し, drivers/block/README.ideを読んでください。そこにはもっと多くの 情報があります。

7.9 廃れてしまったルート要求に対しておかしな警告が出る

[ここでいうルートはrootでなく(ネットワークの)routeのこと です。]

routeプログラムおよびルートをいじるその他すべてのプログラムの新しい バージョンを入手してください。/usr/include/linux/route.h(実際には /usr/src/linuxにあるファイルです)が変更されました。

7.10 1.2.0でファイアウォールが動作しない

少なくともバージョン1.2.1までアップデートしてください。

7.11 ``カーネルイメージファイルが圧縮されていない''

ブートイメージとして/usr/src/linuxにできるファイルvmlinux を使用してはいけません;[..]/arch/i386/boot/zImageを使用してください。

7.12 1.3.xにアップデートした後コンソール端末に問題が出る

/etc/termcapのコンソール(console)エントリにあるdumblinuxに変更してください。terminfoのエントリを作成する必要もある かもしれません。

7.13 カーネルアップグレードの後コンパイルできなくなったようだ

linuxのカーネルソースには/usr/includeにある標準のインクルードファ イルによって参照される多くのインクルードファイル(拡張子が.hのファ イル)が含まれています。これらのファイルは以下のように参照されます(ここで xyzzy.h/usr/include/linuxに存在するもののどれかです):

      #include <linux/xyzzy.h>
通常,/usr/includeからカーネルソースのinclude/linuxディレ クトリ(普通のシステムでは/usr/src/linux/include/linux)への linuxと呼ばれるリンクが張られています。このリンクが張られていない と,あるいはおかしなところへ張られていると,ほとんどのプログラムをコンパイ ルできなくなってしまいます。カーネルソースがあまりにディスクスペースを消費 するからとこれを消去してしまうと,このリンクが消滅してしまい明らかに問題で す。ファイルのパーミッション(ファイルへのアクセス許可)でもうまくいかない 原因になります;あなたのシステムのrootが,デフォルトで他のユーザー にインクルードファイルを見せないようにumaskを設定していたり,かつカーネルを 展開するときにpオプション(ファイルモードを変更しない)をつけない と,他のユーザーはやはりCコンパイラを使用できなくなります。chmodコ マンドでパーミッションを変更することもできますが,インクルードファイルを再 度展開するほうが楽でしょう。最初ソース全体を展開したときのコマンドに,引数 を追加するだけです。
      blah# tar zxvpf linux.x.y.z.tar.gz linux/include
注意;``make config''は/usr/src/linuxにリンクが存在しない と,リンクを張り直します。


前のページ 次のページ 目次