OpenBSD in Bhyve

巷では、老人による交通事故が後を絶たず、社会問題になっている。免許更新時にボケのスクリーニングの ために、怪しそうな人は医師の診断を受けるように道交法が改正されたとか報じていたな。

そして、年よりの運転免許証返納も推奨されてるようだ。ご褒美に豪華賞品じゃなくて、 足がわりになるタクシー券とかをくれるのが流行みたい。

義母も更新を諦め、返納する事にしたとか。警察へ行ったら、60年にもわたり運転ご苦労様です って言われたとか。運転来歴証明書とかいう、免許証そっくりなものを作ってもらったとか。 これも警察OBの安全協会の大事な収入源だな。なにがしかの手数料を取られたそうだ。

有効期限は、死ぬまでの永久不滅の証明書でございます。身分証明書がわりにどうぞ。 じゃなくて、迷子札だな。住所氏名生年月日は、免許証と一緒で記載されてるけど、連絡先は 無いな。オレオレ詐欺の防止になるように、連絡先はあえて記載してないんだな。

タクシー券は無かったそうだ。町が貧乏だと、年よりを優遇出来ないんだな。まーしょうがない。田舎は疲弊してますから。

買い物は今まで車だったけど、車の代わりにシルバーカーを買ったとか。ちょいと座れるように 椅子風になった手押し車。まあ、いいんじゃないでしょうかね。オイラーの未来を見ている ようで、大変参考になりました。

いやいや、後10年もすれば、人工知能搭載の、寝ててもスーパーへ連れてって車が出てくるに 違いない。期待してまっせ。

bhyve

前回は、CentOSでqemu-kvmって言うのをやったけど、それのFreeBSD版であるbhyveをやって みる。こんな記事も出てたしね。 OpenBSD 6.1-RELEASEをbhyveにインストール

この記事によると、OpenBSDにsyspatchなんてのが入ったようだ。ちょいとmanを覗いてみたぞ。

NAME
     syspatch - manage base system binary patches

SYNOPSIS
     syspatch [-c | -l | -r]

SEE ALSO
     signify(1), installurl(5), release(8)

話がそれた。こういう記事も出てた。 FreeBSD bhyve + vm-bhyveでゲストにFreeBSD環境を入れてみる そして、オイラーも以前やってたね。 (協力、強力) OpenBSD in FreeBSD FreeBSDのハンドブックには、 21.7. FreeBSD as a Host with bhyveなんて言う説明も有ったよ。

CentOSの時は、OpenBSDのダイエットに失敗して頓死してしまったので、今回は、 慎重に事を進めた。dmesgで現状を知り、 man -s 4 intro あたりを眺めながらね。 で、その成果。モノリシックカーネルだと、最大公約数的なドライバーが内蔵されてて、 どんなPCでも起動出来る事を目指してる。それに対して不要なドライバーを削除してく。

頑張って、OSの機能(例えば、使わないであろう、IPv6等)を省いていけば、更に ダイエット出来る事は知ってるけど、今回はそこには手を付けていない。

$ ls -l /bsd /obsd
-rw-r--r--  1 root  wheel   4965168 May 11 14:06 /bsd
-rw-r--r--  1 root  wheel  10683954 May 10 06:11 /obsd

何がダイエットに利いてるかというと、NICとUSB関係をばっさり切り捨て。DRMという Direct Rendering Manager deviceも削除。画像関係は、今の所bhyveではサポート されてないからね。(frame-bufferを使って、vncに表示を持ってく事は可能)後は、ddbの関係も止めて、排他の関係にあるkgdbを選んだのさ。

com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com0: console
com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
com1: kgdb

おかげで、kgdbをつつく口が開いてますよ。これはもう、FreeBSD側からgdbしろって事だな。

gdbでつつく

問題は、FreeBSD側で、どうやってシリアルポートの口を確保するかだな。 bhyveのマニュアルを読むと、

           bhyve -c 4 \
             -s 0,amd_hostbridge -s 1,lpc \
                 :
             -s 2,ahci-cd,/images/install.iso \
             -s 3,virtio-net,tap0 \
             -l com1,/dev/nmdm0A \
             -A -H -P -m 8G

こんな例が出てる。/dev/nmdm0Aなんて言う、怪しいデバイスが使われていた。manで 調べてみると、シリアルケーブル相当品らしい。これを使って、Host側のFreeBSDと ゲスト側のOpenBSDをシリアルケーブル接続するとな。で、詳細は、ハンドブックを 見て、見よう見まねしたのさ。

kldloadで、nmdmをロード。そいつはrootしか使用を許していないので、

[fb11: kern]$ cat /etc/devfs.conf
 :
perm    nmdm0A  0660
perm    nmdm0B  0660

wheelユーザーも使えるようにしておく。OpenBSD起動スクリプトは、下記のようにした。

sudo bhyvectl --destroy --vm=OB61;
 printf "kopenbsd -h com0 -r sd0a (hd0,openbsd1)/bsd\nboot\n" |
sudo grub-bhyve -m d.map -M 256M OB61;
sudo bhyve -W -c 1 -m 256M -H -P -A  \
  -l com1,stdio \
  -l com2,/dev/nmdm0A \
  -s 0:0,hostbridge \
  -s 1:0,lpc \
  -s 2:0,virtio-net,tap0 \
  -s 3,virtio-blk,./ob61.img OB61;
sudo bhyvectl --destroy --vm=OB61

これで、com2の口が、ケーブルの一端に接続される。後は、FreeBSD側で、gdbを 起動だな。

[fb11: DEBUG]$ gdb -q bsd.gdb
(gdb) target remote /dev/nmdm0B
Remote debugging using /dev/nmdm0B
Ignoring packet error, continuing...
Couldn't establish connection to remote target
Malformed response to offset query, timeout

もう一端のケーブルを指定して接続。返事が無い! と思ったら、

$ kgdb waiting...Failed to emulate instruction [0x55 0x48 0x89 0xe5 0x48 0x83 0xec 0x40 0x89 0x7d 0xcc 0x48 0xc7 0x45 0xe8] at 0xffffffff812e4d8d
                                                                 Abort trap

反対側が死んで、bhyve.coreが出来ていたので、検視。

(gdb) bt
#0  0x000000080119755a in thr_kill () from /lib/libc.so.7
#1  0x000000080119752b in raise () from /lib/libc.so.7
#2  0x0000000801197499 in abort () from /lib/libc.so.7
#3  0x000000000040affc in vm_loop ()
#4  0x0000000000409e81 in fbsdrun_start_thread ()
#5  0x0000000800eb1b55 in pthread_create () from /lib/libthr.so.3
#6  0x0000000000000000 in ?? ()

死因不明社会。詳細は、FreeBSDのコアチームをコアを送ればいいのかな?

gdbでの接続を諦めて、ddbを使うように設定したら、com1がkgdbから解放されて 自由になってた。dmesgで認識状況が確認出来るって良い事だ。その点、リナときたら,,,(以下、自粛)

com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com0: console
com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo

折角なので、モデムケーブルのチェックを兼ねて、com1からシリアルでログインしてみる。/etc/ttysの tty01をonにする。そして、kill -HUP 1 で、initプロセスの再読み込みを行う。

tty00   "/usr/libexec/getty std.9600"   vt220    on secure
tty01   "/usr/libexec/getty std.9600"   vt220   on  secure
tty02   "/usr/libexec/getty std.9600"   unknown off
tty03   "/usr/libexec/getty std.9600"   unknown off

FreeBSD側から、端末ソフトで、モデムケーブルのもう一端に接続する。

[fb11: ~]$ cu -l /dev/nmdm0B
Connected

OpenBSD/amd64 (ob61.localdomain) (tty01)

RETを叩くと、ちゃんと応答して、login出来たよ。端末の終了は、~-. だな。

tag jump

前回見つけた資料を読んでいたら、kernelのソース内をスイスイ飛び回る仕掛けが用意 されてる事を知った。曰く、cd /sys/arch/amd64; make tags して、tagsファイルを作って おくって方法。

実際にやってみたら、vi用のtagsが作成された。オイラーの指はemacs用にカスタマイズ されてるんだけどな。vi用からemacs用にtagsファイルを変換出来ないものかしらん? こういうのは、先生に聞いてみるに限る。

紹介されたのは、 BuildTags な方法。tagを作るctagsコマンドに、-e オプションを付けると、emacs用になるとの事。

OpenBSDには、ctagsが入っていた。(emacsが引き連れてきたんだな。)それで、やって みると、そんなオプション知らねっていうつれない返事。

急遽、 ExuberantCtags をインストールしたよ。

そして、Makefileをちょいと書き換える。

$ diff -u Makefile zz
--- Makefile 
+++ zz  
@@ -8,7 +8,7 @@
 KFILE= GENERIC.MP
 .endif
 TDIRS= ${_arch} include pci isa
-TAGS=  ${.CURDIR}/tags
+TAGS=  ${.CURDIR}/TAGS

 NOPROG=
 NOMAN=
@@ -34,12 +34,7 @@
        eval "SFILES=\"`make -V SFILES -f $${TDIR}/Makefile`\"" && \
        eval "CFILES=\"`make -V CFILES -f $${TDIR}/Makefile`\"" && \
        eval "AFILES=\"`make -V AFILES -f $${TDIR}/Makefile`\"" && \
-       ctags -wd -f ${TAGS} $${CFILES} $${HFILES} && \
-       egrep "^[_A-Z]*ENTRY[_A-Z]*\(.*\)" $${SFILES} $${AFILES} | \
-           sed "s;\\([^:]*\\):\\([^(]*\\)(\\([^, )]*\\)\\(.*\\);\\3    \\1     /^\\2(\\3\\4$$/;" \
-           >> ${TAGS} && \
-       sort -o ${TAGS} ${TAGS} && \
-       rm -rf $${TDIR}
+       /usr/local/bin/ctags -e -w -f ${TAGS} $${CFILES} $${HFILES}

 links:
        -for i in conf ${TDIRS}; do \

そして、急ごしらえのmakeを走らせて、TAGSを作成。

# make -f zz tags
  :
$ wc TAGS
  254387  842405 14745448 TAGS

こんな巨大なTAGSファイルが作成された。emacsでjumpしようとしると、大きいけど 開いていいかって聞いてくるぞ。

M-. main すると、/usr/src/sys/dev/videomode/vesagtf.c なんてファイルは無いと 言ってきた。ああ、正式なOpenBSD環境(VBOXに入れたやつ)で作ったTAGSなんで、FreeBSDの home下にあるのとソースの場所が違うのね。これはもう、TAGSを書き換えるしかないな。

[fb11: amd64]$ sed -i -e 's!/usr/src!/home/sakae/ob61!' TAGS

して、変更したよ。で、下記のように画面が割れて、どれか選べと言ってきた。フォーカスを 選択画面に移して、適当な行番号にカーソルを移動し、そこでRETを叩くと、目的の所へ 飛んで行ってくれた。カーネルのmainって、init_main.cで定義されてるんだね。

他にもmainが有るな。これってkernel内に別アプリが同居してるって扱いなんだな。 ならば、OSが起動した時に、迷わずinit_main.c内のmainが選ばれるってのは、どういう 仕組み? この辺から追って行くのが定番だな。

/home/sakae/ob61/sys/dev/videomode/vesagtf.c
683: main (int argc, char *argv[])
/home/sakae/ob61/sys/ddb/db_dwarf.c
427: main(int argc, char *argv[])
/home/sakae/ob61/sys/kern/init_main.c
188: main(void *framep)
/home/sakae/ob61/sys/dev/pci/if_ipwvar.h
23:     u_char  *main;
/home/sakae/ob61/sys/dev/pci/if_iwnvar.h
157:    struct iwn_fw_part      main;
/home/sakae/ob61/sys/dev/pci/if_wpivar.h
127:    struct wpi_fw_part      main;

気を良くしたオイラーは、CentOS内に置いてあるソースでもタグジャンプしようとしたんだ。 変更したTAGSを配信するだけだからね。

そしたら、上のようなとび先リストが出てこないで、リスト上の一番最初の所へ飛んで行った。 これって、emacs君の不都合な真実だな。(と、アル・ゴア元副大統領風な発言) この違いが、emacsのバージョン違いかな。FreeBSDは、

[fb11: amd64]$ emacs -version
GNU Emacs 25.1.1

対して、CentOSに潜むemacsは、

[cent amd64]$ emacs -version
GNU Emacs 24.3.1

まてまて、emacsの違いと言うより、progmodes/etags.elの違いかな? 比べてみると、 新しい方は、xrefなんてのを呼んでた。これで、リストを出しているのかな?

PHP開発のためのEmacs 2016 (pixiv <3 Emacs)によると、オイラーの見立ては当たっていたね。etags.elを新しいのに取り替えて おこうと思ったんだけど、24.3の方には、xrefが来ていなかったので、諦めた。(調和を乱す のは、大和の人の嫌いな事です)諦めて、C-u M-. で、我慢しましょ。

tag jump for vi

もしものためと思って、viでタグジャンプをどうやるか調べておく。先生に聞いてみても、vim での解説しか出てこない。やっぱりmanに聞くのが一番ね。以下、FreeBSD調べだ。

:tag! fork1

こんな風に、取っ掛かりで、飛んで行きたい所を指示するか、カーソルを合わせて、C-] で、 目的地へ移動する。元居た所へ戻るには、C-t する。

なお、オイラーはscreenを使ってるんだけど、それのキープレフィクスに、C-t を割り当て てるんで、C-t の打鍵は、screenが食べちゃって、viに到達しない。もう一回打鍵すると、 screenは諦めてviに打鍵を届けてくれる。(都合、2回、C-t するはめになる。)

こんな事なら、tmuxでも使うか。あちらのプレフィックスは、確か C-b だったはずだからね。

ついでに、CentOS備え付けのviでも調べてみたよ。FreeBSDと同様の指使いでいけた。 Centのviは、実態がvimだった。何のプラグインも入れてないので、シンタックス・ハイライトも 効かず、viでソースなんて見るものじゃないと言う当たりまえの結論に落ち着いたよ。

vmrun

こんな便利スクリプトが用意されてた。bhyve使いなユーザーには嬉しい礼です。

[fb11: tmp]$ cd /usr/share/examples/bhyve/
[fb11: bhyve]$ sudo sh vmrun.sh -h
Usage: vmrun.sh [-ahi] [-c <CPUs>] [-C <console>] [-d <disk file>]
                [-e <name=value>] [-g <gdbport> ] [-H <directory>]
                [-I <location of installation iso>] [-l <loader>]
                [-m <memsize>] [-t <tapdev>] <vmname>

       -h: display this help message
       -a: force memory mapped local APIC access
       -c: number of virtual cpus (default is 2)
       -C: console device (default is stdio)
       -d: virtio diskdev file (default is ./diskdev)
       -e: set FreeBSD loader environment variable
       -g: listen for connection from kgdb at <gdbport>
       -H: host filesystem to export to the loader
       -i: force boot of the Installation CDROM image
       -I: Installation CDROM image location (default is ./release.iso)
       -l: the OS loader to use (default is /boot/userboot.so)
       -m: memory size (default is 512M)
       -p: pass-through a host PCI device at bus/slot/func (e.g. 10/0/0)
       -t: tap device for virtio-net (default is tap0)

BHyVeお手軽スクリプト

BHyVeあれこれ

2.2.3 操作

tmux

OpenBSDにはデフォでtmuxが入ってるのね。あの人も認めた優れもの。screenから乗り換えて みるかな。

今まで、OpneBSDでもscreenを使っていたんだけど、こやつを起動したままshutdownすると core吐いちゃう事が有ったからね。

FreeBSDはどうかと思って調べたら、両者とも入っていませんでした。どちらもCUIの時に 使って便利なもの。(ssh時も重宝するか)Windows10になって、やっと仮想スクリーンが 搭載されたようだけど、OpenBSDのtmuxは何時の頃から標準になっていたんだろう? こういう歴史ものにプチ興味が有るな。

よく使うtmuxコマンド/設定ファイル

を見ればいいのかな?

あれれ、VBOXに入れてるOpenBSDで、2つのCPUが有効にならないぞ。どゆ事?

Windows 10 upgrade

と言うんでしょうかね? 巷で騒いでいるアップデートが、我が家にもやって来た。

時間がかかるから覚悟せいという脅しがあって、やむにやまれぬ実行。 ええ、その間に散歩に行きましたよ。帰ってきたらログイン画面になってた。この間、1時間 ぐらいでしょうかね。ログインすると、もう少し時間がかかると言われて待たされた。

被害は、キーボードのCapsLockをControlへ割り当てているレジストリィーがクリア されちゃった事と、マウスパッドを殺していたのに生き返っていた事。

全く面倒なこっちゃ。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layout
Scancode Map
00 00 00 00 00 00 00 00
02 00 00 00 1d 00 3a 00
00 00 00 00

regEdit を起動し、該当箇所に移動して、編集ー新規ーバイナリー値を選び、名前に Scancode Map を選んで、データを入力。saveしたら、再起動。

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layout]
"Scancode Map"=hex:00,00,00,00,00,00,00,00,02,00,00,00,1d,00,3a,00,00,00,00,00

マウスの方は、関連をクリックして、ThinkPadを選んで、タッチパッドを使用するをOFFにする。

これから、10回ぐらいはやりそうだな。