かけまわる子犬。

ThinkPad X13 AMD で利用する FreeBSD。

7月 152020

さてと。前回のエントリは ThinkPad X13 の AMD 版が納品されて、簡単なファースト・インプレッションを行いました。
僕はそもそも NotePC で Windows10 を利用することはあまりないので、ベンチマークとか全然できないのであります。なので、詳細な検証などはまるで皆無。参考にならない記事ですなf(^^;;。

と、いうことで、今回は出たばかりの最新鋭の NotePC に FreeBSD をインストールしてみます。色々と問題点があるのだろうなぁ。とは思うのでありますが、れっつとらい。

1. FreeBSD のインストール準備
今回チョイスした FreeBSD のバージョンは FreeBSD/amd64 12.1-RELEASE と、いうリリースされている標準的なバージョンです。このバージョンが、最新鋭の NotePC にインストールしてどこまで動作するのか確認してみたいと思います。

インストールの作業手順は以下のとおりです。

0).Windows10 の回復 USB の作成
1).Windows10 のパーティションの縮小
2).FreeBSD 用 UEF パーティションの確保
3).FreeBSD のインストール
4).bcdedit でブートメニューの登録

このうちのほとんどの作業は以前「ThinkPad E145 を UEFI ブートに変えてみた。」といえエントリに書いているのでサクっと省略します。実際に僕もこの手順で問題なくインストールできましたので、そちらを参考にして頂ければと思います。

ただ、今回は最新鋭の NotePC で、今まで利用していた ThinkPad e145 と比べて最新技術が導入されています。

気を付けたのは以下の点。

BitLocker が default で導入されている
UEFI (BIOS) の設定画面で「レガシー BIOS」(CSM のことですね) がどうも見当たらない

この二つをなんとか回避する必要があります。

2. BitLocker の解除
「コントロールパネル」から「BitLocker ドライブ暗号化」メニューを覗いても無効にはできませんでした。ただし、この画面から BitLocker のキーを取得しておきましょう。
BitLocker を解除するのは「設定」アプリの [更新とセキュリティ] の中にあります。ここからまず、 BitLocker を無効にします。

最初から入っている OS 以外をインストールするとき EFI セットアップメニュー (BIOS 画面) で「セキュアブート」を無効にする必要があるのですが、 BitLocker を有効にしたままセキュアブートをオフにすると青い画面が現れて何やらキーを入力するように要求されてしまい『むむむ。』などと思ってしまうのであります。

と、いうことで、新しい OS をインストールするためには、

・BitLocker を無効にする
・セキュアブートをオフにする

以上の二つが必要です。

3.「レガシー BIOS」の設定画面が見当たらない
もしかしたら EFI セットアップメニュー内にあるのかもしれません。が、しかし、僕は見つけられませんでした。と、いうか、もう FreeBSDのインストール時には「レガシー BIOS」の設定の有無は不要です。

ThinkPad e145 を UEFI で利用する設定を投入したときに FreeBSD のインストール用 USB メモリを Rufus で作成した。と、書いています。 Rufus で FreeBSD のブート USB イメージを作成するときは MBR で起動する USB ブートイメージしか作れない。と、書いているのですが、実は FreeBSD の 12.1-RELEASE のインストールイメージは UEFI+GPT に対応しているんですね。

Rufus を利用して UEFI 対応の FreeBSD の USB ブートイメージを作成する場合 ALT+E を押すことにより BIOS+MBR にするか UEFI+GPT にするか選択できます。

なので、「レガシー BIOS」をオンにせずとも UEFI モードのままで FreeBSD をインストールすることができるのであります。

4.FreeBSDのインストール
EFI セットアップメニューで変更するのはセキュアブート “オフ” のみで FreeBSD のインストールが可能になりました。

と、いうことで、あとは FreeBSD をインストールするのみです。途中パーティションの設定の所では、 [Auto] を設定すると、SSD の全領域を対象としてしまうので、ここは [Manual] で、必要な領域を確保するようにします。

インストールが完了したあとは Windows10 が起動するので bcdedit で Firmware Windows Boot Manager に FreeBSD がブートするように登録してあげてインストール作業は終了です。

5.いよいよ FreeBSD の起動。しかし NIC は？
まず、必要なのにデバイス的に動かないもの。あ、今回は一発目のインストールなので 12.1-RELEASE になります。あまりにも動かないようであれば CURRENT に移行するか。などと思っていますが。

WiFi6 AX200
Ryzen7 Radeon Vega10

この二つは結構痛い・・。orz
順番に話して行きます。

そもそも pciconf -lv すると none のデバイスが 8 個もあります。orz

・pciconf -lvの結果

vmm.ko を kldload するとか、仮想 OS 用のブリッジ・RealTek のデバイス・AMD のマルチメディア系デバイスなどが認識していません。

Intel の WiFi6 対応の AX200 は調べてみたところ OpenBSD のほうでは if_ixw と、いうドライバが書かれているみたいですが、 FreeBSD はまだ未対応のようです。 if_iwm.ko でも動作しません。

ThinkPad X13 の内臓 re0 を利用するためのアダプタを購入してないので USB WiFi や USB NIC を利用しようと思いましたが・・。それにしても最近の FeeeBSD の USB NIC はボロボロですな・・。RealTek の WiFi NIC ドライバ if_urtw.ko は 802.11a 対応したチップをマージしたら速度が全く出ないし、 if_axge.ko は ue0 の 1Gbps で接続する JR45 の NIC なのに、こいつは ping の損失率は 60% 前後。もう、悲惨というほかない・・。

ショーがないので WiFi の場合は if_run.ko を利用し RJ45 NIC の場合は if_axe.ko を利用する。と、いう状態・・。orz

6.Xorg 動く？
Ryzen7 Radeon Vega10 はディスプレイ用のチップですが ports から graphics/drm-fbsd12.0-kmod/ をインストールして

kld_list="/boot/modules/amdgpu.ko "/boot/modules/radeonkms.ko"

を書いても認識されませんでした。

/dev/dri/Card0 が生成されないので OS 的にも認識されていません。

まぁ、この際 amdgpu.ko をきっぱりと諦めて vesa ドライバで Xorg が起動してみようと試みるもダメ・・。あらまぁ。

[ 71220.842] (II) VESA(0): initializing int10
[ 71220.843] (EE) VESA(0): V_BIOS address 0x0 out of range
[ 71220.843] (II) UnloadModule: "vesa"
[ 71220.843] (II) UnloadSubModule: "int10"
[ 71220.843] (II) Unloading int10
[ 71220.843] (II) UnloadSubModule: "vbe"
[ 71220.843] (II) Unloading vbe
[ 71220.843] (EE) Screen(s) found, but none have a usable configuration.
[ 71220.843] (EE) 
Fatal server error:
[ 71220.843] (EE) no screens found(EE) 
[ 71220.843] (EE) 
Please consult the The X.Org Foundation support 
         at http://wiki.x.org
 for help. 
[ 71220.843] (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information.
[ 71220.843] (EE) 
[ 71220.844] (EE) Server terminated with error (1). Closing log file.

vesa ドライバを利用した場合はこんな感じのログが出力されます。

それなら最後の手段だ。と、いうことで scfb で試してみたところ、一応 Xorg の画面は現れました。が、 xrandr で対応する画面サイズを確認してみると・・。

# xrandr 
xrandr: Failed to get size of gamma for output default
Screen 0: minimum 640 x 480, current 640 x 480, maximum 640 x 480
default connected 640x480+0+0 0mm x 0mm
   640x480        0.00*

orz。

しかし、scfs ドライバというのは UEFI と密接に関連いているようですね。 xorg.conf でディスプレイサイズを変更するのではなく UEFI 用のコマンドが用意されていて、 OS 起動時の画面サイズを調整してから、そのサイズを scfb ドライバが読み取って画面サイズが決定されるようです。

FreeBSD の起動時に OS ブートのメニューが表示されますが、そこで 3 を押して OK プロンプトを出します。

表示された OK プロンプトで gop コマンドを打ちます。 GOP とは Graphics Output Protocol のことらしいです。オプションは list (選択枝の表示) get (現在の設定情報の取得) set (新しい設定を指定) の三つ。

OK プロンプトから gop list と打つとディスプレイが対応しているサイズの一覧が表示されます。そこて gop set 0 などと打ち、使いたいサイズの番号を打ちます。

すると、コンソールが中央付近に小さくなって表示されます。そこの OK プロンプトで boot と打つと指定した画面の大きさで FreeBSD がブートします。くれぐれも reboot とは打たないように;-)。
OS の起動後にすかさず startx と叩くと、さっきまで 640×480 でしか表示してくれなかった scfb ドライバが大画面で表示できるようになります。

ちなみに ThinkPad X13 AMD は色々なサイズがあったのですが、実質的に 640×480 か 1920×1080 の二つのサイズしか表示できませんでした。

なお、 /boot/loader.rc に gop set で指定したモードの番号を記載することにより毎回 OK プロンプトで設定する必要がなくなるらしいのですが、それはちょっとバグがあるみたいで正しく動作しないようです。
では、どうするか？と、いうと /boot/loader.conf に exec=”gop set 0″ と、コマンドイメージそのままを書くと良いです。

これで Xorg が無事に起動したので、ずいぶんと利便性がアップしました;-)。いやぁ。良かった。
あと、 NotePC のスペックが非常に高いので scfb ドライバでもその遅さがあまり気になりません。これは非常にラッキーです;-)。

7.Suspend/Resume するの？
以前、今回の ThinkPad X13 AMD を購入する前に FreeBSD の偉い人が既に ThinkPad X1 を持っていたのでその人に「Suspend/Resume します？」って、聞いたら「興味ない。」と、つれない返事。あらま。

では、ThinkPad X13 AMD が届いてから確認すれば良いやぁ。などと思ったのですが、今回はその検証を。

まず、何はなくとも zzz と打ってみると、一応は寝てくれました。しかし、電源を投入すると、 OS が起動して来て fsck が走ります。あらら・・。

試しに以下のコマンドを打ってみます。

# sysctl hw.acpi.supported_sleep_state
hw.acpi.supported_sleep_state: S4 S5

うひょー。 S3 ステートがないじゃーーん。 orz
なるほど。これが原因で「興味ない。」と、コメントが返ってきたんだな。と、一人で納得。

本当に S3 ステートが無いのか？とウェブで探し回ったことろ、以下の URL にぶち当たりました。

Lenovo ThinkPad X1 Carbon (Gen 6)

最近の ThinkPad には BIOS レベルで S3 ステートがなく、かわりに s0i3 スリープというのがあるらしい。では s0i3 スリープとはなんぞや？と、思い調べてみると Windows10 もしくは Microsoft 『モダンスタンバイ』というモノらしく OS べったりなスリープモードらしいです。

これを FreeBSD 側、上記 URL では『Linux 側』で利用するには ACPI の DSDT を書き換える必要がります。まぁ、過去に何回か書き換えたことがあるのでどーにかなるだろう。などと思いつつも EFI セットアップメニューを眺めていたらなんとっ!!

ThinkPad X13 AMD はスリープステートを EFI セットアップメニューから切り替えられるようになっておりました。

[Windows 10] にすると「モダンスタンバイ」になって [Linux] にすると今までどおり S3 ステートになります。 [Linux] に変更したあとに上記 hw.acpi.supported_sleep_state を確認すると S3 S4 S5 と、 S3 が生えてまいりました;-)。

と、いうことで準備が整ったので再度 zzz と打ちます。 Suspend は割と素直に寝てくれます。フタを閉じて再度開けると、画面はブラックアウトです。しかし、 USB WiFi がピカピカ光っているのでカーネル自体は起き上がったようです。

しばらく待って ping の疎通確認したら目覚めていました。 ssh したらログインできました。無事に Suspend/Resume 自体は動作しているようですが、画面は真っ暗なまま。まぁ、まだ Xorg 動き始めたばかりなのでなんとも言えないですが、コンソール周りの vt や Xorg 次第で画面が復活するかな？などと安直に思っています。

ちなみに、相変わらず acpi_video.ko はまともに動作せず sysctl の hw.acpi.reset_video mib を 1 にするとカーネルが凍りつくのは ThinkPad e145 と一緒ですね。

8.その他
画面の明るさ変更についてですが、上にも書いた通り acpi_video.ko がまともに動かないので sysctl の hw.acpi.video.lcd0.brightness mib などが使い物になりません。

これまた、画面の明るさについては Xorg が動いたら本格的にいじっていきたいです。

あと、まださわりだけですが、イヤホンジャックから音が出ません。 /dev/sendstat 見ると色々デバイスはあるみたいですが sysctl hw.snd.default_unit で切り替えてもヘッドホン端子にさしたイヤホンで音が出ていません。

pciconf -lv で AMD マルチメディアチップが none8 になっていたのでその辺りが影響しているのかな？

9.で、結局？
しかし、普段から NotePC で FreeBSD を利用しているので Windows10 では PC のスペックに対してその速さをあまり体験できなかったのですが FreeBSD をブートするとその性能が体感できますね。起動がむちゃくちゃ速い。 KDE5 も sddm からログインしたらサクっとデスクトップが表示されるし、 Firefox の起動もむちゃくちゃ速い。『いやぁー。速い NotePC は中々良いねぇ。』と、なるのであります;-)。

そして、ですが FreeBSD/amd 12.1-RELEASE では結局、以下が動きませんでした。

WiFi の AX200 が動作しない
Radeon Vega10 が amdgpu.ko で認識しない
S3 ステートは利用可能だが Suspend して Resume 後は画面がブラックアウト
画面の明るさは変更できない
音声出力がイヤホンジャックに切り替えられない

こんな感じでしょうか。Radeon Vega10 が graphics/drm-devel-kmod/ な ports で動作するのか確認したいところではありますが、そーすると OS 自体を CURRENT に上げる必要があります。

上記の状態を鑑みると CURRENT を試してみる価値ば十分にあるのかなぁ？などと、思っている次第ではあります・・。

が、このネタ、もう一回続くかも。

Lenovo Thinkpad X13 AMD が届いた。

7月 122020

いやぁ。久しぶりに NotePC を新調しました。以前購入し、今でも現役なのは ThinkPad Edge e145 ですが、それ以来です。で、ThinkPad e145 はいつ購入したの？と、いうとなんとっ!! 2013/11 なのですねぇ。
ThunkPad e145 は、最近はディスプレイのヒンジを固定しているプラスチックが砕け散って液晶ディスプレイの開け閉じに支障が出ていたのでありました。

長く使うとプラスチックというのは壊れてきますねぇ。まぁ、長く使いすぎた。と、いう話もあるかと思いますが;-)。

と、いうことで、今回購入した ThinkPad を含めて、僕の使った歴代の ThinkPad を並べてみました。

ThinkPad 535E -> (途中 DELL とか購入) -> ThinkPad X100e -> ThinkPad e145 -> ThinkPad X13

ThinkPad X100e からずっと AMD の CPU を利用したモノを購入しており、今回の X13 も当然 AMD な CPU 版をチョイスです。実は ThinkPad X395 を買おうかと悩んでいたところに『 ThinkPad X13 は新しい Ryzen で登場予定っ!!』とのことだったので待って待って待って、ようやっと購入しました。

それにしても、購入した歴代の ThinkPad で 10 万 yen を超えたのは今回が初めてです・・f(^^;;。 AMD CPU は安さが魅力ですからね。そして、ThinkPad の看板でもある X シリーズを購入したのも今回が初めて。なるほど 10 万 yen 突破するわけだぁー。

ウェブから申し込んだのが発売日の 2020/06/05 。その後、カードで引き落としできず結局銀行振込にして 5 日ほど無駄な日々を過ごし、納品されたのが 2020/07/07 でした。大体約一ヶ月ですね。
ThinkPad e145 と同じくらいでしょうか。

あ。カードで引き落としができなかった件ですが、僕は macOS の Safari で Lenovo のポームページを見て購入しました。最後のカード番号を入力するところで画面が動作的に壊れてしまいカード番号を入れたんだけど、うまく Lenovo 側に伝わっておらず「このカードは利用できません。」となっているそうでした。

macOS の Safari と、あと AD Block が悪さしているかもしれません。 macOS でカードで購入しようとしている方は Safari ではない別のブラウザを利用したほうが良いかもです。
僕の場合は Microsoft Edge を利用し、 AD Block をオフにしました。が、それでもダメで、諦めて、サポートの人にメールで振込先口座番号を聞いて、銀行振り込みにしました。

それでは使用感。ファースト・インプレッションをば。

まず、箱から取り出しての感想。『でかいっ!!』フツーの ThinkPad って、こんなにでかいのか？と、愕然。まぁ、 X100e も e145 もこぢんまりとした機種でありましたから、それと比較すると、ずいぶんと大きく感じます。

あと、排気熱がすごいっ!! 筐体の右側にダクトがあるのですが、この辺りって外付けマウスを利用する場所なんでよ。気がつくと、マウスを握っている親指に熱風が降り注いている・・。いやぁ。気をつけないと・・。

・default は Windows10 バージョン 1909
Windows10 バージョン 1909 をインストール直後から初期設定するのは初めてだったのですが、インストール時にコルタナが登場して音声で設定することができます。「次へ」とか口に出して言うとマウス操作が必要なかったりとか。

あと Windows10 バージョン 1909 で驚いたのはローカルユーザで利用できません。 Microsoft アカウントが必要です。
新規に作るか、既存アカウントでログインすることになります。ただ、回避策があるようで、初期の段階でネットワークに接続しないとローカルアカウントを作成することができるようです。

僕の場合は、一旦 Microsoft アカウントでログインしたあと、ダミーのローカルユーザをなんとか作成して、ローカルユーザでログインし直して、Windows10 上の Microsoft アカウントを削除して、ローカルユーザを Microsoft カウントに結びつけました。

ローカルユーザを作成するときのキャプチャを掲載しておきます。

「設定」アプリ -> [アカウント] -> [家族とその他のユーザー] -> [その他のユーザーをこのPCに追加]

ここで、ウィンドが開きます。そして

[このユーザーのサインイン情報がありません] -> [Microsoftアカウントを持たないユーザを追加する]

これでローカルユーザなアカウントが作成できます。

・Windows10 な NotePC で使う 8 コア 16 スレッドって、あまり意味を感じられないのですが・・f(^^;;。あ。今回購入した ThinkPad X13 AMD のスペックは以下の通りです。

CPU: Ryzen 7 PRO 4750U 8 コア/ 16 スレッド
メモリ: 16GB DDR4 3200MHz
SSD: 1TB M.2 2280 PCIe-NVMe
NIC: Wi-Fi 6 AX200 (RJ45 アダプタ購入せず)
ディスプレイ: 1920×1080 IPS・マルチタッチ非対応
その他: 指紋認証・WLAN・キーボードバックライト無し

以前購入し、デスクトップとして利用している Mac mini に続き 8 コア/ 16スレッドな CPU です。AMD では初です;-)。
SSD は奮発しました。512MB から 1TB へは増量キャンペーンで +9,900yen だったので飛びつきました。どうせ FreeBSD もインストールするだろうしみたいな。

その代わり、要らないのを思う存分削ぎ落とした。と、いう感じでしょうか。 Windows10 を利用していると指紋認証あると便利だろうけと、 FreeBSD で利用した場合は必要ないし、キーボードのバックライトで ACPI 周りを悩みたくないし。みたいな。

Windows10 ってあまり使い込んだとこないのですが、8 コア/ 16スレッドな PC って、恩恵受けられるのかぁ？

Windows10 側は普段必要なモノをインストールして、WLS と ubuntu をインストールして MobaXterm をインストールした段階で、一応 UNIX 風環境が整ってしまうので、それで『はい。シューリョー。』となってしまうんですよね。

そーそー。Windows10 って、Microcoft アカウントを利用していると、他の PC の情報を新しい PC に引き継いでくれるんですね。例えば Ctrl2Cap を使って Ctrl と CapLock を入れ替えていると、新しい PC でもその情報が反映されます。あと、同じように XMouseSetting ですね。こちらは X-window みたいにマウスオーバーによる Auto Rize の機能を設定していると、その設定も引き継いでくれました。手間を省略できたのが嬉しいし、素晴らしいですねぇ。

PC の速さには問題ない状況です。しばらく使い込んで、その後 FreeBSD をインストールする予定ですが、それは次のネタとして取っておきます;-)。

実は上の写真。 ThinkPadX 13 AMD で、もう FreeBSD/amd64 12.1-RELEASE が動いていたりします;-)。

詳細については次回を待て;-)。

Rakuten Monile の SIM カードが届いた。

2月 162020

楽天モバイルが「無料サポータープログラム」の参加者募集したとき、すぐに応募したのだけど見事に落選。今回二次募集があり、一次募集で漏れた人が優先的に二次募集に参加できる。と、いうのでメールが届き、早速アクセスしてクーポンコードを入力したら、SIM カード発送準備ができて、 02/02 の午前中に届いた。うひひ。

僕は以前に OPPO Reno A を購入していたので、今回の適合機種であろうということで、 SIM カードのみを申し込んだ状態です。

届いたモノはこんな感じ。

でもって、早速 OPPO Reno A に Rakuten Mobile の SIM カードを入れてみると、特にバージョンアップや APN を設定することもなく、サクっと認識し、LTE での通信が可能な状態となりました。
僕の OPPO Reno A は楽天モバイルで購入したものではなく、フツーに購入した 64GB 版で、楽天モバイル専用の 128GB 版ではないのですが、同じ機種だからでしょうかね。サクっと苦労せずに動作しました。楽ちんでした;-)。

LTE の動作確認と、電話の動作確認を実施しましたが、特に問題はありませんでした。

と、いうことで楽天推奨のアプリを二つインストールしました。

o. 楽天 Link アプリ
こっちは、電話や SMS などがひとまとめになったアプリで、一個のアプリでコミュニケーションが取れるようになっています。まぁ、まとまっていると楽かな。メニューアイコンを何個も並べる必要はないのでね。

o. 楽天モバイルアプリ
こっちは、何ギガ使ったかとか、スピード計測・契約情報や楽天への連絡用などがひとまとめになったもので、検証結果や、回線の状況などを楽天モバイルに伝えることができます。これが、楽天モバイルへの品質改善のレポートになるんだろうと思うんですが。

ちなみに、楽天モバイルの Band3 をつかんでいるときにスピード計測した結果。一番速度が出ているのをキャプチャしてみました;-)。

実際に使ってみると、僕の住んでいる東京都の埼玉とくっつていている 23 区の一つ(それはつまりは足立区ということですね)では特に問題もなく利用できます。

会社のある品川区でも特に問題もなく利用できます。ただ、僕の職場は 12 階にあるので、多少影響を受けるのか、スピード計測すると自宅の約半分の速度しか出ないような感じです。

もう少し細かく書くと、楽天モバイルが持っている LTE は Band3 で、楽天モバイルのアンテナがないところでは au の回線にローミングされるとのことですが、使用している au の LTE は Band18 と 1 でした。
と、いうことは楽天モバイルで利用するスマートフォンは Band 1・3・18 が利用できるモノであれば事足りるような気がします。

今回 LTE バンドの確認のために利用したアプリは Network Cell Info Lite と、いうヤツです。

ちなみに自宅では Band3 で通信します。地下鉄は Band18 もしくは Band1 でローミング状態です。例えば日比谷線が三ノ輪駅の手前で地下に入りますが、その瞬間を見ていると Band3 から Band18 に切り替わります。つまりローミングが開始された瞬間ですね。

楽天モバイルアプリでスピード計測で確認すると、Band3 を掴んでいる北千住駅は 50Mbps 程度、三ノ輪駅の手前で au の Band18 に切り替わった直後は 140Mbps 出ました。おー。さすがは au の回線;-)。あ。朝の 07:15 前後の時間帯です。

会社のほうはもっと面白くて、地下鉄南北線内では Band18 、地上に出ると Band3 、そして、ビルの中に入りエレベータに乗り、トビラが閉まった瞬間に Band18 になります。
職場は 12F にあり Band3 は届かないようで Band18 で過ごすことになります。

で、ちょうど Band3 から Band18 に切り替わる瞬間をキャプチャできました。エレベーターの扉が閉まる瞬間なので、再現性十分です。なので、何回でもトライできます;-)。

無料サービス開始時はけっこうボロクソ言われていたような気がしますが、僕がそうであるように、二次募集のメンバはそれなりに使えている人が多いのではないでしょうか。楽天モバイルは最近頑張ってアンテナ立てているのと、 au とのローミングがシームレスに行っているような気がします。

とわ言いつつ、都内での利用状況のみなので、ちょっと遠出をしたときにどうなるのか、それはそれで楽しみではあります;-)。

今回はファースト・インプレッションなのでここまで。

そーそー。「無料サポータープログラム」に参加している人はレポートを出さなければならないのですが、第一回目のメールが届きました。
これが、ウェブベースのアンケート形式で、結構時間が取られる。全部回答するのに大体 20 分くらいかかりました。
これで楽天ポイント 2,000と 100GB の『ギガ』が利用できるので、まぁ、ヨシとして置きますかねぇ。と、いうか、ちゃんとレポート上げて楽天モバイルの品質向上に貢献しないと;-)。

Softbank の初期の、回線状況がボロボロだった頃に僕は iPhone3G を利用していたのですが、状況的に似ているような気がします;-)。

立ち上げ時のドタバタに参加するのは非常に楽しいですね。僕は『二度目のキャリアの立ち上がりに参加している。』と思うとワクワクします;-)。

Nginx + quiche パッチで HTTP/3 にチャレンジ。

1月 092020

2020 年の正月に ports を csv update したら Firefox72 が降って来ていたので、そのまま FreeBSD/amd64 12.1-RELEASE にインストール。
しかし、ハタと考えてみた。『Firefox って 72 から HTTP/3 をサポートしたんじゃなかったけっ？』
果たして about:config で確認してみると

network.http.http3.enabled

と、いうのがあるではないかっ!! これをすかさず true にして google などを確認してみる。

HTTP/3 というのは、チョー簡単に言うと UDP で SSL 通信を行うものであります。詳細についてはウェブで情報を探してください;-P。
ファイアーウォールなどで UDP の 443 ポートなんてのは中々開いているものではないので、自宅なり、オフィスなりのファイアーウォールをまず先に確認してみましょう。

しかし、自分でも UDP:443 で通信するサーバを構築してみたい。色々探してみると apache24 はまだ、未対応ですが、 nginx は対応パッチが出ているようです。

まずは以下の URL にアクセス。

https://blog.cloudflare.com/experiment-with-http-3-using-nginx-and-quiche/

ここに記載されている git からパッチを取ってきて nginx のソースにパッチを当てて make しても良いんだけど、configure のオプションがややこすぃー。せっかく FreeBSD が手元にあるので ports の nginx に quiche パッチを適用してサーバ環境を構築してみましょう。

と、いうのが今回の趣旨です。ひと足お先に HTTP/3 を体験してみましょう。

このブログでは以前に apache24 で HTTP/2+TLSv1.3 対応にするエントリを書いていますが、今回は nginx のエントリになります。

1). ports の準備
以下に手順を書いてみます。

# cd /usr/ports/www/
# cp -pr nginx nginx-http3
# cd nginx-http3/
# git clone --recursive https://github.com/cloudflare/quiche
# make patch

原本となる /usr/ports/www/nginx/ は一応残しておいて nginx-http3/ というディレクトリで作業を始めます。
git から quiche を一式持ってきて、ports 的には make patch まで走らせます。make patch 時に make config が走ると思いますがお好みの設定で、絶対に忘れてはいけないオプションが HTTP_SSL と HTTPV2 です。 default で [X] になっていると思うんですけどね。

2). パッチ適用

# cd work/nginx-1.16.1/
# patch -p01 < ../../quiche/extras/nginx/nginx-1.16.patch
# cd ../..

nginx-1.16 用の quiche パッチなので、最新の ports ツリーであれば容易に適用できます。

3). ports の Makefile の編集
www/nginx-http3/Makefile を編集します。上記 URL では configure オプションが記載されていますが、それを FreeBSD の ports に書いて上げます。

diff -ur Makefile.orig Makefile
--- Makefile.orig       2020-01-03 12:00:17.947717000 +0900
+++ Makefile    2020-01-03 12:01:29.885305000 +0900
@@ -53,6 +53,9 @@
 
 HAS_CONFIGURE= yes
 CONFIGURE_ARGS+=--prefix=${ETCDIR} \
+               --with-http_v3_module \
+               --with-openssl=/usr/ports/www/nginx-http3/quiche/deps/boringssl \
+               --with-quiche=/usr/ports/www/nginx-http3/quiche \
                --with-cc-opt="-I ${LOCALBASE}/include" \
                --with-ld-opt="-L ${LOCALBASE}/lib" \
                --conf-path=${ETCDIR}/nginx.conf \

さーっ!! 準備ができたのでいよいよ make だぁっ!! などと思っては行けません。 quiche 側のソースコードのコンパイルには rust の cargo build を実行するので、なんとっ!! ここへ来て、 rust をインストール必要があります。
Firefox を自前でコンパイルする人は既に rust はインストール済みだと思われるため簡単ですが、持っていない人は /usr/ports/lang/rust/ を make install しましょう。速いマシンでも 30 分くらいかかると思いますけど。

rust のインストールが終わったらいよいよ nginx を make install します。

以上で HTTP/3 対応 nginx のインストールが完了しました。めでたしめでたし。

4). nginx.conf の設定
nginx.conf の設定は抜粋のみです。

user  www;
worker_processes  4;

error_log  /var/log/nginx/error.log;
pid        /var/run/nginx.pid;

events {
    worker_connections  16;
}

http {

    autoindex off;

    server {
        listen [::]:443 quic reuseport;
        listen [::]:443 ssl  http2;
        listen      443 quic reuseport;
        listen      443 ssl  http2;

        server_name         nx.icmpv6.org;

        access_log  /var/log/nginx/access_nx_icmpv6_org.log;

        location / {
            root   /usr/local/www/nginx;
            index  index.html index.shtml index.php;
            allow  all;
        }

        ssl_certificate     /usr/local/etc/letsencrypt/live/nx.icmpv6.org/cert_chain.pem;
        ssl_certificate_key /usr/local/etc/letsencrypt/live/nx.icmpv6.org/privkey.pem;

        ssl_protocols       TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
        ssl_session_cache   shared:SSL:1m;
        ssl_session_timeout 5m;

        ssl_ciphers  HIGH:!aNULL:!MD5;
        ssl_prefer_server_ciphers  on;

        add_header alt-svc 'h3-23=":443"; ma=86400';

        http3_max_concurrent_streams 128;
        http3_max_requests           1000;
        http3_max_header_size        16k;
    }
}

listen は計 4 行ありますが、HTTP/3 で接続する場合には 443 quic reuseport の行が利用されます。 HTTP/3 に対応していないブラウザでは HTTP/2 で待ち受けるので、その設定は 443 ssl http2 になります。

そして、IPv6/IPv4 のデアルスタクです。

HTTP/2 も HTTP/3 も SSL が必須なので証明書を準備しましょう。 SSL 関連の設定もお忘れなく。

5). 実際に起動してみる
まず、何はなくとも以下のコマンドを叩いて確認。

$ netstat -an | grep 443
tcp4       0      0 *.443                  *.*                    LISTEN     
tcp6       0      0 *.443                  *.*                    LISTEN     
udp4       0      0 *.443                  *.*                    
udp4       0      0 *.443                  *.*                    
udp6       0      0 *.443                  *.*                    
udp6       0      0 *.443                  *.*
$
# tcpdump -i em0 udp port 443

うぉー。udp4,6 で port:443が開いているっ!!
tcpdump を起動して、UDP の port:443 でパケットが流れているか、確認ができます。
また、nginx のアクセスログで "GET / HTTP/2.0" は TCP Port:443 の接続になります。 "GET / HTTP/3" が UDP の Port:443 の接続になります。
上記の nginx の設定ではもう HTTP/2 か HTTP/3 の接続になりますな。高級なブラウザの場合は HTTP/2 か HTTP/3で、 w3m でアクセスするとようやっと "GET / HTTP/1.0" でのアクセスになります。

あとは nginx の root パスにドカドカコンテンツを置いていけば良いと思われます。

しかし、 netstat -an で UDP port:443 を確認して待受状態になっているにも関わらず接続できない場合があります。
サーバ側で tcpdump で確認してみると、クライアント側からアクセスがあるだけで、サーバ側からの応答がない場合が・・。しかし、とあるタイミングでは接続できるので・・。今の所 nginx を再起動してみたりと、いう運用ですかねぇ。

あと、Firefox72 は HTTP/3 で接続できなかった場合 HTTP/2 や HTTP/1.1 にフェイルオーバーしません。 HTTP/3 の応答が無くともずっと待っている状態になります。 about:config の HTTP/3 のタイムアウト設定も見当たらないし・・。

と、いうことで、今から遊ぶには十分に楽しい HTTP/3 です。FreeBSD では ports を利用すると Firefox72 は使えるわ、 nginx は ports にパッチを当てるだけで configure オプションに悩まなくて済むわ。比較的容易に、そして十分に楽しめること間違いなしです。

ここいらで UDP の世界にどっぷりとハマってみるのも良いのではないでしょうか;-)。

FreeBSD 12.1-RELEASE の if_vmx.ko は通信できない。

1月 072020

Vmware ESXi 上で動作している FreeBSD 12.0-RELEASE を freebsd-update upgrade -r 12.1-RELEASE で 12.1-RELEASE したところ、パッタリと通信が止まった。

まぁ、ssh でログインして ls とかたたく分には問題はない。ログイン先から scp でファイルを転送しようとしたときや、 12.1-RELEASE のサーバが nfs サーバだったりすると、データの転送が全くできない状態。

FreeBSD 12.1-RELEASE はアップロード (受信側) はなんとか速度が出る状態だけど、ダウンロード (送信側) は最初チョロョロそのうちストール。状態で全く利用できない状態。

どうしてそうなったのか？と、言えば FreeBSD 12.1-RELEASE になって、 if_vmx.ko は fib に対応したのですが、そこにバグがあるようです。fib については簡単にですが以前書いていますので、そちらを参考にして頂ければと思います。僕的には ubuntu の VRF のような動作ができない機能なので、全く使う気にはならないのですけども。

12.1-RELEASE でバグが入り込んでしまったのは if_vmx.ko のみなので、 Vmware ESXi で動作している FreeBSD 12.1-RELEASE は NIC を E1000 、つまりは em0 に変えることにより通信が復活するようになります。ただし、 NIC を変更すると /etc/rc.conf などに記載している設定を変更する必要があるために、インパクトがそれなりに大きいです。

12.0-RELEASE のカーネルソースツリーが手元にある人は 12.1-RELEASE 上で sys/modules/vmware/vmxnet3/ までたどり着いて、そこで make install 叩けばフツーに利用できるようになります。

とは、簡単に行かないか・・。

1). 12.0-RELEASE のソースツリーを 12.1-RELEASE 上に用意
2). 12.1-RELEASE 上で 12.0-RELEASE の sys/modules/vmware/vmxnet3/ を make install
3). カーネル再構築時は 12.1-RELEASE のソースを利用
4). GENERIC カーネルを利用しているのであれば GENERIC コンフィグから device vmx をコメントアウトしてカーネル再構築 && インストール
5). /boot/modules/ にインストールされた 12.0-RELEASE の if_vmx.ko を /boot/kernel/ に移動
6). /boot/loader.conf に if_vmx.ko をロードするように記載
7). FreeBSD の再起動

これだけやる必要があります。

今の所 12.1-RELEASE にバージョンアップして通信ができなくなるのは if_vmx.ko が原因になるので、他の NIC では発生していないと思われます。

僕は、物理 NIC を割り当てていない vSwitch 経由の FreeBSD の NIC は if_vmx.ko を利用して MTU を 9000 にしています。
物理 NIC を割り当てている vSwitch では if_vmx.ko を利用していますが MTU は 1500 のままにしています。
どちらの場合も通信が滞るので MTU は関係ありません。

バグレポートも上がっているようです。が、直接的な解決策はまだ見つかっていないようです。

Bug 236999 – vmx driver stops sending network packets and resets connections (TCP) but allows ICMP

某 BSD 系な Slack で仲間連中と色々話したり試験したりしているのですが、再現性は 100% で、かつ、今日現在 if_vmx.ko での回避策を見出せていません。

なお、 Vmware ESXi 上に FreeBSD をサーバとして if_vmx.ko を利用しているサービスはほぼ全滅です。ウェブ・ FTP ・ svn サーバ・ NFS サーバ、その他諸々。

FreeBSD 12.0-RELEASE を Vmware ESXi 上で稼働させていて、FreeBSD 12.1-RELEASE にバージョンアップした人、しようとした人はお気をつけください。

OPPO Reno A 買ってみました。

11月 242019

去年の暮れに UMIDIGI Z2 Updated Edition を購入しました。しかし、あまりにも遅くてうんざり・・。ポケモン GO とかナニゲに遅いし、あらゆる動作でもっさりしていて、ノッチが付いているスマートフォンが欲しくて購入したのに、ちょっと残念な状態で使っていました。

新しいのを物色していて Xperia Ace が小型で良さそうだと思ったけど、実際に持っている人の話を聞くと『Snapdragon 630 は速くないよ。』と、のことだったので、たとえおサイフケータイが付いていたとしても、悩みどころな状態だったのであります。

が、そんなところにすごい端末が出たようです。 OPPO Reno A 。スペック的には有機 LE ディスプレー・ Snapdragon 710 ・メモリ 6GB ・おサイフケータイ付き。

ウェブで色々調べていると非常に良いみたい。そして、販売しているサイトでは次から次へと売り切れになっているので、こらー悩んでいたら売り切れちゃうな。と、いうことで楽天の「ひかり TV ショッピング」で、購入しました。なんとっ!! 次の日には売り切れ。いやぁ。危なかった・・。

右側が今まで利用していた UMIDIGI Z2 Updated Edition 。左側が新しく購入した OPPO Reno A です。

どちらも、液晶保護フィルムとケースが default で付いていました。 UMIDIGI Z2 に付いていた保護フィルムはポケモン GO している間に指のササクレなどがある状態でモンスターボールを投げ続けるなどしていたら傷だらけになってしまったので、ちょっと弱い感じですね。 OPPO Reno A の保護フィルムは硬質な感じがします。ケースはソフトで透明なのが OPPO Reno A で、背面の色がキラキラ光って綺麗です。

ケースが default で付いているので、裏面に貼られているシールとか剥がさずにそのまま利用している状態ですねf(^^;;。 UMIDIGI Z2 などは今で裏面にシール貼ったままです。

それにしても OPPO Reno A の箱は随分と縦長だった。インパクトある箱です。

と、いうことで、届いて 10 日ほど経ったのでレビューしてみます。現在は、設定は全て完了していておサイフケータイまで利用可能な状態になっています。

o. ColerOS 6 (Android9) はつらい・・。
まず、やっぱり OS について書く必要があるかな。ハードウェア的には秀悦でもその上で動作している OS のアラが目に着く。あんまり深く踏み込んだレビュー記事が無いので書いてみます。

1. google アプリが無効にできない
Android9 の仕様なのか ColerOS の仕様なのかよく分かりませんが google のアプリが無効にできません。僕の場合、以下のアプリや、他の google 謹製アプリは不要なので、無効にしたいのであります。 UMIDIGI Z2 では無効にできたのにこの端末ではできません。

停止した google 謹製アプリは以下の通り。他にももっとあるけど・・。

しょーがないので、不要と思われる google 謹製、その他の無効化できないアプリは

アップデートは削除
全ての通知は非表示
全ての権限なし
モバイル・ WiFi 通信なし

にしました。

もうコテコテです。ブラウザは Microsoft Edge を常用にして Vivaldi (Beta 版) をサブしています。

QUICPay アプリがいつでも Chrome を呼び出すのには辟易します。 default ブラウザは Microsoft Edge にしているのに Chrome が起動します。なんとかしてくれよー。 JCBぃーー。って感じ・・。 orz

2. ウェブショートカットができない
Microsoft Edgi や Vivaldi (Beta 版) からウェブの URL のショートカットをトップページに作成しようとしてもできません・・。結構ダメージでかい。

3. 設定のウィジットからウェブショートカットができない
「設定」アプリの各項目をウィジェットとしてショートカットを作成しようとしても、メニューがボロボロで欲しい設定ウィジェットが作れません。

こんな感じで表示されます。なんで同じ項目が何個もあるんだろう? orz

ただ、上からスワイプしたときに表示される通知の欄の上の設定項目が充実しているので、そこで色々オン・オフできるので代用はできる道が残されています。

4. 各アプリの設定項目が少ない
カメラアプリは保存するサイズの変更ができません。 GPS ポイントはオンにするだけで、もちゃんと書き込んでくれます。ただ、アプリの権限を適切に与えてあげましょう。

UMIDIGI Z2 の標準カメラアプリは GPS を書き込んでくれなかったので常用していなくて、ハードウェア的にレンズ二個積んでいてもその恩恵は受けられなかったのですが、 OPPO Reno A のカメラは GPS ポイントをちゃんと書き込んでくれるし、撮れる写真は被写体深度も深い写真ができるので中々良い感じです。

ギャラリーアプリは写真のソート順序を変更できません。ただ google 謹製のやつではなく ColoerOS 自前で用意しているようなので UMIDIGI Z2 に比べて好感は持てます。
その他、 ColorOS 付属のアプリは非常にシンプルです。

5. 楽曲 DB が文字化け
今まで UMIDIGI Z2 に入れていたハイレゾ音源もたくさん入っている 128GB の MicroSD をそのまま OPPO Reno A に入れました。ミュージックアプリを起動するとスキャンが始まってデータベースを構築するようです。このとき、文字化けが起きてしまい、以下のような状況。
日本語ディレクトリは文字化けせず認識しているので、ただ単に DB 構築時のスキャンプログラムに不備があるのでしょうなぁ。 nkf -u とかすれば良いのに;-P。

6. テザリングオッケー
ここから先は良い点を何個か;-)。
UMIDIGI Z2 というか、中華スマホ系はテザリング時に Wi-Fi の 14ch で待ち受けるため、最近の日本国内では Wi-Fi 子機は 1 〜 13ch での接続が主流だったので、子機が接続できない事象があちこちで発生していたのですが、この OPPO Reno A はそんなことはなく、ちゃんとデザリングがでて、トヨタのカーナビも無事に接続できました。

ただ、UMIDIGI Z2 は 2.4GHz 帯と 5GHz 帯が選択できのですが OPPO Reno A はそのメニューがないので 2.4GHz 帯でのみのテザリングになります。

7. 開発者向けオプションが無い
Androd 純正ではないので、開発者向けオプションがないのは当たり前かな？

何が言いたいのか？と、言えば Bluetooth 機器のボリューム調整が楽なのであります。素の Android の場合 Bluetooth 機器のボタンを押してもボリュームの微調整ができない(でかくなりすぎたり、小さくなりすぎたりで、その中間がない)ので、開発者向けオプションのメニューで「絶対音量を無効にする」をオンにする必要があったんだけど ColorOS は、それが必要なく Bluetooth 機器のボリュームボタンが割と素直なボリューム調整を行ってくれます。

OS 的にはこんな感じでしょうかね。ただ、慣れれば ColorOS も特に気にならないような気がしないこともないでしょぅか。
誰かが書いていましたが iOS に似ている部分がそこはかとなくあります。ボリューム調整ボタンを押したときだったり、タスクをぶっ飛ばすときに上にスワイプするとか。

ColorOS 独自の機能も充実していて、指三本で上から下にスワイプすると画面キャプチャできたりとか、指三本で下から上にスワイプすると画面分割してくれるとか、画面右に怪しげなメニューが隠れているとか、面白い機能が潜んでいます。ただ、それを知るにはウェブで ColorOS について色々検索して調べるのが良いですね。その点も iOS みたいだぁ;-)。

そして、使い込んでいくと、やはり OS よりも本体のスペックの高さが先に目立つようになります。ディスプレーは非常に綺麗なので、いつも見ていたくなります。
指紋認証も OK 。顔認証は老眼鏡をかけていても認識してくれるときがあるので嬉しいです。

OS のバージョンアップの頻度はどれくらいで行われるのかは未定ですが、ハードウェアのスペック的には 2,3 年使える雰囲気なので、 UMIDIGI Z2 よりは長く使える端末であることには間違いないような気がします;=)。

今回はなんか、良い買い物をしたような気がします。考えてみると、僕はあまり Android 端末には恵まれていなかったのかな？まぁ、 iPhone3 からずっと持っていて Android にはあまりお金をかけてこなかった。と、いうのもあるんですが、今回購入した OPPO Reno A は僕の Android OS 人生の中でもかなりのヒットだと思われます。

売り切れ続出なのも解ります。売り切れる前に購入しておいて良かったぁ;-)。

FreeBSD 12.0-RELEASE から if_rtwn が利用可能ななった。

10月 282019

以前書いた「FreeBSD で if_urtwm を使ってみる。」と、いうエントリの置き換えです。当時は 11.0-RELEASE で RealTek のチップセットが組み込まれている 802.11a な USB Wi-Fi 子機を利用するためにドライバ(カーネルモジュール)をインストールして、利用する。と、いうものだったのですが 12.0-RELEASE になって RealTek の Wi-Fi チップは rtwn というデバイスに統合されました。 PCI 接続のものも USB 接続のものもどっちも rtwn.ko になりました。

なので、以前の記事はもう古くなっているので、新しく更新します。

と、いうことで FreeBSD 12.0-RELEASE 以降で RealTek のチップを利用している USB な Wi-Fi 子機を利用する方法を記載します。

まず、何はなくともカーネルモジュールをロードします。以下が /boot/loader.conf に書く内容ですね。

legal.realtek.license_ack="1"
firmware_load="YES"
if_rtwn_load="YES"
if_rtwn_usb="YES"
rtwn-rtl8188eufw_load="YES"
rtwn-rtl8192cfwE_B_load="YES"
rtwn-rtl8192cfwE_load="YES"
rtwn-rtl8192cfwT_load="YES"
rtwn-rtl8192cfwU_load="YES"
rtwn-rtl8192eufw_load="YES"
rtwn-rtl8812aufw_load="YES"
rtwn-rtl8821aufw_load="YES"

wlan_* の設定は省略しています。 if_rtwn.ko は本体で、それとは別な if_rtwn_usb.ko は USB な Wi-Fi 子機用のカーネルモジュールもロードし(自動的にロードされ)ます。 PCI 接続のデバイス用にもカーネルモジュールは用意されていますが、今回は割愛します。

rtl81* なファームウェアは 802.11 b/n/g 用のチップで、今まで urtwn で利用されていたヤツですね。でもって rtl88* は 802.11a/ac 用のチップで、これが使えるようになったのが一番大きい変更点です。僕も FreeBSD で 802.11a を利用したくて以前のエントリを書いたくらいですからねぇ。

で、使える USB な Wi-Fi 子機ですが、古い b/g/n 用の、以前 urtwn.ko で利用していたヤツはサクっと利用可能です。なので、今回は詳細について記載しません。
ただし、遅いです。 google のスピードテストのサイトにアクセスしても 10Mbps 前後の速度です。以前の urtwn.ko のほうが速度は出たんではないかなぁ・・。

さてと。問題は、今回のメインの話になる 802.11a についてですが、現在、僕の知る限り(製品など)、以下の三種類のチップがあるようです。

RTL8811AU : USB2.0 ベースで 802.11a/ac にアクセスできるチップ
RTL8812AU : USB3.0 ベースで 802.11a/ac にアクセスできるチップ
RTL8821AU : USB3.0 ベースで 802.11a/ac にアクセスできるチップ

FreeBSD のソースを見れば解りますが src/sys/dev/rtwn/ には rtl8812a/ と rtl8821a/ しかないので、一番上のチップを利用している USB Wi-Fi 子機は動作しません。

RTL8811AU なチップを利用している USB 子機で、僕が持っているのは以下の二種類です。

一個は「二個目の if_urtwm を試す。」というエントリで書いています。

そして、もう一個、新しいのを買ってみました。 TP-LINK の AC600 と言うヤツです。

しかし、こいつも見事に RTL8811AU だったので FreeBSD では利用できませんでした・・。orz

これらを src/sys/dev/usb/usbdevs や、番号がちょっと違うだけの src/dev/rtwn/usb/rtwn_usb_attach.h にエントリを書いても以下のログが出て動作しませんでした。

kernel: ugen0.2:  at usbus0
kernel: rtwn0 on uhub1
kernel: rtwn0:  on usbus0
kernel: rtwn0: MAC/BB RTL8812AU, RF 6052 2T2R
kernel: wlan0: Ethernet address: 81:3f:5d:28:3a:bb
wpa_supplicant[1676]: Successfully initialized wpa_supplicant
wpa_supplicant[1678]: wlan0: Trying to associate with 1a:68:82:43:0a:99 (SSID='80211N-AP' freq=2412 MHz)
wpa_supplicant[1678]: Failed to add supported operating classes IE
wpa_supplicant[1678]: ioctl[SIOCS80211, op=21, val=0, arg_len=42]: No such file or directory
wpa_supplicant[1678]: wlan0: Association request to the driver failed
wpa_supplicant[1678]: wlan0: Authentication with 1a:68:82:43:0a:99 timed out.
wpa_supplicant[1678]: wlan0: CTRL-EVENT-DISCONNECTED bssid=1a:68:82:43:0a:99 reason=3 locally_generated=1

Mac アドレスが付加されず ff:ff:ff:ff:ff:ff になってしまうので、やはり RTL8812AU なドライバのソースコードでは代用できない。と、いうことですねぇ。ifconfig wlan0 scan も動作しません。

となると、手持ちの RTL8812AU なチップを利用した USB Wi-Fi 子機に全てをかけることになります。

以前、このブログで一回掲載しているヤツで、やたらと大きい USB Wi-Fi 子機です。 amazon.co.jp で探しても RTL88* なチップ利用している USB 子機はアンテナが出ていたりやたらと大きかったりして邪魔になるものが多いですね。

では、この USB Wi-Fi 子機利用時の設定を見ていきます。が、その前に usbdevs や rtwn_usb_attach.h にエントリを作成し、カーネルモジュールを make し直す必要があります。

o. src/sys/dev/usb/usbdevs に追加

product REALTEK RTL8812AU       0x8812  RTL8812AU Wireless Adapter

o. src/dev/rtwn/usb/rtwn_usb_attach.h に追加

        RTWN_RTL8812AU_DEV(REALTEK,             RTL8812AU),

これで sys/modules/rtwn_usb/ で make && make install します。 /boot/modules/ にインストールされるので好みで /boot/kernel/ に移してください。

そして、次に設定。

o. /etc/rc.conf

wlans_rtwn0="wlan0"
ifconfig_wlan0="WPA DHCP country JP ssid 80211A-AP mode 11a"

o. /etc/wpa_supplicant.conf

# パスワードが必要な Wi-Fi (802.11a)
network={
        ssid="80211A-AP"
        scan_ssid=1
        key_mgmt=WPA-PSK
        proto=RSN WPA
        psk="PASSWORD"
}

# パスワードが必要な Wi-Fi (802.11n)
network={
        ssid="80211N-AP"
        scan_ssid=1
        key_mgmt=WPA-PSK
        proto=RSN WPA
        psk="PASSWORD"
}

# パスワードが不要なフリー Wi-Fi (802.11n)
network={
        ssid="80211N-AP_FREE"
        scan_ssid=0
        key_mgmt=NONE
        proto=RSN WPA
}

この設定で、フツーなら接続できるはずなんですけどねぇ・・。公開している (ifconfig wlan0 scan で表示される) 802.11a な AP には接続できます。ステルスモードの 802.11a な AP には接続できませんでした。 scan_ssid=1 を指定しているのにね。

『/etc/wpa_supplicant.conf の書き方、悪いんじゃね？』とか思う方がいるかと思われますが 802.11n なステルスモードの AP には接続できます。 SSID のみを書き換えているだけなのに 802.11n は接続できて、802.11a には接続できません。
そして、 802.11a でもステルスモードを off にして SSID を公開している AP には接続ができて、かつ、通信もできます。
ステルスモードの 802.11a に接続できないのは、ドライバ (rtwn.ko) ・ wpa_supplicant ・ ifconfig のどこに問題があるのか、まるで見当がつかないのでソースコードさえ追ってないです・・。

wpa_supplicant で、何か特別なオプションが必要なのかな？

FreeBSD で 802.11a のステルスモードの AP に接続できている人ってどなたかいますか？

さてと。ここから先は無事に接続できた SSID 公開モードの 802.11a な AP に接続した状態で、通信試験をしてみた結果です。

google のスピートテストで確認してみましたが・・。

これまた遅い・・。orz

RTL81* シリーズで 802.11n な AP に接続した状態と対して変わらないか、色眼鏡で見て +2Mbps 程度、つまりは、いーとこ 10Mbps 程度の速度しか出ません・・。
非力な CPU や firefox が重いなどの点を抜きにしても遅すぎます。常用にはほぼ向かない雰囲気です・・。orz

これじゃ 802.11a にする意味ねー・・。orz まぁ、電子レンジ対策にはなりそうですが。

ちなみに今回試した 802.11a な AP は iPhone8 でアクセスすると 70Mbps 程度、 FreeBSD に接続していた同じ USB Wi-Fi 子機を Windows10 に接続して試験すると 50Mbps 程度は出ているので AP や USB 子機の問題は無いはずです。つまりは FreeBSD の rtwn.ko ドライバは『利用できるよ。』ってだけで、速度は全然出ていない。と、いうことになりそうです・・。

Intel の CPU を積んでいない NotePC にとって 802.11a に接続できる唯一の rtwn.ko だったのですが、これでは利用するに値しません・・。きちんと動作して、サクっと 802.11n に接続する if_run.ko のほうが圧倒的に性能良いです。

では、 FreeBSD で 802.11a な AP に接続するには他にどんな手段があるのか考えてみました。
そして、ふと、思いました。 Wi-Fi 中継機を RJ45 な NIC に接続して、そこから 802.11a に接続するのが良いんじゃね？みたいな。

僕のは手元には ELECOM の WRH-583GN2-S があるのですが、これは超小型の Wi-Fi AP です。ウェブ UI から設定を変更することにより Wi-Fi の中継機にもなります。
価格も 802.11a/ac 対応の USB Wi-Fi 子機を買うのと遜色ありませんでした。大体 2,000yen くらいで買った記憶が・・。今はもう既に販売終了のようですね。

このてのちっこいヤツは、利用時の電源は USB から供給できるので、通信時には FreeBSD の re0 に接続して WRH-583GN2-S が Wi-Fi の中継機として動作し 802.11a の AP に接続して利用すれば望み通り無線環境で 802.11a が利用可能になります;-)。

これが最後の手段かなぁ・・。

今回は FreeBSD 12.0-RELEASE で登場した rtwn.ko の 802.11a について、以前のエントリを書き換えるために書いてみました。結果はそこはかとなく悲しい状態だったのでありました・・。 orz

このエントリを読み終えた方。慌てて RTL8812AU や RTL8821AU に対応した USB Wi-Fi 子機を買う必要は、今の所、全くありません。たとえ FreeBSD で認識して、利用可能な状態になったとしても、遅すぎてお話になりません。ヒトバシラーは僕だけで十分です・・ (g_g)。

さて。それでも rtwn.ko を使うか使わないかはあなた次第っ!!??

って、FreeBSD のバージョンが上がったら、もう一回エントリ書くことになるのかなぁ？

Ansible の telnet モジュールは結構へぼい。

9月 152019

わけあって ansible を触るようになりました。ネットワーク機器の設定を自動更新できたら良い感じー。みたいな雰囲気で。

で、話のテンポはサササっと行くのですが、Cisco スイッチとかにアクセスする場合、 ssh ではなく今でも telnet を利用している人(会社)は多いかな？
エッジスイッチなんてのはグローバルアドレスが付いてないので外部から攻撃される心配ないし、パケットをキャプチャされることもないので『telnet でじゅーぶん。』みたいな。

そうなるといつまで経っても telnet を利用してしまうわけですが、 ansible が Cisco のネットワーク機器にアクセスするときには ios_command というモジュールを利用すると便利なのですが、こいつは ssh にしか対応してないので、それを使わず telnet モジュールでシコシコ tasks: を並べていく必要があるんですけども。

以下は telnet モジュールを利用した場合の標準的な playbooks の書き方です。

- name: send configuration commands to IOS
  telnet:
    user: admin
    password: cisco
    login_prompt: "Username: "
    prompts:
      - "[>|#]"
    command:
      - terminal length 0
      - show running-config
      - configure terminal
      - hostname ios01
    register: result

  - name: debug
    debug:
      msg: "{{ result }}"

この通りにやっても動かないことが多々ある。debug: を指定して output の中を見てももーぐちゃぐちゃ。初めて ansible をテスト的に利用してみると

『ansible ってこんなダサいの？ perl の Net::Telnet 使ったほうがよっぽどいーじゃん。』

とかになってしまうのであります。

ansible の telnet モジュールがまともに動かない。答えを先に書くと、その原因は “#” にあります。

以下、Cisco 機器のネットワークインターフェースの設定だとします。

interface GigabitEthernet4
  description # VLAN1 Network #
 no ip address
!

description に “#” を使っていると telnet モジュールはプロンプトだと勘違いして処理がそこで止まります。
show interfaces status や show interfaces description ・ show running-config など何一つまともに動きません。

telnet モジュールの prompts: はプロンプトの “#” のみを見ているのでは無く Cisco ルータから出力された全ての “#” を見て動作しています。ヘボ過ぎる・・。 orz

telnet モジュールを利用した場合、出力された内容に “#” があるとまともに動作しません。ではどうやって対応するか？以下は Cisco ルータの場合の対応策です。

- name: send configuration commands to IOS
  telnet:
    user: admin
    password: cisco
    login_prompt: "Username: "
    prompts:
      - "[o|)][>|#]"
    command:
      - terminal length 0
      - show running-config
      - configure terminal
      - hostname ios01
    register: result

  - name: debug
    debug:
      msg: "{{ result }}"

prompts: に指定する文字が一文字だからダメで、二文字にマッチさせると何とか無事に動作するようになります。二文字でマッチできない場合はもう一文字追加で;-)。

上記の prompts: の設定では、本スト名が cisco の場合、プロンプトは以下になります。

cisco>
cisco>enable
cisco#
cisco#configure terminal
cisco(coinfig)#interface gigabitEthernet4
cisco(config-if)#

つまり、ホスト名の最後の一文字と “#” を組み合わせた “o#” と、いう prompts: 、あと configure terminal 時にはプロンプトの前に “)” がつくので “)#” にマッチするように prompts: を記述します。

これで show running-config したときに設定中に “#” があっても無事に動作するようになります。

ansible で telnet モジュールを利用する場合には prompts: に設定した文字列に十分に注意しましょう。 prompts: に指定する文字は register: に出力される前に吸収されてしまいます。

ThinkPad E145 を UEFI ブートに変えてみた。

8月 072019

最近の FreeBSD は BIOS では PC の機能が使えなくなってきているものがちらほら出てきて、いよいよ UEFI に変えるべきかと思えてきた。
僕の持っているちょっと古いが、今でも現役の ThinkPad E145 を BIOS で利用するのは FreeBSD/amd64 10.1-RELEASE が一番良かった。その後 10.3-R -> 11.2-R にしてみると LCD の明るさが変えられなくなったりとか。
最近 11.3-R にしたら suspend して resume すると /dev/psm0 が『もう使えないよ。』みたいなエラーを吐きやがる。

psm0: failed to get status (doinitialize).
psm0: failed to enable the device (doopen).
psm0: failed to enable the device (reinitialize).

こんな感じ。 resume 後はもう USB なマウスを使うしか手がない。 /dev/psm0 だけでなく /dev/sysmouse (こっちはタッチパッド) も使えない状態。 moused も hald も悲しい状態。

/dev/psm0 みたいなのは BIOS べったりなので OS 的に UEFI 対応が進む FreeBSD ではいよいよ使えなくなってきているのだろうなぁ。などと、思い、それじゃ。と、いうことで UEFI で起動してみるかぁ。と、なったのであります。

以前、このブログでは ThinkPad E145 を BIOS+MBR の組み合わせで Windows8 と FreeBSD のマルチブートについてエントリを書いているのですが、今回はいよいよ UEFI+GPT でのブートになります。
当時 (上記 URL の記事は 2013 年 09 月に書いていますね) は、マルチブートに関する前例が中々見当たらず、インターネット上にもそれらしい記事がなかったのですが、最近は探せばちらほらと見つかるようになってきましたね。それは非常に良いことです。

と、いうことで僕もトライ。今回は、自分の今後のことも兼ねて、メモ的にその手順について書き留めておきます。まぁ、作業はほとんどが Windows10 上で行うんですけどね。

おおまかな手順は以下です。

0. Windows の回復 USB メモリの作成
1. Windows10 をまずインストール。もしくはパーティションを分割
2. FreeBSD 用 EFI パーティションを作成
3. FreeBSD/amd64 12.0-RELEASE をインストール
4. bcdedit でマルチブート設定
5. EFI パーティションにファイル設置
6. 電源投入で FreeBSD 起動

だいたいこんな感じでしょうか。では、はじまりです。

一応、断っておきますが、0 番目の「回復 USB メモリ」はもしものためにちゃんと作成しておきましょう。僕は Windows10 環境を何回もぶっ飛ばしていたりしますが、もし、そうなっても僕は責任持てません:-|。

1. Windows10 のインストール
新しい PC を買ってきたときや、今使っている PC には Windows10 が最初から入っていると思われます。
コントロールパネル -> コンピュータの管理 -> ディスクの管理で、Windows10 に割り当てられているパーティションをちっこくしてあげる。詳細は書きませんけども。
新規に Windows10 をインストールする場合は C:\ を好きなサイズにして FreeBSD をインストールするスペースを残しておきます。
まず最初に Windows10 をインストールする。もしくは Windows10 がインストールされている状態。と、いうのが重要です。

新規に Windows10 をインストールする場合、ブート用の USB メモリを作成するところから始める人がいるかもしれませんが、僕の場合、今回は Windows のアプリで rufus と、いうのを利用しました。

バージョンにもよるかもしれませんが、 Windows10 の ISO ファイルは rufus に食わせると USB の起動イメージを BIOS+MBR で作るか UEFI+GPT で作るか指定できます。もしこの時に UEFI+GPT で作成した場合には NotePC の BIOS 設定は UEFI モードにしないとイントールできません。
Widowos10 の USB の起動イメージを BIOS+MBR で作ると、インストールした Windows10 は BIOS+MBR になってしまいます。今回は UEFI+GPT で USB 起動イメージを作成することになります。

作成した USB 起動イメージに合わせるために BIOS の設定を確認しましょう。 BIOS の設定については以前書いています。そちらを参考にしてください。

さてと。これで Windows10 のインストールが無事に完了しました。

2. FreeBSD 用 EFI 領域の確保
FreeBSD を ISO イメージから起動してメニューの [install] を選択して進めていくと、 Windows10 がインストールされているにも関わらず FreeBSD しかブートしない NotePC になってしまいます。 bsdinstall を利用して (それはつまりは FreeBSD をフツーにインストールする。と、いうことです) FreeBSD をインストールすると既に存在する Windows10 の EFI パーティションを上書きしてしまうからなんですね。

フツーの人 (それは takawata さんみたいにマニアではない人のこと;-) は FreeBSD はフツーにインストールすると思います。

しかし、フツーにインストールすると既にある EFI パーティションを上書きして潰してしまうので、新規に 100MB 程 EFI パーティションを作成してあげます。

Windows10 は既に起動しているはずなので、以下のコマンドを管理者権限の DOS プロンプトから実行します。

c:\ diskpart
DISKPART> list disk
DISKPART> select disk 0
DISKPART> list vol 
DISKPART> select vol 0
DISKPART> list part
DISKPART>
DISKPART> create partition efi size=100
DISKPART> list part
DISKPART> select part [番号]
DISKPART> format quick fs=fat32 label="FreeBSD-EFI"
DISKPART> assign letter="S"
DISKPART> 
DISKPART> list vol
DISKPART> list part
DISKPART> exit

簡単にコマンドイメージだけ書きました。

1). diskpart.exe を管理者権限で実行
2). 対象とするディスク番号を選択
3). 対象とするボリューム番号を選択
4). ディスクのパーティション状況を確認
5). いよいよ create partition で EFI パーティションを 100MB で作成
6). 作成したパーティションを選択 (番号間違えないでくださいねぇー)
7). fat32 でフォーマットして、ラベルは FreeBSD-EFI とする (お好きな文字列をどうぞ)
8). assign letter=”S” でおまじない;-)

これで FreeBSD の bsdinstall がアクセスする EFI パーティションが作成できました。 FreeBSD を何回インストールしても、インストール後に NotePC を再起動すると Windows10 が起動する状態になります。

上記 takawata さんの URL ではこの工程がないので Windows 側の EFI パーティションを守るために bsdinstall を利用しないで make buildworld しているんですね。あ。 takawata さんは『マニア』なのかもしれないですが、 make buildworld が好きな人なのですね。きっと;-)。

それにしても bsdinstall が既存の EFI パーティションを上書きしてしまうのが問題なんですね。メニューで上書きするかしないか選択できるようにすれば良いのに・・。

と、いうことで次は FreeBSD のインストールです。

3. FreeBSD のインストール
今回は FreeBSD-12.0-RELEASE-amd64-bootonly.iso をチョイスしました。もう、面倒なので Windows10 上で、やはり rufus を使い USB 起動イメージを作成しました。
FreeBSD の場合は、今度は BIOS+MBR でしか作成できません。なので、FreeBSD インストール時には今度は BIOS の設定を Legacy モードにする必要があります。

あとはフツーにインストール。パーティション分割のところで GPT を選択し、更に [Manual] を選択してHDD (最近は SSD か;-) の空き領域にインストールします。

インストールが完了してリブートします。 2. のところで書いた通り、先に FreeBSD 用 EFI パーティションを作成していると bsdinstall を利用しても Windows10 側の EFI パーティションはつぶれてないので、この時点で再起動後は Widnows10 が起動するはずです。
もし FreeBSD が起動してしまった場合は Windows10 がつぶれてしまった。と、いうことです。回復 USB メモリなどから Windows10 を復旧しましょう。

4. bcdedit でマルチブート設定
FreeBSD インストール後に再起動したら Windows10 が起動しましたが、インストールした FreeBSD はしっかり残っております。起動させるために Windows10 側で bcdedit を利用してエントリを作成してあげます。

以前、このブログでも BIOS+MBR 環境のときに bcdedit を利用して、Windows Boot Manager から Windows と FreeBSD をブートしていましたが、 UEFI+GPT の場合は Windows Boot Manager が利用できません。 UEFI+GPT でのマルチブート環境は Firmware Windows Boot Manager を利用してブートすることになります。

そもそも「Firmware Windows Boot Manager」とはなんぞや？と、なるのですが、簡単に言うと BIOS(UEFI) のブートセレクタです。
例えば HDD からブートするとか、CD や USB メモリからブートするとか、選択する画面は Fn キーを押してメニューを出しますが、それをどうやら「Firmware Windows Boot Manager」というようです。
CD や USB・HDD からブートするのと同じレベルのメニューに “FreeBSD” や “Windows Boot Manager” メニューが存在している状態になります。

ThunkPad の場合 (Lenovo の PC の場合) は電源投入時に F12 キーを押すとブートセレクタが現れます。メーカによっては F2 キーだったり F8 キーだったりするかもしれません。

これから、このブートセレクタに bcdedit でメニューを登録していきます。

まず、管理者権限の DOS プロンプトでフツーに bcdedit と叩くと「Windows Boot Manager」のメニュー画面の情報が出力されます。僕の知っていた bcdedit はこの、オプションなし状態の出力でした。

「Firmware Windows Boot Manager」の項目を表示するには以下のコマンドを打ちます。

C:\Windows\system32> bcdedit
C:\Windows\system32> 
C:\Windows\system32> bcdedit /enum firmware
C:\Windows\system32> bcdedit /enum all

/enum オプションをつけて、そのあとに firmware とすると「Firmware Windows Boot Manager」の項目を表示します。 all と打つと「Firmware Windows Boot Manager」と「Windows Boot Manager」の全ての項目を表示します。ここ、重要ですからね;-)。

まず、「Firmware Windows Boot Manager」に FreeBSD のメニューを追加します。

C:\Windows\system32> bcdedit /copy "{bootmgr}" /d "FreeBSD"
*** ここで UUID が表示される ***
C:\Windows\system32> bcdedit /set {UUID} device partition=\Device\HarddiskVolume2
C:\Windows\system32> bcdedit /set {UUID} path \EFI\FreeBSD\Boot\bootx64.efi
C:\Windows\system32> bcdedit /set {fwbootmgr} displayorder {UUID} /addfirst

以下のような雰囲気です。

1). /copy で “FreeBSD” というエントリを作成。このときに FreeBSD の UUID が割り当てられる
2). エントリ中に device を設定 (省略可)
3). エントリ中に path を設定
4). エントリ中の順番を設定

最後の 4). のエントリについて先に説明します。 /addlast で最後に追加することもできます。その場合 F12 キーを押さない場合は Windows10 が起動します。 /addfirst を指定すると先頭に追加され、 F12 キーを押さない場合は FreeBSD がブートするようになります。お好みで;-)。

上記コマンドを投入したあと、再度 bcdedit /enum firmware を叩いてみましょう。以下は抜粋です。

C:\Windows\system32> bcdedit /enum firmware

ファームウェアのブート マネージャー
--------------------------------
identifier              {fwbootmgr}
displayorder            {bootmgr}
                        {dd655fef-3160-11e9-8f42-a6c75caf7b54} <- 先頭に追加
                        {dd655fe9-3160-11e9-8f42-a6c75caf7b54}
                        {dd655fea-3160-11e9-8f42-a6c75caf7b54}
timeout                 2
<--- 略 --->
Windows ブート マネージャー                                       <- 今回追加
--------------------------------
identifier              {dd655fef-3160-11e9-8f42-a6c75caf7b54}
device                  partition=\Device\HarddiskVolume2
path                    \EFI\FreeBSD\Boot\bootx64.efi
description             FreeBSD
locale                  ja-JP
inherit                 {globalsettings}
badmemoryaccess         Yes
default                 {current}
resumeobject            {dd655fed-3160-11e9-8f42-a6c75caf7b54}
displayorder            {current}
toolsdisplayorder       {memdiag}
timeout                 30
<--- 略 --->

このあとに説明しますが、UEFI+GPT の場合、OS をブートさせるためには EFI パーティションにファイルを一個置いてあげる必要があります。FreeBSD の場合は、インストールされている FreeBSD の /boot/boot1.efi を上記エントリの device と path に指定したところに正しく置いてあげる必要があります。

記載内容を間違えると「Firmware Windows Boot Manager」で “FreeBSD” を選択しても何もアクションが起きません。

そして、この内容が、BIOS+MBR の頃のように

device                  partition=c:\
path                    \bootx64.efi

などと記載していると「Windows Boot Manager」側で認識して、ブートすると 0x000007d みたいなエラーが出力されます。

記載した内容と設置した場所を正しく一致させましょう。

ちなみに作成したエントリを消す bcdedit は以下になります。書いては消して、また書いて、ブートしないのでまた書いて・・。などと、いうとき用です;-)。

C:\Windows\system32> bcdedit /delete {UUID} /f
C:\Windows\system32> bcdedit /set {fwbootmgr} displayorder {UUID} /remove

一行目は bcdedit /copy “{bootmgr}” で作成したエントリ全てを消すコマンドです。このコマンドを実行すると「ファームウェアのブートマネージャー」からも削除されます。
二行目のコマンドは「ファームウェアのブートマネージャー」から削除するときのみ利用するコマンドです。例えば /addlast で一番最後に登録したけど、やっぱり /addfirst で先頭に登録したい。などとうとき、二行目のコマンドを実行したあとに再度 bcdedit /set fwbootmgr displayorder を叩く。と、いうときに利用します。

bcdedit で「Firmware Windows Boot Manager」に登録するコマンドはこんな感じでしょうか。

5. EFI パーティションにファイル設置
さてと。あと少しで環境が整います。 EFI パーティションに FreeBSD がブートするための boot1.efi を書き込んで上げます。他の PC 上で動作している FreeBSD から /boot/boot1.efi を持ってきて Windows10 側に保存して上げましょう。

まず、diskpart.exe でボリュームの確認です。

c:\ diskpart
DISKPART> list disk
DISKPART> select disk 0
DISKPART> list vol
  Volume ###  Ltr Label        Fs    Type        Size     Status     Info
  ----------  --- -----------  ----  ----------  -------  ---------  --------
  Volume 0         回復          NTFS   Partition    499 MB  正常
  Volume 1     C                NTFS   Partition    213 GB  正常         ブート
  Volume 2                      NTFS   Partition    574 MB  正常
  Volume 3                      FAT32  Partition    100 MB  正常         システム
  Volume 4         FREEBSD-EFI  FAT32  Partition    100 MB  正常         非表示
DISKPART>

EFI バーティションは Windows10 が作成したもの (Volume3) と FreeBSD インストール時に作成したもの (Volume4) と二つありますが、どっちを利用しても問題ありません。

Windows10 で EFI パーティションをマウントするためには以下のコマンドを利用します。

C:\Windows\system32> mountvol
C:\Windows\system32> mountvol z: /S
C:\Windows\system32> mountvol z: /D
C:\Windows\system32> mountvol z: \\?\Volume{874c2b19-1ada-4089-9a27-de7f61f38177}\
C:\Windows\system32> mountvol z: /D

mountvol.exe コマンドですが、オプションなしで実行するとヘルプと、下のほうにボリュームの一覧が表示されます。表示された UUID が上から順に Volume0,1,2,3,4 みたいな感じなので。色々マウントして確認してみると良いでしょう。

Windows10 が作成した EFI パーティションを z:\ に mount する場合には二行目のコマンドを打ちます。
FreeBSD のインストール時に作成した EFI パーティションをマウントするには四行目のコマンドを利用します。 mountvol のオプションなしで実行した場合に下のほうに「現在のマウントポイントとボリューム名の考えられる値:」で表示されたマウントポイントの *どれか* を指定します。
diskpart.exe の list vol や list part と見比べてじっくりと判断してください;-)。

ちなみに mountvol z: /D は umount するオプションです。

今回は FreeBSD インストール時に作成した EFI パーティションは利用せず、Widnows10 側の EFI パーティションを利用します。

C:\Windows\system32> mountvol
C:\Windows\system32> mountvol z: /S
C:\Windows\system32> z:\
z:\> mkdir EFI\FreeBSD\Boot 
z:\> cd EFI\FreeBSD\Boot 
z:\> copy c:\boot1.efi ./bootx64.efi
z:\> dir
z:\> c:\
C:\Windows\system32> exit

mountvol で Widnows10 の EFI パーティションを z: に mount します。 z:\ に行くと既に EFI というディレクトリが掘られています。そこに FreeBSD 用のディレクトリを作成し、c:\ に置いた boot1.efi という FreeBSD から引っこ抜いてきたファイルを bootx64.efi として保存します。
途中、ls ではなく dir コマンドで色々確認しつつ作業を行ってください。設置場所は bcdedit コマンドで指定した device と path の各オプションと一致していることが重要です。

ちなみに mountvol で EFI パーティションをマウントしていると bcdedit /enum firmware で確認した場合の device パラメータの表示が変わってきます。 mountvol で mount している状態のほうが確認しやすいです。

さてと。これで全ての準備が整いました。Windows10 側でリブートしましょう。 /addfirst を指定した場合は NotePC 再起動後にスルスルっと FreeBSD が起動するようになります。

やったっ!!

もし FreeBSD が起動しなかった場合は bootx64.efi の設置場所が bcdedit で指定したものと合っているかじっくりと確認してください。

僕の場合ですが、大失敗・・。 copy c:\boot1.efi ./bootx64efi とやっていました・・。orz
これじゃ起動しません。rename bootx64efi bootx64.efi として事なきを得、無事に FreeBSD が起動したのでありました。ふぅ。そして、パチパチパチ。

6. 電源投入で FreeBSD 起動
さてと。僕の場合 ThinkPad E145 は FreeBSD メインで利用し、時々 Windows10 を利用する形態なので bcdedit /set {fwbootmgr} displayorder {UUID} /addfirsst で登録しました。これだと電源投入後はサクっと FreeBSD が起動します。

Windows10 を起動したいときには NotePC の電源投入後に F12 キーを押してブートセレクタを表示して「Windows Boot Manager」を選択すると Windows10 が起動するようになります。

さてと。最後に FreeBSD 12.0-RELEASE についてちょっと書いておきます。

今まで僕はずっと BIOS+MBR な FreeBSD しか使ったことがなかったのですが、今回初めて UEFI+GPT な FreeBSD を使うことになります。
一番上で書いた /dev/psm0 が resume 後に psm0: failed to get status となって使えなくなった事象は解決しました。やっぱり FreeBSD の ACPI 周りはどんどん UEFI に傾倒して行っているのね。と、再確認できました。

あと、ThunkPad E145 など AMD のグラフィックスチップ使っている PC 限定かもしれませんが、グラフィックスチップは graphics/drm-fbsd12.0-kmod で認識しています。今までは radeonkms.ko を指定していましたが、これを利用するとカーネルパニック頻発です。 amdgpu にしたら安定しました。 UEFI ブートとは相性が良くないみたいですね。 pkg-message にも書かれています。

しかし、 UEFI にしても acpi_video.ko が使えない状態なのは変わらず。なので、ディスプレーの明るさは変えられません。 AMD グラフィックスチップの悲劇か・・。

とまぁ、ツラツラと書いてみましたが UEFI+GPT にした PC において Windows と FreeBSD のマルチブートについて書いてみましたが、大きな点としては

1). bsdinstall は Windows 側の EFI パーティションを潰してしまう
2). 「Windows Boot Manager」ではなく「Firmware Windows Boot Manager」でマルチブートを実現

でしょうかね。

1). のほうは僕も過去に実はずいぶんとハマりました。どうして Windows10 が起動しないのだっ!!?? みたいな・・。知っている人はちらほらいるみたいですが、僕は Slack のとあるコミュニティで FreeBSD のエラい人に教えてもらいました。 FreeBSD のインストールのために EFI パーティションを一個作成する。ってことがミソですね。

ちなみにですが、/boot/boot1.efifat が、ここで書いてきた FreeBSD インストール前に作成した EFI パーティションの中身です。
bsdinstall が Windows10 側の EFI パーティションを boot1.efifat で上書きしています。 FreeBSD インストール前に EFI パーティションを作成すると bsdinstall は FreeBSD インストール前に作成した EFI パーティションに対して /boot/boot1.efifat が書き込まれ Windows10 側の EFI パーティションは無傷です。

mountvol z: \?\hoge\ で FreeBSD 側 EFI パーティションも mount できるので確認してみるのも良いかも。

2). のほうはある意味目ウロコですね。 Windows Boot Manager を捨ててその一個前のフェーズで FreeBSD をブートしてしまう。 grub とか、他のブートマネージャは不要で bcdedit でなんとかしてしまう。ってことになりますね。

FreeBSD インストール前に EFI パーティションを一個作って、 bcdedit /enum firmware のコマンド群で制御。

この二つが今回は大きな収穫でした。これで UEFI な PC でもマルチブートは大丈夫っ!! 新しい NotePC 買おうかなー;-)。

thunderbird-60.6.1 を日本語化。

4月 082019

FreeBSD の ports-current を追いかけていると www/firefox と mail/thunderbird は i18n な ports/packages が削除されたことが解ります。
なので、firefox や thunderbird をインストールした人は各個人で Japanese Language Pack をアドオンからインストールしてね。と、いうことになるのでありますが・・。

それにしても thunderbird のアドオンから言語パック (Japanese Language Pack のこと)をダウンロードしようにも 52 のままで新しい thunderbird-60.6.1 に対応したものが見つかりません。

困ったのぉ・・。と、いうことで、どーすんべ・・。などと悩んだのですが Linux 方面から持ってくることを思いつきました;-)。

ちょいと調べてみると ubuntu 方面のモノが使えそうです。と、いうことで以下のサイトにアクセスして ubuntu の deb パッケージをダウンロードします。

https://packages.ubuntu.com/ja/xenial/amd64/thunderbird-locale-ja/download

僕は thunderbird-locale-ja_60.6.1+build2-0ubuntu0.16.04.1_amd64.deb というのをダウンロードしました。

これを適当なディレクトリで展開します。 FreeBSD の tar はなんでもかんでも xvzfp で展開できるのが嬉しいですねぇ;-)。

$ mkdir deb
$ cd deb
$ wget http://security.ubuntu.com/ubuntu/pool/main/t/thunderbird/thunderbird-locale-ja_60.6.1+build2-0ubuntu0.16.04.1_amd64.deb
$ tar xvzfp thunderbird-locale-ja_60.6.1+build2-0ubuntu0.16.04.1_amd64.deb
$ tar xvzfp data.tar.xz
$ cd usr/lib/thunderbird-addons/extensions/
$ cp -pr langpack-ja@thunderbird.mozilla.org.xpi ~/.thunderbird/乱数.default/extensions/
$ thunderbird
$

以上です。

1. ubuntu の deb パッケージから Japanese Language Pack を引っこ抜きます。
2. それを自分の thunderbird の環境の extensions/ の中に入れます。
3. thunderbird を起動し Japanese Language Pack を enable して再起動します。

以上で FreeBSD の thunderbird-60.6.1 でも日本語対応することができるのであります;-)。

当分の間は、thunderbird のバージョンアップを繰り返すごとに上記を実行する必要があるかなぁ・・。

japanese/thunderbird-langpack-ja/ なんて ports 作っても、きっと却下されるんだろうなぁ。ノラ ports でも作るかなぁ;-)。

以前のエントリー新しいエントリー

		running-dog.net。しかし、自分が一番落ち着かない。かけまわっている子犬のような状態。そんな毎日をブログで綴ってみました。 FreeBSD・MacOSX・UNIX・PC・プログラム・iPhone(iOS)・Android ネタなど技術的・趣味的なネタについて色々書いてみたいと思います。
		From 18.188.20.56

2024年4月
日	月	火	水	木	金	土
	1	2	3	4	5	6
7	8	9	10	11	12	13
14	15	16	17	18	19	20
21	22	23	24	25	26	27
28	29	30