NetBSD/amd64 on さくらVPS
一番安いプランの試用を始めました。
何の変更もなく6.1 (RC) のISOで起動。今のところ負荷をかけても安定しているようですので、そのまま契約しそうな流れです。
ACPIやSMPは切らなくても問題ないようです。
CPU は Intel(R) Xeon(R) CPU E5645 と認識されますので、x86_errataも関係ありません。
BSD
NetBSD/amd64 on CloudCore VPS (3) 終了編
事実関係は以下の通り。
- 2013年3月15日に再起動を伴うサーバのメンテナンス。一週間前に予告。内容は「仮想環境の再起動に時間がかかってしまう不具合」の解消とのこと。
- メンテナンス後に再起動に失敗。以前使用したISOイメージも起動せず。
- 起動しない症状と同じものを発見。 https://bugs.launchpad.net/qemu/+bug/897771
- 問い合わせたところ、このバグを含むバージョンの qemu-kvm であるとの回答。qemu-kvm-1.1.1 以降では修正されている (http://tima-sls.imag.fr/viewgit/general/?a=commitdiff&p=QEmu&h=cdde6ffc27517bdf069734fbc5693ce2b14edc75) が、導入したホストOSの基本パッケージを使用するため、対応の検討はしないとのこと。
まあ、こちらは動作保証外のことをやってるし、個別にバグ修正を行わないというのもわからなくはないんであきらめるわけですが、「試用して動くことを確認して契約したら違う環境になってしまった」というのは結構困った話なのではないかな。
普通に提供されている環境で使う分には、サポートの返事も早いので悪くはないかと思います。念のため。
これが1年契約の初日とかであればもう少し頑張る可能性もあったのですが、もう3/4は使ったので更新なしで終了かなといったところ。次を探さないと。
build.sh ベンチ
NetBSD 6.0 リリース記念企画（嘘）
build.sh tools は済の状態から build.sh -j ${NCPU} -u -x distribution したときの build.sh started ～ ended までの時間計測大会。
（実際には -T, -O, -X -U あたりも指定してますが略）
Thecus N0503
CPU: Intel Atom N270 1.60GHz (NCPU=2)
Memory: 1GB
Disk: SSD1個でRAIDなし (80GB)
OS: NetBSD 6.0 i386
Time: 11:31:59
Thecus N2800
CPU: Intel Atom D2700 2.13GHz (NCPU=4)
Memory: 2GB
Disk: HDD2個でRAID1 (2TB)
OS: NetBSD 6.0 amd64
Time: 03:05:07
（-j 1 だと 07:13:29）
CloudCore VPS
CPU: AMD Phenom 9550 と表示されるけど KVM 上なので意味なし (NCPU=1)
Memory: 2GB
Disk: virtio上のld (100GB)
OS: NetBSD 6.0 amd64 （+x86_errata無効パッチ）
Time: 03:35:42
Thecus N0503
旧機種のN0503も入手しました。「3.5インチのディスクが3台」または「2.5インチのディスクが5台」も内蔵できます。
これも、CPUがAtomとのことなので普通のPCかと思いきや、VGA出力がない。
PCIスロット（Expressではない）が1つあるので、そこにビデオカードを挿して（あとはUSBキーボード等を繋いで）やると、普通のPCになるようです。手元になぜか未開封（1996年モノ）のMatrox Mystique (PCI) があったので、開封して挿してみたところ動きました。
N0503のマニュアル類に、PCIスロットについての説明がほとんどないですが、背面のフタ（ネジ4本）を外し、その中の外周のネジ8本を外し、前面フタを開けた中の黒いネジ4本（2.5インチ用のケージは外さないと見えない）を外せば、中身が背面から引き抜けます。
N2800と比べた場合、前述の通りディスクが多く積めて良い面もあるものの、旧機種なのでCPUが旧型だったりメモリや内蔵フラッシュが小さいです。CPUはAtom N270なので、64bit非対応。メモリ1GBでフラッシュは128MB。測ってないですが、省電力仕様ではあるかもしれません。
OSを入れ替えたりする用途にはオススメしませんが、一応やればできるということで。
…
Thecus N2800
Thecus N2800を購入しますた。
CPUはIntel Atom D2700でメモリ2GB。HDDは付いてませんが2台まで内蔵可能。LAN端子も2つあるので、家庭用のファイルサーバ兼ルータみたいな使い方がメインでしょうか。
最初から1GBのストレージにLinuxベースのNASのソフトウェアが入っていて、電源とネットワークだけ繋いだ後、他のPCからウェブブラウザで設定するようになっています。
が、それ以外はまったく普通のPCなので、ディスプレイ（アナログ）やらUSBキーボード・マウスやらUSB光学ディスクドライブやらを繋いで他のOSを動かすことも可能です。起動時にF2だったかを押せばよくあるBIOSの設定画面になります。
せっかくのNASのソフトウェアがもったいないですし、PCとしての性能は微妙ですので、Windows動かすとかそういう用途にはお勧めはしませんが。
というわけで（？）、お約束のNetBSDのdmesgなど。
…
NetBSD/amd64 on CloudCore VPS (2)
【追記 2013-03-19】以下は書いた当時の情報であり、2013年3月現在、ここに書いたような方法（x86_errata()の無効化）を用いてもCloudCore VPSでNetBSDは動作しません。
前のエントリを書いた後すぐに、ISOイメージからのbootができるようになりました。
（ただしbetaと書かれています。）
イメージアップロードに関する情報は、VPSのコントロールパネルのOSインストールの項にあります。秘密鍵ファイルのダウンロードもそこにあります。build.shで普通にiso-imageを作成し、NetBSDのsftpで以下のようにアップロードして起動できました。
$ sftp -i 秘密鍵ファイル名 -P 接続先ポート 接続先ユーザ@接続先ホスト sftp> put ISOファイル名 /iso
併せてインストール時にvirtioのオン・オフが選べるようになり、NetBSDをvirtioオンでインストールした場合、ディスクやネットワークがvirtio経由のld, vioifになります。
アクセスの速さは…あまり変わりませんでした。
…
NetBSD/amd64 on CloudCore VPS
【追記 2013-03-19】以下は書いた当時の情報であり、2013年3月現在、ここに書いたような方法（x86_errata()の無効化）を用いてもCloudCore VPSでNetBSDは動作しません。
KDDI Web Communications の CloudCore VPS、最安とまではいかないがそこそこ安いのと（トップにある945円/月は1年契約のときの値段ですが）、「提供予定」に普段使っているNetBSDが入っていたので様子を見ていたところ、
CentOS 5.8/CentOS 6.2/Fedora 16/Scientific Linux 6.2/Ubuntu 12.04 提供開始のお知らせ
なお、かねてよりOSインストール機能の一環にて提供予定としておりました、
「NetBSD」につきましてご報告させていただきます。お客様からのご要望も高く、ご期待に添えるべく技術検証を重ねてまいりましたが、
サービスとして提供できるレベルに至らず、提供を見合わせることとなりました。
ご期待を寄せていただいていたお客様方へは深くお詫び申し上げます。
誠に申し訳ございませんでした。
とまあ、残念なお知らせが載っていたので、雲野コアさんに愛を伝えるべくどういう問題かを把握すべく試用してみました。
Back Street Net（神戸さんのサイト）のさくらVPSの例（とてもわかりやすくて助かります）を参考に if_wm.c にパッチをあてて、イメージを作成。
（VNCコンソールなのでinstallbootのオプション,console=com0,speed=115200は削りました。）
イメージの書き込みは、他のサポートされているOSのインストーラを途中で止めて、ネットワークの設定をしてイメージを転送してddでディスクに書き込むだけなので、特にトリッキーなテクニックを使う必要もなく比較的簡単です。私はFreeBSDのインストーラを使いました。（今後ISOイメージからの起動ができるようになるそうなので、もっと簡単になりそうです。）
すると、…起動に失敗します。
理由は、多分以下のスレッドのものと同じですが、
Current-Users archive: Boot fail as kvm guest
要は、sys/arch/x86/x86/errata.cのx86_errata()でCPUがAMDと判定されるとMSRへのアクセスがありますが、KVM上では通らないという事のようです。今のところ、AMDのCPU以外では何もしないようになっているので、さくらVPS（IntelのCPUに見える）等では問題ないということでしょう。
「KVM上の場合は何もしない」というコードをどう書くのが正しいかわからないので、x86_errata()が何もしないようにソースを直接書き換えて、再度コンパイルしてイメージを作り、さらにACPIとSMPをdisable（起動メニューの4番）したところ起動しました。
一応、インストールした後負荷をかけてみたりしましたが、動いているようです。ただ、「サービスとして提供できるレベルに至らず」という文面が気になるところです。
契約して使うかどうかは迷っています。
何処をどう直すのがスジかという話ですが、KVMとかハイパバイザの類の上でどうせCPU依存の特殊なことはできないのであれば、それらがCPUの種類を隠蔽してくれるのがいい気がしますが、どうでしょうか。
…
binutilsが正しく作れないことがある件
NetBSDでmingw-w64を作っていて、クロスのgccもbinutilsも出来上がったのに、それでコンパイルしたバイナリをWindowsに持っていって実行しようとすると“not a valid WIN32 application”（日本語版だと「有効なWIN32アプリケーションではありません」）などと言われる。
結論から書くと、binutilsのldのldscriptsが正しく作れていなかった。
configureでSHELLとして何故か/bin/shではなく/bin/kshが選ばれるが、このシェルだとgenscripts.sh（から呼ばれているscripttempl/pep.scなど）がエラーになる。
エラーなので止まってくれれば良いのだが、実際にはそのまま進んで、make installすると途中で打ち切られた（実質中身のない）ldscriptsがインストールされてしまう。
出来上がったgcc+binutilsを使ってコンパイルしたときに、一見すると正しいPE32(+) executableに見えるモノが出来てしまうので、なかなか原因がわからなかった。しかし、以前にも、違うパターンとはいえ同じ部分でハマったことがあったのだった。http://est.ceres.ne.jp/2008/07/02/post_241/…すぐに気がつくべきだった。
回避方法としては、binutilsのconfigureを実行する際、CONFIG_SHELL=/bin/sh …/configure …とでもすれば良い。多分。
OpenJDK7 on NetBSD
普通に pkgsrc/lang/openjdk7 動くようになってた。素晴らしい。
$ uname -srm
NetBSD 5.99.24 amd64
$ /usr/pkg/java/openjdk7/bin/java -version
openjdk version "1.7.0-internal"
OpenJDK Runtime Environment (build 1.7.0-internal-pkgsrc_2010_01_23_23_14-b00)
OpenJDK 64-Bit Server VM (build 17.0-b05, mixed mode)手持ちの Java プログラムをいくつか動かしてみたが特に不具合はなし。GUI のあるプログラムは試してないが。
pkgsrc/www/ap2-fcgid
mod_fcgid の socket / shm のファイル作成場所について。
fcgid_conf.c:
#define DEFAULT_SOCKET_PREFIX "logs/fcgidsock"
#define DEFAULT_SHM_PATH "logs/fcgid_shm"で，
config->sockname_prefix =
ap_server_root_relative(p, DEFAULT_SOCKET_PREFIX);
config->shmname_path = ap_server_root_relative(p, DEFAULT_SHM_PATH);なので，apacheもpkgsrcデフォルトのままだとすると，おそらく/usr/pkg/logs/以下になる。
で，標準でそんなディレクトリはないので，
[emerg] (2)No such file or directory: mod_fcgid: Can't create share memory for size %zu byteといったエラーになる。
仕方がないのでhttpd.confなどで明示する。
<IfModule mod_fcgid.c>
AddHandler fcgid-script .fcgi
SocketPath /var/run/fcgidsock
SharememPath /var/run/fcgid_shm
</IfModule>SocketPathで指定するのはディレクトリで，その下にwww権限（apacheの実行権限）でソケットが作られる。
SharememPathの方はファイル名そのもの。root権限で作ってくれるようだ。
検索すると/tmp以下に置いている例もあるが，別にした方が良いと思う。