これはとても簡単です。まずBooterユーティリティー(現時点で最新はバージョン1.11.1ですが、古いバージョンでも動作するかも知れません)とカーネルファイル(できればgzip圧縮tarファイルでなく生ファイルかgzip圧縮ファイル)を入手します。Booterの最新版はgzip圧縮カーネルをロードすることも可能です。どちらも通常、 ftp.macbsd.com または ftp.NetBSD.org から anonymous ftp で入手できます。 Booterのメニューで[Options]->[Booting...]を選択してください。"Booting Options"のダイアログボックスが現れたらカーネルの場所を指定するための"Mac OS File"ラジオボタンを選択します。[Set...]ボタンをクリックすると標準のファイルダイアログボックスが現れます。コピーしたカーネルファイルを選択し[OK]をクリックしてください。次にメニューから[Options]->[Boot Now]を選択します。するとBooterウィンドウをいろいろスクロールしていくのが見え、次いで画面全体が真っ白になるはずです[訳註:ビデオモードが16ビット以上の場合は真っ黒]。ブートストラップメッセージが続いて表示されるはずです。ブートメッセージが下に示す行まで達したら:
boot device: sd0
root device (default sd0a):
haltとタイプするとマシンはきれいにシャットダウンするはずです。
Mac OS側Booterから抜け出さない場合、Booterのビデオ割り込みなどに関するオプションを無効化して試してみてください。別の可能性としては圧縮カーネルファイルを展開するときにファイルを壊してしまったことが考えられます。もしそうならBooterは下のようなメッセージを出したところでハングするはずです:
Set _mac68k_vrsrc_vec to {0x0 0x0 0x0 0x0 0x0 0x0 }.
MacGzipとSunTarなどでファイルを展開し、小さなかたまりに再度アーカイブすることができるでしょう。その後再度gzip圧縮します。[訳註:これはいかにも面倒な手法ですが、Stuffit LightやCompact Proなどを起動し、無圧縮モードで配付ファイルを分断する方が、簡単に1.4MBの断片に分けられそうな気がします。インストールする前に同じユーティリティーで逆の操作を行って配付ファイルを復元し、Installerでインストールします]
文字通りの意味では、これは「世界の終末の教え」ということになります。
ここでは、旧バージョンのA/UXのパーティションタイプのひとつを意味します。システムを災害に備えるようにという、システム管理者達への合図として、Appleはちょっとしたユーモアのつもりで命名したに違いありません。Eschatologyパーティションは、システムがダウンしても重要なシステムファイルを自動的に復旧することになっています。これはA/UXの「自動復旧」プロセスの一部と位置付けられています。重要なシステムファイルのバックアップコピーをふたつのパーティションに保存しておくことで動作することになっていました—EschatologyとEschatology2です。5年間の大学生活で何百人の学生がA/UXマシンを使うのを見てきましたが、この「自動復旧」が作動して能書き通りの効用を発揮したところなど、一度も聞いたことはありません。[訳註:これはMacBSD発祥の地、Virginia Techでの(古い)話ではないかと想像します。Aliceチームのメンバーが入学した頃のVirginia Techでは、学生はMac IIを買わされていた、とAllen Briggsが言っていたように記憶しています。VT以外に何百人もA/UXユーザーがいるサイトなんてなかなか想像できませんし…]
これはEschatologyパーティションの新しい名前です。AppleはA/UX 2.0でEschatologyをAutorecoveryと改名したと思います。
いいえ。
もしお使いのパーティショニングソフトウェアがどうしても"Eschatology"、"Eschatology2"または"Autorecovery"パーティションを作ってしまったら、そのパーティションは削除して、他のパーティションサイズを増やして無駄な空間をなくしてしまいましょう。
ファイル名が.hqxで終っているファイルはBinHexフォーマットのファイルです。これらのファイルはまず変換してバイナリー形式に戻す、つまりde-BinHexする必要があります。Mac OSでこの変換を行うユーティリティーはたくさんありますし(例えばStuffit ExpanderやBinHex 4.0)、またUNIX上ではmcvertと呼ばれるプログラムを使用してデコード可能です:
mcvert base10.hqx
先に進む前に、次のチェックリストを確認してください:
Booter最新版を持っていることを確認してください(現時点で1.11.1)。
IIsiでPDS/NuBusビデオカードを使用してブートしようとしている場合、内蔵ビデオを何らかの形で使用する必要があることに気をつけてください。詳しくは ビデオカードを使用してIIsiをブートする項を参照してください。
フルインストールしたNetBSDをブートしようとしている場合(つまり、Mac OSボリュームに置いてあるカーネルファイルをテストしているだけではない場合)、Installerユーティリティーで[Build Devices]の実行を確認してください。またデバイスファイルを作る前に、スワップパーティションの存在を確認し、/etc/fstabファイルに正しくスワップパーティションのエントリーが作られるようにしてください。
バージョン1.1aから1.1cまでのInstallerでは、すべてのパーティションがsd0にあるかのような、状況によっては正しくない/etc/fstabファイルを作りますから注意が必要です。解決策はInstaller 1.1d以降を入手することです(現時点では1.1gが最新です)。
上のどれもうまくいかないときは、ふたつの可能性が考えられます:ひとつはNetBSD/mac68kはあなたのマシンに対応していないこと。もうひとつはブートしようとしているカーネルがあなたのマシンやハードウェアに対応していないことです。違うカーネルを試してみると良いでしょう。他のカーネルを入手できるウェブやftpサイトのリストはメタFAQをご覧ください:
../meta-faq/
もしかしたら役に立つかも知れないのがmachine-statusノートで(どれだけ最近に更新されているかにもよりますが)、これによってNetBSDの各機種への対応状況がわかります。下のURLをご覧ください:
http://www.macbsd.com/macbsd/macbsd-docs/machine-status/
最後に、このMark Andres (mark@ratbert.aisol.net)のMacBSDカーネルページ:
http://www2.giganet.net/~mark/NetBSD/kernels.html
Allen Briggs (briggs@macbsd.com)のコメント:
これはあなたが内蔵ビデオを使っていないのが原因です。IIsiは1MBのみのメモリーがバンクAメモリーとしてマザーボードに直付けされており、内蔵ビデオが使用されるかどうかによって、メモリーマップも変ってきます。NetBSDは今のところ、物理メモリーの最初のチャンク[訳註:連続した領域]にカーネルが収まりきらない状況には対応していません。
内蔵ビデオが許可されると、バンクAメモリーの一部がディスプレイ用に使用され、バンクBの後方にマップされます。この場合バンクBはアドレス0x0から始まります。ところが内蔵ビデオが禁止されるとバンクAが0x0から始まり、バンクBがバンクAの後方に(1MBから)マップされます。これはIIciでも同様ですが、大部分のIIciユーザーはバンクAに1MBより多いメモリーを持っているので問題にはなりません。
この問題は、内蔵ビデオポートにモニターを接続する、ディスプレイアダプターをつけておく、あるいはペーパークリップで[訳註:4番と11番の]ピンをショートする、のいずれかの方法で、モニターが接続されているとビデオ回路が考えるように仕向けることで回避できます。この回避策に関するより詳しい情報については モニターなしでのブートについての項を参照してください。
これは 前項の問題のもうひとつの症状です。回避策については前項を参照してください。
はい、Mac OSのブート時にコマンド-オプション-P-Rの各キーを押し続けることでPRAMの内容を消去する必要があります。どういう理由でか、AV Mac(つまりQuadra 840AVおよびQuadra/Centris 660AV)は他の機種よりもこの問題に敏感なようです。しかし、PRAMを消去することで大部分の問題は解決するようです。
情報を寄せてくれたDave Huang (khym@bga.com)に感謝します。
はい。セキュリティー配付セットは、DES暗号復号化コードの他には単にKerberosを使用するバージョンのtelnetなどのユーティリティーが含まれているだけです。標準のNetBSDリリースは、NetBSDシステムの通常動作に十分な暗号化コードを持って出荷されています。
単にsecr配付セットが見つからないのでなくてもいいのか不思議に思っているだけの場合は、NetBSDリリース配付ツリーのmac68k/binary/securityサブディレクトリーにありますから見てください。
Chris G. Demetriou (cgd@NetBSD.org)のコメント:
「NetBSDは一般に、『安定したリサーチプラットフォーム』として意図されています—これは、商用、ホーム、そしてリサーチワークに利用可能なシステムということです。NetBSDで何をするかは完全にあなた次第です。一般には、NetBSDを開発している私達は、どのような面であれできる限りシステムを改良することを目指しています。より多くのハードウェア対応、安定性、性能、ドキュメンテーション…」
はい。Mark Andres (mark@giganet.net)は素晴しいHowToページを持っており、彼のシステムで日本語が使えるように設定したやり方が記述されています:
http://www2.giganet.net/~mark/NetBSD/japanese.html [訳註:しかしlocaleは未だ全く未対応といっていい状態なんですが…。ところで、上のHowToページは英語で書かれていますが、日本語で書かれたページも数多く存在します。日本のサーチエンジンで"MacBSD"や"NetBSD/mac68k"などとして検索してみると良いでしょう]
いいえ、それはあまり良い考えではありません。MODE32を使うべきです。「MODE32 (7.5)」と呼ばれるバージョンの入手をお薦めします。というのは古いバージョンのMODE32ではSystem 7.1以降には正式に対応していないからです。MODE32をインストールしたら、必ずメモリコントロールパネルで32ビットアドレッシングモードを許可してください。このバージョンのMODE32は、以下の場所から入手できると思います: http://download.info.apple.com/
これは、NetBSD FFSファイルシステムではなくMac OS HFSボリュームに置いたカーネルファイルをロードしてNetBSDをブートするためのものです。このとても有用な機能によって、NetBSD全インストールという手間をかけずに カーネルをテストブートしてみることが可能となります。あるカーネルが実際にあなたのマシンで動作するなら、Mac OSボリュームにあるカーネルファイルのブートは、ルートデバイスを変えるところまで進行するでしょう。ですから、もしNetBSDをあなたのマシンで初めて動作させることに興味があるなら、このオプションは試してみるには良い方法です。
この問題はクロック割り込みの優先度を最低にすることをAppleが決定したことに起因しています(UN*Xシステムでは通常、クロック割り込みの優先度は最高です)。[訳註:UNIXワークステーションに限らず、まともなハードウェア技術者が設計すれば大抵そうなります。というのはクロック割り込みはマルチタスクに欠かせないものですし、またクロック割り込みには低レイテンシが要求される上に割り込み処理に要する時間は非常に短い、と高優先度を与える条件が揃っているのです。]結果的に、重い割り込みロードの下では(例えば大量のシリアルI/Oなど)クロック割り込みが処理されずに失われ、したがってマシンの時計が遅れていきます。明らかにこれはMac OS上でも問題ですが、NetBSDほど深刻な影響はないようです。
しかしRichard Todd (rmtodd@servalan.servalan.com)はこう言っています:
電源が切れている状態でも時間を保持するバッテリバックアップクロックはクロック割り込みのクロックよりもずっと正確です。リブートするたびにカーネルはバッテリバックアップクロックから現在時刻を取り出し再初期化しますから、正確な時刻を得ることができます。
この問題に対して何ができるでしょうか?もしインターネットに接続しているなら、xntpdを使うのが一番です。Network Time Protocol (NTP)デーモンとしてxntpdはネット上のタイムサーバーにコンタクトしてシステムクロックをサーバーの時計と同期します。1.3リリースからxntpdはNetBSDに統合されています。より詳しい使用法についてはxntpd(8)マニュアルページを参照してください。
ネットワーク接続を必要としない、より恒久的な解決策は今のところ存在しません。基本的には、定期的にPRAMクロックを読んでシステムクロックを設定しなおすようなカーネルタスクが必要になるでしょう。
大部分の人達は問題を受け入れるか、ときたまリブートするかしています。
Booter 1.8以降を使用する場合はSystem 7以降のシステムソフトウェアが必要になります。System 6はもはやサポートされていません。問題はBooterにあるようですが、誰も気にかける人はいないようです。
Installer最新版(すなわち1.1d以降)も、System 7以上が必要です。
これ以外にも、Mac OSの最近のバージョンに含まれて出荷されている多くの機能拡張は問題を引き起こすかも知れません。もし可能であれば機能拡張なしでMac OSをブートするのは一般に良いアイディアです。
いいえ。一般の意見とは逆に、NetBSDローカルコンソール[訳註:シリアルコンソールとの対照で、ビデオハードウェアを使ったコンソールという意味]に対応するすべての機種では、カラーモードでもNetBSDは普通にブートします。しかし、カラービデオの使用はコンソールに制限されてしまいます。というのはdtは[訳註:正式配付版のXサーバーも]カラーには対応していませんし、カラーXサーバーが使用できるマシンは限られているからです。NetBSDコンソールは4ないし8ビットモードでは遅くなるかも知れませんが(誰か2ビットモードを使うとは思えません)。ということで、やはり1ビットモードでブートするのが一番と言えます。もし万が一知りたいと思っているならばですが、これはNetBSDのブート前にモニターコントロールパネルを開いて"Black and White"ラジオボタンを選択することで実現できます。
より簡単な解決策(そして私もお薦めするもの)は、Booter(バージョン1.10.3以降)を使うやり方です。まず[Options]->[Monitors]を選択して、開いたダイアログボックスで"Change Monitor Depth"チェックボックスをチェックします。更に"B&W"ラジオボタンをチェックします。[訳註:設定後はプリファレンスをセーブしておいた方が良いでしょう]これによって、NetBSDブート時にBooterが自動的にピクセルデプスを1ビットに変更します。Mac OSをリスタートした時にはカラーセッティングは元に戻っているはずです。複数のモニターを使用している場合、またはどうしても古いバージョンのBooterを使う必要がある場合には、デプスを変更する何らかのプログラムが必要になるでしょう。
上の情報を提供してくれたNigel Pearson (nigel@ind.tansu.com.au)に感謝します。
現在のところ、16ビットあるいは24ビットにはまったく対応していません。16ビットや24ビットモードでNetBSDをブートすることさえうまくいかないこともあるかも知れません。必ず8ビット以下のカラーデプスでNetBSDをブートするようにしてください。[訳註:16ビット以上のモードでブートできるかできないかはハードウェア構成に依存しますが、ブートできる場合は16ビットカラーに対応したXサーバー(コード名:OSFA)も最近出回っています。カラーXサーバーについては ftp://ftp.macbsd.com/pub/NetBSD/Xを参照してください。]
十分素早ければ、コマンドと"."(ピリオド)キーを両方押すことでブートを中断できます。しかし、一旦画面全体の色が変ってしまったらもう後戻りはできません。その点以降は、ブートを止める唯一の方法はリスタートボタン(またはコントロール+コマンド+パワーキーコンビネーション)しかありません。Booterがハングしてしまった場合でも同じことが言えます。もしブートを中断したら、一度Booterを終了して再度起動した方が良いでしょう。さもないと再度ブートを試みたときにハングしたりすることがあります。
mesg yとタイプしてメッセージを許可したのに自分自身をfingerすると(messages off)と表示されます。何か見落しているのでしょうか?これは恐らく、コンソールでログインしたときにメッセージを許可せず、今はdtかXを使っているのではないでしょうか。mesg yを.loginファイルに書いておけばこの問題は起きません(またはXやdtを起動する前にコンソールでmesg yを実行するのを忘れないようにするか)。[訳註:コンソールでメッセージを許可すると、場合によってはコンソールへのメッセージでXやdtの画面が崩れてしまうかも知れません。xtermやdtの仮想ターミナル上でメッセージを許可しておけば、talk要求やwriteやwallのメッセージはそのウィンドウないし仮想ターミナルへ表示されるので問題ないような気がするのですが…]
Allen Briggs (briggs@puma.macbsd.com)の回答:
その人によってつけられます…。クリーンなソースツリーで'config GENERIC'を実行すると最初のカーネルは#0になります。カーネルをリンクしようとするたびごとにナンバーは1ずつ増えます。
という訳でナンバーそのものにはあまり意味がありません。一般には、READMEファイルをチェックしてある特定のカーネルのある特定バージョンについての違いがなんであるのかみておくのが良いでしょう。
68851と印刷されたソケットに挿さっているApple製の黒いチップは、まず間違いなくAMU(Address Management Unit)と思われます。これはMac OSの24ビットアドレスをメモリーサブシステムの32ビットアドレスに変換するために使われています。このチップはNetBSDを動かすには機能が十分ではありません(もしNetBSDがちゃんとブートするなら、恐らく実際には68851 PMMUが載っているか、または68030以上へのプロセッサアップグレードが行われたのでしょう)。
私が知っている唯一のMC68851の販売ソースはDMSです:
http://www.datamem.com/main.htm
他にもあることは十分考えられますが。これはこの会社を推奨している訳ではないので注意してください(しかしかなり低価格であると聞いてはいます)。[訳註:日本では東京の秋葉原エレクトリックパーツあたりでXC68040RC33などとともに扱われていそうな気はします。これも別にAEPを推奨している訳ではありません。念の為]
GENERICという用語は、マシンアーキテクチャーが対応するほとんどすべての機種で動作するようにコンフィギュアされたカーネルを指します。この場合、GENERICカーネルはNetBSD/mac68kが対応するどの機種のMacでもブートするはずです。この用語自体はカーネルコンフィギュレーションファイルのルートデバイスとスワップデバイスを指定する行に使用されていた"generic"という単語に由来しています。このオプションとそのフォーマットのコンフィギュレーション行は今や使われてはいませんが、この名前はしばらく残ることでしょう。
これらGENERICカーネルは、あなたが使おうが使うまいが、すべてのデバイスドライバーとすべての機種への対応を抱えこんでいるので、自分のカスタムカーネルを構築することをお薦めします。より詳しい情報については カーネル構築HOWTOを参照してください。
ftp://ftp.macbsd.com/pub/NetBSD/utils/dt/dt-1.1.5.tar.gz最近この質問が非常によく見られるので追加することにしました:
この手のリクエストはメーリングリストそのものには送らないでください。
メーリングリストに参加申込したときに送られてきた使用説明を読むか、majordomo@NetBSD.orgへ、以下のメッセージボディのE-mailを送ります:
unsubscribe port-mac68k userid@hostname.domain
もう一度くりかえしますが、この手のリクエストをメーリングリスト本体へ送ると、助けてもらうよりも却ってひやかされたりすることが多いので、説明を読んでください。
Table of contents of this chapter, General table of contents