だけど、オレのPCってばいつの間にか128Mものメモリを積んでしまっているでわないくぁ。なんでかって〜と、オレってばFPMをいまだに使っているのだった。SDRAM？ちっちっち。バブリーだねあんた(笑) EDOですらないぜ、オレなんて(自慢してどうすんぢゃい)
会社のマシンがブチ壊れたり、ほんのちょっと古くなって重たい重たいNT鯖なんぞが軽やかに動かなくなると、ディスクやらなんやらの再利用できるパーツだけをかっぱがれて、あわれ捨てられちゃったりするでしょ？
そういう時に、FPMなメモリなんてあんまり引き取り手がいなくて、いつのまにかオレのマシンにズンズン積まれて増殖してしまったのだった(笑)
こうなるともはや、kernelでmoduleを使う意味ってのが極めて薄くなるよね。なにしろ、自分のマシンでmakeしたkernelは、そのマシンでしか使わない。moduleに分割して、実行時の使用メモリ量を削ったり、ハードの違いを吸収するといったような、moduleのメリットが、ほとんど意味をなさないではないか。
しかもRedHatって、System V系のrcファイルでdaemonの面倒を見ているので、あの設定ファイルはあっちで、こうやって止めて、再起動はこう、などという繁雑さからケロリと逃れ、単に /etc/rc.d/init.d/hogehoge restart などとすると狙ったdaemonをサックリと再初期化できたりしちゃうもんだから、もう全然リブートっつ〜もんをしない。ふと気が付くと2週間とか立ち上げっぱなしになってしまっている。結局のところ、使うドライバの類は一旦メモリに読み込まれようものなら、もうアンロードされることがないのだった(笑)
だったらわざわざkerneldを介して使うmoduleよりも、kernelにスタティックに取り込んでしまうほうが何かと都合がよさそうだ。やれmoduleがロードできないのなんのと悩む必要もなくなるし。
てなわけでkernelの再構築をしたわけだが、Slackなんかだとlinux-2.0.35.tar.gzなどのtarballを持ってきて、/usr/srcに展開し、make configで… といつもの手順で勝手にやればいいのだが、RedHatの場合は…？
RedHatも同じようにやっちまったよ(笑)
だが、このせいで後にちょっとハマることになるのだった。それは後述。
今ならkernel-2.0.35-2.src.rpmってのがすでにあるから、それをもらってきて、rootになって rpm -baで全部入れてもいいし、コンパイル済みのrpmを落してきてもいいだろう。
オレの場合は、kernel 2.0.35が出てすぐに、RedHatのサイト(ここはいつも混んでいて繋がらなかったりするので、日本の人はkddのミラーとかがいいかも)にまだrpmが出る前に、linux-2.0.35-tar.gzを落してきて、Slackとまったく同じやり方でアップデートしてしまった。だから、rpm -qiで見ると、ちょっと変なんだけど、まぁこれはそのうちマットウに直そう。
で、手順はというと、一応RedHat 5.1のInstallation GuideのP.153「1.1.4 Building a Custom Kernel」の項にちゃんと書いてある。このガイドでは、kernel-sourceとkernel-headersのパッケージをまず入れろ、と書いてあるんだけど、tarballからやったので、
rootになる。
cd /usr/src でディレクトリを変更
rm linux でシンボリック・リンクを削除
tar zxvf linux-2.0.35-tar.gz などでソースを展開
mv linux linux-2.0.35 でディレクトリ名を変更しておく
ln -s linux-2.0.35 linux でシンボリック・リンクを張り直す
cd linux で kernelのソースツリーに入る
make menuconfig
と、こんな風にいつもの手順でやってしまった。make menuconfigのところは、make configでもmake xconfigでもいいだろう。
で、kernelのconfigだけど、オレの場合をかいつまんで書くと
| CONFIG_EXPERIMENTAL=y | kernelのautomountを使いたいので。これをyesにしないと、configのメニューに出てこないのだ。 |
| CONFIG_MODULES=y CONFIG_MODVERSIONS=y CONFIG_KERNELD=y |
なんだ、module使ってるじゃんよ、というなかれ。一応、どうしてもmoduleにせざるを得ないものもあるのだ。で、この2番目の、CONFIG_MODVERSIONSを Y にしなかったせいで、何やらハマッた記憶があるが、どういうハマリだったのかは忘れた(笑) とにかく、moduleがロードできないとか、そんな類のことだったような。 |
| IDE関係は全部 N | IDEは使ってない。DiskもCD-ROMもなんもかんも、全部SCSIなんでね。 |
| CONFIG_BLK_DEV_LOOP=y | 今現在はLoop Back Deviceは使ってないんだけど、そのうち使って、怪しい実験など(笑)やろうかと思っているので入れておいた。 |
| CONFIG_FIREWALL=y CONFIG_INET=y CONFIG_IP_FORWARD=y CONFIG_IP_COOKIES=y CONFIG_IP_FIREWALL=y CONFIG_IP_FIREWALL_VERBOSE=y CONFIG_IP_MASQUERADE=y CONFIG_IP_MASQUERADE_ICMP=y CONFIG_IP_ALWAYS_DEFRAG=y CONFIG_IP_ACCT=y CONFIG_IP_NOSR=y CONFIG_SKB_LARGE=y |
このあたりは、IP Masqueradeを使うことを前提にした設定。ダイアルオンデマンド関係のデバッグなんかも考慮して、冗長なログを残してみる。 |
| CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y CONFIG_BLK_DEV_SR=y CONFIG_BLK_DEV_SG=y |
SCSIマシンなので、この辺は必須だ。CD-ROMやDiskのみならず、CD-Recorderも使っているので、SCSI Generic Deviceも忘れず Y に。 |
| CONFIG_SCSI_AHA152X=y CONFIG_SCSI_AIC7XXX=y CONFIG_SCSI_PPA=m CONFIG_SCSI_PPA_HAVE_PEDANTIC=y |
スキャナ専用にAdaptec AHA-1521を、その他 Disk関係は全部 Adaptec AHA-2940UWにブラ下がっているので、それぞれを有効に。ここで初めてmoduleが出てくるが、ごくたま〜に、パラレルポート接続のZIPドライブを使わなければならない時があるので、そのドライバをmoduleにしてある。ほとんど使わないんだが… |
| CONFIG_NETDEVICES=y CONFIG_NET_ETHERNET=y CONFIG_NET_VENDOR_3COM=y CONFIG_EL3=y |
Ethernet関係は、3COM の 3c509B を1枚使っているので、これはもうそのまま。PnPも殺してない、出荷時のまま単にブッ差しただけだが、特に認識に失敗したりということはない。いまんとこ。 |
| CONFIG_MINIX_FS=y CONFIG_EXT2_FS=y CONFIG_NLS=y CONFIG_ISO9660_FS=y CONFIG_FAT_FS=y CONFIG_MSDOS_FS=y CONFIG_VFAT_FS=y CONFIG_NLS_CODEPAGE_437=m CONFIG_NLS_ISO8859_2=m CONFIG_PROC_FS=Y CONFIG_AUTOFS_FS=Y |
ファイルシステムはこんな感じ。MSDOS_FSってのが、FATやVFATと別に用意してあるのって、いまだに違和感があるのだが…。フロッピーやらZIPドライブやらをWindows95から持ってきて見たりするぶんには、MSDOS_FSっていらないようだ。DOSEMUやWINEを使うときには必要なのかな？WINEはそのうち使いたいと常々思っているので、MSDOS_FSもいつも有効にしているけど日の目を見ないまま(笑) CODEPAGE関係は、いるのかいらないのかよくわからん(笑)ので、最低限 437 だけをmoduleにして放ってある。/procはお約束として、AUTOFS_FSってのが、一度使うともうやめられない便利さなので、当然 Y に。 |
| CONFIG_SERIAL=y CONFIG_PRINTER=m CONFIG_MOUSE=y CONFIG_PSMOUSE=y |
プリンタはmoduleになっている。印刷するとkerneldが勝手にロードして、印刷が終るとメモリから捨てられる。パラレルなZIPドライブが捨てられないばっかりに、moduleにせざるを得なかった。2.1系のkernelなら、パラレルポートをバスとして使えるそうなんだが…。マウスはPS/2インタフェースのLogitech 3 button mouseを使っている。ホイールは使ってない(笑) |
| CONFIG_SOUND=y CONFIG_AUDIO=y CONFIG_MIDI=y CONFIG_YM3812=y CONFIG_SB=y CONFIG_ADLIB=y SBC_BASE=220 SBC_IRQ=5 SBC_DMA=1 SB_DMA2=5 SB_MPU_BASE=330 SB_MPU_IRQ=-1 DSP_BUFFERSIZE=65526 | SoundBlaster AWE64 Valueというカードを使っている。なんだかよくわからないが、それなりにちゃんと音が出ているからよしとする(笑) |
で、とにかくこんな風に好みの設定にしてから、お約束の
make dep; make clean
make boot
make modules ; make modules_install
を実行する。Slackの時は、make bootじゃなくて、make zliloなんてやって、直接 vmlinuz を / 直下に作って一気に lilo までやっちゃってたけど、RedHat は kernel が /boot に置かれるようになっているので、make boot で作って、後に自分で手でコピーするのがよいらしい。なんか Shell Scriptくらいありそうだけど、まぁマニュアルには make boot 後に手でコピーせぇと書いてあるからよしとしとく。
てなわけで、cp /usr/src/linux/arch/i386/boot/zImage /boot/vmlinuz などとして kernel イメージを配置してやり、lilo を使う人は /etc/lilo.conf を適切に編集してから /sbin/lilo する。この辺もまぁお約束だね。オレは Windows などの他のOSを一緒に入れておらず、全パーティションが linux 用で MBR からの直接起動なんで、常に黙って /sbin/lilo している。
あと、注意する点としては、ブート時にkernelに渡すパラメータの設定だ。オレの場合は、PnPでないISAのSCSIカードを一枚使っていて、Ethernetカードに3COM 3C509Bを使っている。さらにメモリも128MBなので、kernel 2.0系の自動認識してくれるメモリサイズを越えているため、明示的に指定してやる必要があるのだった。
append="mem=128M ether=10,0,eth0 aha152x=0x340,11,7,1"
上記のappend行をlilo.confに追加し、リブートしてみると…
作った module を一つも見付けてくれないぞ。
よくよく調べてみれば、カギは /etc/rc.d/rc.sysinit にあった。単に、/boot に vmlinuz があり、そのバージョンが 2.0.35 だったときに、/lib/modules/2.0.35 の下に module を探しに行ってくれるってなもんではなかったのだ。
カラクリとしては、/etc/rc.d/rc.sysinit の中で、指定された kernel イメージのファイル名から、バージョン番号とリビジョン番号を抜きだし、それを利用して module の検索 path を毎ブート時に決定するようになっているようだ。それも、リビジョン番号までが絶対に必要だ。
だから、RedHatから提供された kernel をただ黙って使っているぶんには問題はないが、自分で tarball から make しちゃった場合は、かならずウソでもバージョン番号とリビジョン番号を kernel イメージのファイル名に含めてやる必要がある。
たとえば、自分で 2.0.35 の kernel を make したとしよう。その場合は、リビジョン番号を 0.1 などと自分で決めてしまい、vmlinuz-2.0.35-0.1 を /boot の下に置こう。もちろん、/etc/lilo.conf でも image=/boot/vmlinuz-2.0.35-0.1 と記述しておかないとブートしなくなっちゃうから注意だ。これで kernel イメージの準備はやっと完了。
で、今度は module だけど、2.0.35 のソース・ツリー から make modules すると、普通は /lib/modules/2.0.35 以下に module が配置される。が、これを先程準備した kernel イメージに合わせて、/lib/modules/2.0.35-0.1 に mv でリネームしてやる。
/etc/lilo.conf が vmlinuz-2.0.35-0.1 になっているのを確認して、/sbin/lilo した後にリブートすると、今度は /etc/rc.d/rc.sysinit が /lib/modules/preferred -> /lib/modules/2.0.35-0.1 というシンボリック・リンクを張ってくれて、めでたく module を見に行ってくれるようになる。
こういう風にして、RPMの知らないところで kernel のバージョン・アップなどを行ってしまうと、RedHat に最初から入っている kernelcfg などが動かなくなるかも知れない。が、kernelcfg なんて、どうせ大したツールじゃない(いや、マジであってもなくても誰も困らぬ)ので、オレ個人としては全然気にしていない。
結局、取り組み方としては Slackware と何ら変わるところはない。納得いくまで自分で make するのを基本としているし、その際に避けられない試行錯誤のターンアラウンドを、RPMで便利にパッケージの管理が(自分で make した、信用できないパッケージでさえも！)でき、System V系のrcファイルが使えるってだけでもう充分に短くしてくれているからね。
| メール | 戻る |