"WARNING: cannot set battery backed clock..."というメッセージが出ます気にする必要はありませんが、このメッセージが出るのはむしろ古いカーネルです。新しいカーネルは 次の項にあるメッセージを出します。
"NetBSD/mac68k does not trust itself to update the RTC on shutdown."というメッセージが出ますこれは単に、コンピューターのリアルタイムクロックをNetBSD/mac68kカーネルがセットしないということを示しているに過ぎません。というのはNetBSD/mac68kには 長い間動かしていればいるほど時計が遅れていくという問題があるからです(ですから遅れた時刻をRTCにセットするとMac OS側でも時計がずれていくことになります)。しかし、RTCを更新するコード自体は存在しており、もしそう望むのであれば、更新を行うようなカーネルを構築することも可能です。
init: not found
panic: no init
Pausing forever.
/sbin/initがインストールされていないのが原因です。Installerのミニシェルでls /sbin/initを実行してインストールされているか確認してください。また、NetBSD 1.3やcurrentスナップショットのbaseセットのインストールが間違いなく行われたことを確認してください:
audio at mainbus0 not configured
floppy at mainbus0 not configured
オーディオ対応はリリース1.2以前から存在します。現在では以下のようなメッセージが出力されるはずです:
asc0 at obio0: Apple Sound Chip
しかし、フロッピー対応はまだ実装されていません。これも作業中ではあります。
[訳註:このバグはとても古いバグです。下にも書いてありますが、とっくの昔に修正されていますから、これに出喰わすことはまずないでしょう]もしこれが画面最下行にカーソルがある状態で起こったとしたら、これは悪名高い「ADB入力の最中にスクロール」バグが原因です。いくつかこれを避ける方法があります:
clearコマンドで画面を消去する/etc/ttysをエディットしてシリアルポートに接続した端末を使うようにするdtというプログラムを使う(これは良い解決策です)
changing root device to sd1a.
Swapping 409 and 401.
Swapdev = 409, dumpdev=ffffffff.
新しいルートパーティションをマウントするように/etc/fstabファイルを編集する必要があります。またはInstallerユーティリティーを使用して今の/etc/fstabを消去し、その後"Build Devices"を実行して新しいファイルを作らせることもできます。
この症状は恐らく以下のようなものだと思います:
Extra-debugger infoをオンにしてマルチユーザーモードでブートすると:Changing root device to sd1a. PRAM: 0x30d482dc, macos_boottime: 0x30d482d1. vm_fault(10c000, 8bb3000, 1, 0) -> 1vm_fault(10c000, 8bb3000, 1, 0) -> 1vm_fault(10c000, 8bb3000, 1, 0) ->と表示され、そしてハングします。
残念ながら1.1配付版のカーネルには結構バグがあり、多くの機種、とくにIIciで正常に動作しません。 1.5 配付版をダウンロードして試してください。
netstat -rを実行するとnetstat: kvm_read kvm_read: Bad addressというエラーになりますこれは心配には及びません。基本的には/netbsdが現在動作中のカーネルでないのが原因です。いくつかのプログラム、例えばps、who、systatなどlibkvmを使用するものは/netbsdファイルをオープンしてカーネル内の情報を取り出します。ですから、現在使用中のカーネルを/netbsdとリネームすればこのエラーは出なくなるのです。うっかり使用中のカーネルファイルに上書きしてしまったりしないよう注意してください。
netstat -rを実行するとクエスチョンマークの嵐になりますこれはlibkvm/netstatと/netbsdのミスマッチ、または現在動作中のカーネルが/netbsdというファイル名でないことが原因です。この問題の他の症状としては、who、ps、ifconfig、そしてsystatも正常に動作しないことがあります。カーネルと他のバイナリーを同時にアップデートすればこの問題は起こらないでしょう。
w、ps、netstatその他のプログラムが正常に動かなくなってしまいました次のうちどちらかです:現在動作中のカーネルが/netbsdというファイル名でないか、カーネルとバイナリーにミスマッチが起きていることです。最初のケースでは単に現在使用中のカーネルファイルから/netbsdへリンクを張るだけで症状は収まります。
二番目のケースでは、libkvmを更新すれば、動的にリンクされたバイナリーについては症状が収まるでしょう。静的にリンクされたバイナリーはカーネルとマッチしたバージョンで置き換える必要があります。静的にリンクされているプログラムをもし自分でコンパイルする場合は、プログラムそのものをコンパイルするより前に libkvm.aを更新するのを忘れないでください。
John Wittkowski (jpw@netscape.com)のおかげでlibkvmに依存している(/bin/ps以外の)プログラムのリストを以下に示せます(これらのどれも/usr/binにあります):
fstatgdbipcsnetstatnfsstatsystatuptimevmstatwpsコマンドを実行すると"proc size mismatch"というエラーが出ます前三項と同様、答はlibkvmバイナリーおよびカーネルとの間にミスマッチが起きていることです。これを解決するにはカーネルに合ったバージョンのバイナリーをインストールするか、以下の手順を踏んで自分でバイナリーを構築するかします:
"proc size mismatch"エラーが出て、ライブラリーを更新する必要があるとはっきりしたら以下のようにします:
1.ソースコードを入手します。もしこれをやりたくない場合は誰かかわりに
やってくれる人を探してすべてを手動でインストールする必要があります。
2.ヘッダファイルが最新のものであることを確認します。
cd /usr/src
make includes
これにはしばらく時間がかかるでしょう。私がやったときには
Makefileの中にはINSTALL変数を定義していないものがあっ
たため、多少トラブルを経験しました。"make includes"が失
敗したときにはいつでも、失敗したディレクトリーに移動して次
の一行をMakefileにつけ加えました:
INSTALL=/usr/bin/install
Makeがエラーなしで終了するようになるまで、これを数回や
る必要がありました。
(/usr/bin/makeと/usr/share/mk以下のファイルをきちんと
最新にすれば、このトラブルは恐らく避けられると思います
--Colin)
3. Libkvmを再構築してインストールします:
cd /usr/src/lib/libkvm
make
make install
私のシステムでlibkvmをコンパイルしてインストールするに
は次のコマンドを実行しなくてはなりませんでした:
cd /usr/include/machine
ln -s ../m68k/kcore.h kcore.h
これは私のシステム特有の変な癖であった可能性もあるので、
まずこれをやらずにコンパイルしてみてください。
4.次にlibkvmと静的にリンクされるバイナリーの再構築をします。
そのようなプログラムは、私の知る限りでは"/bin/ps"だけ
です。このためには単に次のコマンドを実行します:
cd /usr/src/bin/ps
make
make install
5. Libkvmと動的にリンクされるプログラムを再構築する必要があ
るかどうかは一概には言えません。これは、(私が思うに)ライブ
ラリーのメジャーバージョンが上がると古いバイナリーはその新しい
ライブラリーでは動作しなくなるからです。例えば、私の古い
libkvmはlibkvm.so.4.0でした。新しいものはlibkvm.so.5.0
です。プログラムを再コンパイルしないと、依然"proc size
mismatch"エラーが出る(バージョン4.0のライブラリーファイル
がある場合)か、またはライブラリーが存在しないというエラー(バ
ージョン4.0のライブラリーを削除した場合)が出ます。マイナー
バージョンだけが変わった場合(例えば4.0から4.1)は、警告
が出ることもありますが、通常はプログラムは動作しますから、
再コンパイルは必要ないでしょう。
libkvmと動的にリンクされるプログラムは私が知っている限り
で以下の通りです:
/usr/bin/fstat
/usr/bin/gdb
/usr/bin/ipcs
/usr/bin/netstat
/usr/bin/nfsstat
/usr/bin/systat
/usr/bin/uptime (/usr/bin/wにリンクされている)
/usr/bin/vmstat
/usr/bin/w
/usr/bin/uptimeは/usr/bin/wへのリンクで、"make install"
を実行することで正しく設定されます。
これらを再コンパイルするには、以下のようにします:
cd /usr/src/usr.bin/<cmd>
make
make install
例えば/usr/bin/vmstatの場合:
cd /usr/src/usr.bin/vmstat
make
make install
このように詳しい回答を寄せてくれたJohn Wittkowski (jpw@netscape.com)に大変感謝します。
このエラーはシリアルドライバーのバグによるものです。修正は行われましたが1.1のリリースには間に合いませんでした[訳註:つまり1.2以降では修正済みです]。それ以降のカーネルであればこの修正は取り入れられているはずです。
(注意:もし現在でもこのエラーが出ているような場合は、この項の最後の段落を参照してください)
これがBill Studenmund (wrstuden@loki.stanford.edu)からの最新情報です:
シリアルポートの問題が修正できたことを皆さんにお伝えできることに、大変
喜んでいます。ftp.NetBSD.org上のcurrentソースは修正済みのはずです。
この問題は、私達が割り込みレベル(とくにspltty)の設定の仕方について誤
解していたことが原因であったことがわかりました。カーネルへのデータ渡し
だけを止めておく必要があったところで、チップの割り込みを止めていたので
す。一時的バッファ(リングバッファ)から文字が出ていくのを止めるべきだっ
たのですが、実はバッファへ文字が入っていくのを止めていたのでした。これ
によりたくさんのfifoオーバーランが発生しました。
私はPPPを非常に確実に動かすことに成功しました。数メガバイトのデータ
を、ひとつのfifoエラーもなしに転送できました:-)
変更されたファイルはsys/arch/mac68k/include/param.hです。このファイ
ルが変わったということは、カーネルのかなりの部分が再コンパイルを要する
ということに注意してください。
Noud de Brouwerは近所の人向けにISPを運営していますが、彼も新シリア
ルドライバーを使用してすばらしい数字を出しています。6Kバイト/秒くらい。
高速転送についての警告:もし高速、例えば28800ビット/秒を超えるような
スピードでデータ転送中に、何かほかのこと、例えばコンパイル、他ホストへ
のログイン、Ethernetの使用などをやろうとすると何か問題が起きるかも知
れません。何も問題はないかも知れません。1文字受信するたびにCPUはそ
れまでやっていたことを一旦置いて、コンテキストをセーブし、文字を取得・
保存し、そしてさっきまでやっていたことを再開します。これがDMAなしの
人生です。:-(うまく動作はしますがCPU時間を食います。気に留めておい
てください。
最近割り込みハンドリングに対する変更によってこのエラーがまた出るようになったようです。既に修正は行われてはいますが、新しいシリアルドライバーによってこの問題に結着がつくはずです。新シリアルドライバーが採用されたらそれについても書きます。
Bootstrapping the pmap system.
Failure in BSD boot. nextpa=0x106000, high[0]=0x100000.
panic: You're hosed!
メモリーコントロールパネルで32-bitアドレスモードにするのを忘れたのです。これをやれば、他の問題がなければうまくブートするはずです。
これは、24-bitビデオカードがインストールされていない場合に成り立ちます。例えばApple 8.24やRadius Preciesion Color Pro 24XPなどがインストールされていると、どういう訳か1.2カーネルは32-bitアドレスモードの検出がうまくできないようです。
この問題は1.1では起きなかったことから、最近のカーネルでは修正されていると期待されます。または、取り敢えずそうしたビデオカードを取り外すという手もあります。
Mar 2 13:03:04 myname init: kernel security level changed from 0 to 1
mrg: no trace functionality enabled
panic: kernel jump to zero
シリアルコンソールを使用してブートしていて、なおかつ/etc/ttysを変更して/dev/ttye0上でのログインの抑制と/dev/tty00上でのログインの許可を行っていない場合には、この挙動は正常です。例えば以下のように変更します:
/etc/ttysを:
# Define console that we actually run getty on
ttye0 "/usr/libexec/getty Pc" vt220 on secure
.
.
.
#Hardwired lines are marked off ...
tty00 "/usr/libexec/getty std.9600" unknown off secure
から:
# Define console that we actually run getty on
ttye0 "/usr/libexec/getty Pc" vt220 off secure
.
.
.
#Hardwired lines are marked off ...
tty00 "/usr/libexec/getty std.9600" unknown on secure
に書き換えます。
上の修正を寄せてくれたBrian Wimberly (brianw@scripps.edu)に感謝します。
/netbsd: Panic switch: PC is 0x7f734.
/netbsd: ae0: warning - receiver ring buffer overrun
[訳註:このバグはどうやら相当古いもののようです] Steve Weiss (srw@izzy.net)によれば:
このバグは既知で修正済みです。
一ヶ月ちょっと前、私はApple Ethernetドライバー、dev/if_ae.cのバグに気付きました。そのバグは、タリーカウントレジスターが溢れたときにカードが上げた割り込みレベルを、下げていなかった、というものです。これは、ハングするまでの時間がネットワークトラフィック量に比例するということです。
Allen Briggsがこれを修正して2月2日[訳註: 1998年ではないようです]にソースツリーに修正をチェックインしました。Pumaの彼のoutgoingディレクトリーにいくつかこの修正が入ったカーネルがアップロードされています。もっとも古いものがnetbsd.please.test (2/4)で最新のものがnetbsd.GENERIC-5 (3/7)です。READMEをチェックしてください:
ftp://ftp.macbsd.com/pub/outgoing/briggs/
私のIIciはトラフィックによっては3分から5分おきにハングしていたものですが、この修正により、GENERIC-3カーネルでuptimeが二週間にも達しました。
/netbsd: ae0: warning - receiver ring buffer overrun
/netbsd: ae0: device timeout, recovered
もしこれがブートの後も続くようでしたら、何らかの問題があると見たほうが良いでしょう。しかし、これがブート時だけだったら恐らく、カードがMac OSで既に初期化されておりNetBSDのブート時に動作中であるためで、心配はいりません。
回答を寄せてくれたHenry B. Hotz (h.b.hotz@jpl.nasa.gov)に感謝します。
Scott Reynolds (scottr@og.org)からの回答:
これは非常によく知られた問題で、Sunの(そしてHPの、少くともHP-UX 9.xまでは) telnetが非常に古くて正しくないコードをベースにしていることから発生しています。この問題にはふたつの回避策があります: (a)新しいtelnetソースをftp.cray.comから入手し、Sunにコンパイル・インストールする、または(b) inetd.confファイルのtelnetdのエントリーに"-k"オプションをつけることです。はじめの解決案の方が良く、後者は状況を少し良くするでしょうが、一方「正しい」telnetからアクセスした場合には別の問題が発生するでしょう。
恐らく、Macのtelnetも同様の問題を抱えているのでしょう。Telnetの代わりにrloginを使うと大抵うまくいきますが、sshがあるならそちらを使うことをお薦めします。
Unimplemented Trapシステムエラーでクラッシュしてしまうのですか?Bill Studenmund (wrstuden@loki.stanford.edu)からの回答:
最小限のMac OSをインストールしたシステムなのではないですか?仮想メモリーをオンにしたままでNetBSDをブートするための実験の一部として使用されたシステムコールがあります。この実験は完成しませんでしたが、このシステムコールは残ったままでした。このシステムコールは最小システムでは実装されていないのですが、フルインストールでは実装されます。
Booter 1.9.4以降へアップグレードすれば問題は解消します。
savecore: can't find device 0/0と出るのですか?Allen Briggs (briggs@puma.macbsd.com)より:
これは、/netbsdと現在実行中のカーネルが同じではないために起きます。savecoreはデフォルトのダンプデバイスを取得するためカーネルファイルにアクセスする必要があるのですが、このとき/netbsdと現在実行中のカーネルが異ると混乱してしまいます。そのようなプログラムは他にもいくつかあります。
もし、Ethernetかビデオカードを認識した直後にハングしているのであれば、これは恐らく割り込み干渉バグだと思われます。ビデオとEthernetカードの組み合わせによって割り込みが干渉することがわかっており、通常ブート時にハングします。
一方を取り除けば問題は解消しますが、新しいカーネルを試してみるのもよいでしょう。というのはこの手の問題は時々修正されているからです。
Allen Briggs (briggs@puma.macbsd.com)は、この種のバグを修正するのに必要な情報を探すためのHOWTOを書いてくれました: http://www.macbsd.com/macbsd/howto/video.html
ae0: NIC memory corrupt - invalid packet length 65280というエラーが出るのはなぜですか?このエラーメッセージの完全な文面はたぶん次のようなものでしょう:
ae0: length does not match next packet pointer
ae0: len 0000 nlen ff00 start 0c first 00 curr 20 next 00 stop 40
ae0: NIC memory corrupt - invalid packet length 65280
これはほとんどの場合Mac OS側のネットワーク(EtherTalkやMacTCPなど)がNetBSDブート時に既に動作中であったのが原因です。拡張機能なしでMac OSをブートすれば症状は消えるはずです。Mac OSのネットワークを停止しておかないと時にはこの時点でシステムがハングすることもあります。
回答を寄せてくれたIsaac Salpeter (isaac@ticalc.org)に感謝します。
Allen Briggs (briggs@puma.macbsd.com)によれば、これらのメッセージはまったく無害で、またDIAGNOSTICオプションを指定しないでカーネルをコンパイルすることでメッセージの出力を抑制することができるということです。
/dev/sd0a on /: specified device does not match mounted deviceというエラーが出るのはなぜですか?これは、/etc/fstabファイルが実際のディスク・パーティション構成と一致していないことを示しています。考えられる原因としては、バージョン1.1aから1.1cまでのInstallerユーティリティーが正しくない/etc/fstab (すべてのパーティションがsd0上にあるように書かれてしまう)を作ることがあることです。もしsd0を使っていない場合、以下のふたつの解決策があります:
/etc/fstabをcopyoutし、テキストエディタ[訳註: BBEditやGNU Emacsなど、UNIX形式の改行コードが扱えるエディタを使用すること]を使って現実を正しく反映するよう編集します。そしてできたファイルをInstallerでcopyinします。/etc/fstabを作り直します。もうひとつの可能性は、NetBSD 1.3以降はApple Driverタイプのパーティションを無視するようになったため、パーティションを表わす文字に若干の移動が出る場合があることです。disklabel sdX (ここで"X"は使用するドライブの番号)を実行することで、NetBSDがパーティションをどのように見ているかわかります。これを参考にして/etc/fstabを変更します。
panic: ResHndls table too small!
Bob Nestor (rnestor@metronet.com)による回答:
このエラーは、ROMリソースコールを行っているうちにResHandlesがなくなってしまうことから起きるものです。これはMRGによるADB対応によるもので、したがってHardware Direct ADBドライバーでは起きないでしょう。なぜ特定のADBデバイスでResHandlesテーブルが一杯になってしまうのかはよくわかっていません。以前この問題についてある人と一緒に作業していたのですが、ROMの中のリソース総数より多きなサイズのResHandlesテーブルを用意してもエラーを完全に解消することはできませんでした。これは恐らく、ResHandlesテーブルの使い方に誤りがあり、なおかつADB ROMルーチンの中に何らかのループがあってこれらのデバイスを取り扱おうとしてるのだと思います。Mac OSではADBルーチンのROMパッチが存在しますが、NetBSDのMRGではそうしたパッチは使用していません。これがこの問題と関係しているのかも知れません。
という訳で、誰かがMRGコードを掘り起こしてバグを修正しない限り、現実的解決策はHardware Direct ADBコードの完成を待つか[訳註:これはほぼ完成していると見てよいと思います]、または問題を起こしているADBデバイスを取り外して使用するかのどちらかです。
Warning: Battery clock earlier than filesystem dateとエラーが表示されますNico van Eikema Hommes (hommes@ccc.uni-erlangen.de)の回答:
私は何が起きているのかつきとめたと思います:これはInstallerのバグで、ファイルシステムのタイムスタンプが、本来GMTが格納されるべきところがMac OSのローカル時間が格納されているのです(このことはcpinした後でlsすると確認できます)。ファイルシステムがマウントされるとき、タイムスタンプはGMTとして見做され(それが正しいのです)、そしてローカル時間とGMTの時差が加算されます。[訳註:時差が正の場合は]これによってタイムスタンプは現在時刻よりも進んだ時刻として計算されます。症状の不規則性はもちろんインストールとブートの時間差によるものです。GMTとの時差が負であるアメリカではこのメッセージが出力されないため、この問題は気付かれずにここまで来たのでしょう。
Installerの最新バージョン(1.1e)ではこの問題は修正されており、タイムスタンプにはGMTを使うようになっています。
"kernel is not in a format the booter can understand"というエラーメッセージが出ますたぶん、Mac OSパーティションのカーネルファイルからブートしようとしていて、アーカイブファイルから生のカーネルファイルを取り出すのを忘れているのではないでしょうか(たくさんのカーネルファイルはtarアーカイブ、gzip圧縮ファイル、またはgzip圧縮tarアーカイブのいずれかのフォーマットでアップロードされています)。拡張されたStuffIt Expander、あるいはMacGzipとSun Tarユーティリティーなどで生のカーネルファイルが復元できます。このとき、改行コード(テキスト)の変換が行われないよう、注意してください。さもないとカーネルバイナリーを破壊する結果となります。
"sn0: receive descriptors exhausted"というエラーが出るのでしょうか?Denny Gentry (denny1@home.com)曰く:
SONICチップは受信したパケットをデータバッファにDMA転送します。このとき、バッファ上のデータのアドレスや長さなど、ドライバーに渡す情報を書き込むためのディスクリプターが必要です。もしこのディスクリプターの領域が一杯になるとSONICチップはCPUに割り込みをかけます。
これは通常、かなり長い時間snドライバーに制御が渡らず、受信したパケットを処理してディスクリプター領域に空きを作ることができなかったことを意味しています。これは大量のSCSI I/Oが行われているときなどに起こることがあります。というのはSCSI I/Oのためにネットワーク割り込みがブロックされるからです。早朝/etc/dailyなどのスクリプトが実行されますが、これによって大量のディスクI/Oが実行されます。もしこのとき誰かがこのマシンへアクセスしようとすると、ディスクリプターの枯渇が簡単に起きてしまうことがあります。
数週間前、受信ディスクリプター用に別個の4Kページを使うことによってディスクリプター数を増やす修正を送りました。その変更はScottがチェックインしましたから、「最近」のカーネルを使うよう気をつけてください。1.2Dのカーネルを使っているようですが、1.2Gではディスクリプターが増加しているはずです。
SONICチップでは、ディスクリプター領域は物理アドレスで連続している必要があるので、もっとディスクリプターを増やす[訳註:ページサイズよりも大きな領域を割り当てる]には、物理的に連続したカーネルメモリーを割り当てる手段が必要になります。
"warning: no /dev/console"というメッセージが出たあとハングしてしまいますこれともうひとつよく似たメッセージ:
warning: lookup /dev/console: error #
情報を寄せてくれたBill Studenmund (wrstuden@loki.stanford.edu)に感謝します。
You booted with booter version 1.8.
Booter version 1.11 is necessary to fully support this kernel.
Scott Reynolds (scottr@NetBSD.org)より:
ミニルートを使っているのではない限り、これは無害なメッセージです(まあ、もし今ミニルートを使っているとしたら、そのやり方は現在では推奨されていないやり方なのですが)。この警告メッセージとは関係なく、バージョン1.9.5以降のBooterを使って新しいカーネルを安全にブートすることができます。
カーネルに渡されるBooterバージョン情報は長いこと時代遅れのものでした。それでBooterの次のバージョンが1.10.3ではなく1.11なのです。バージョン情報が修正されたBooterを使っている場合の潜在的な問題を回避したかったのです。
この問題は、IIcxユーザーが特によく遭遇するもののようですが、他の旧型IIシリーズの機種でも報告されています。どうやらこれは、カーネルの大きさやカーネル内データ構造の位置に依存した、低位メモリーのおかしな相互作用の結果のようです。
ひとつの回避策は、不要なデバイスドライバーを削除したカスタムカーネルを自分で構築することです。これによって症状が解消することがよくあります(効かないこともあります)。もうひとつは、まず試しにMac OSでシャットダウンとリブートをやってみます。もしこれでハングするようなら(そういうことが多いようです)、シングルユーザーに落ちて(shutdown)ディスクをsyncし、手動で電源を切る以上のことはできません。
Table of contents of this chapter, General table of contents