通常のアップグレードの後,新しく構築したカーネルが奇妙な動作をするときは,新
しいカーネルをコンパイルをする前にmake clean
し忘れた可能性がありま
す。症状はいろいろで,システムが完全にクラッシュしてしまったり,I/Oが変だっ
たり,あるいは速度が遅かったりするかもしれません。make dep
も忘れず
にしてください。
カーネルが多量のメモリを使いこんだり,あまりに巨大だったり,あるいはせっかく 新しい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)
コンパイルできない場合,パッチ当てに失敗していたり,カーネルソースがどこか壊
れているのかもしれません。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 dep
とmake zImage
を実行してください。
極めて,極めてまれなことですが,ハードウェアの問題でgccがクラッシュすること があります。エラーメッセージは``xxx exited with signal 15''というような感じ になり,一般に大変ミステリアスに見えます。このことについては言及しませんが, 一度わたしも遭遇したことがあります - 原因は不良のキャッシュメモリで,コンパ イラがランダムに酔っ払い状態になることがありました。問題に遭遇したら,まず gccを再インストールしてみてください。外部キャッシュをオフにしたり,RAM容量 を減らしてみたらカーネルコンパイルがうまく行く場合は,この辺を疑ってみるべ きでしょう。
LILOを実行していなかったり,LILOの設定が正しくありません。以前私が遭遇したの
は設定ファイルの問題でした。`boot = /dev/hda
'ではなく
`boot = /dev/hda1
'と書いていました(これは本当に紛らわしいですが,
一旦動作する設定ファイルを作ったら後は変更する必要はありません)。
ええっ!ここでの最善の策はフロッピーディスクから起動し,別のブート可能なフロ
ッピーを作ることです(`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=zImage
を
if=vmlinuz
へ変更します。どうして/mnt/src/linux
になるか,
という注意に関してはこの場合関係ありません。
LILOを大きなドライブ(1024以上のシリンダを持つもの)で使用すると,問題が 生じることがあります。LILO mini-HOWTOなどに,この問題に関する情報がありま すので参照してください。
これは深刻な問題であるかもしれません。リリース1.0以降のカーネル(94年の4月
20日前後)から,ファイルシステムのバッファを定期的に消去する`update
'
というプログラムが修正/取り替えられました。`bdflush
'のソースを入手
し(カーネルソースを取ってきたところで見つかるはずです),インストールします
(恐らくインストールは古いカーネルの下で実行したほうがよいでしょう)。インス
トールの際に自動的に`update
'としてインストールされ,リブートの後新
しいカーネルはもう不平をいわなくなるはずです。
おそらく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ライブラリを使用してコンパイルできます。
どうも奇妙なことに,多くの人が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
を読んでください。そこにはもっと多くの
情報があります。
[ここでいうルートはroot
でなく(ネットワークの)route
のこと
です。]
route
プログラムおよびルートをいじるその他すべてのプログラムの新しい
バージョンを入手してください。/usr/include/linux/route.h
(実際には
/usr/src/linux
にあるファイルです)が変更されました。
少なくともバージョン1.2.1までアップデートしてください。
ブートイメージとして/usr/src/linux
にできるファイルvmlinux
を使用してはいけません;[..]/arch/i386/boot/zImage
を使用してください。
/etc/termcap
のコンソール(console)エントリにあるdumb
を
linux
に変更してください。terminfoのエントリを作成する必要もある
かもしれません。
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
にリンクが存在しない
と,リンクを張り直します。