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 のバージョンが上がったら、もう一回エントリ書くことになるのかなぁ?

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 part
DISKPART> 
DISKPART> create partition efi size=100
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). いよいよ create partition で EFI パーティションを 100MB で作成
5). fat32 でフォーマットして、ラベルは FreeBSD-EFI とする (お好きな文字列をどうぞ)
6). 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 コマンドですが、オプションなしで実行するとヘルプと、下のほうにボリュームの一覧が表示されます。
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 買おうかなー;-)。

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 でも作るかなぁ;-)。

3月 152019
 

このサイトはさくらのレンタルサーバ上にあるので自分の力で apache の設定を変えられはしないので、さくらの VPS 上で運用している icmpv6.orgmotsuyaki.org を HTTP/2+TLSv1.3 に対応させてみました。

どちらのサイトも基本的に写真掲載付きのブログ(とわ言いつつ、最近バッタリ更新が止まりましたが・・)なので、写真とかドドドとあり、一回アクセスで大体 40 個くらいファイルを持っていくんではないかなぁ。と、思います。そんな感じなので HTTP/2+TLSv1.3 は非常に効果的ではないかと思われるわけであります。

HTTP/2+TLSv1.3 に対応するためには色々と準備が必要です。ここでは FreeBSD/amd64 12.0-RELEASE 上で動作している環境を HTTP/2+TLSv1.3 にしてみたいと思います。

1. FreeBSD の準備
手間を掛けたくないのであれば FreeBSD 12.0-RELEASE を用意しましょう。なぜかと言うと、それは OpenSSL のバージョンに関係するからです。
11.2-RELEASE の openssl は以下のバージョンで HTTP/2+TLSv1.3 に対応していないんですね。

$ openssl version
OpenSSL 1.0.2o-freebsd  27 Mar 2018

 
対して 12.0-RELEASE は以下のように表示されます。

$ openssl version
OpenSSL 1.1.1a-freebsd  20 Nov 2018

 
HTTP/2+TLSv1.3 に対応するためには OpenSSL は 1.1.0 以上のバージョンが必要です。

しかし、FreeBSD/amd64 12.0-RELEASE もまだまだ問題があってサーバとしては中々利用しづらいですよねぇ・・。
12.0-RELEASE の問題点はパッと思いつくだけで、

・NTT フレッツ回線を利用、IPv6 での通信時に ssh が利用できない
・shutdown -p now で、電源が落ちない PC がある
・drm-fbsd12.0-kmod はカーネルパニックするときがある(割と頻繁)

僕が直接的に感じたのはこれくらいでしょうか。まぁ、最後のは X が必要なのでサーバにはあまり関係ないですが・・。

 
FreeBSD 11.2-RELEASE を利用する場合には個別に OpenSSL をバージョンアップする必要があります。 ports に security/openssl111/ があるのでそれをインストールするのが良いかも知れませんが、僕は試していません。

 
2. apache24 の環境
FreeBSD の準備が整ったのでいよいよ apache24 の設定を見ていきます。

ports で www/apache24/ をインストールしますが、make config のときに [X] HTTP/2 と [X] SSL は当然として、さらにもう一個設定してあげる必要があります。

「Build enabled SESSION modules」のところで (*) MPM_EVENT を指定してあげる必要があります。

MPM_EVENT を指定すると httpd はマルチスレッドで動作することになるので WordPress などを利用している場合、php (僕は lang/php73/ を利用している) は [X] ZTS 付きでコンパイルし直す必要があります。

以上で準備 apache24 のが整いました。

 
3. apache24 の設定
HTTP/2+TLSv1.3 の設定をします。あちこちにファイルが散りばめられておりますな。

o. /usr/local/etc/apache24/httpd.conf

LoadModule ssl_module libexec/apache24/mod_ssl.so
LoadModule http2_module libexec/apache24/mod_http2.so
LoadModule mpm_event_module libexec/apache24/mod_mpm_event.so

 
上記モジュールの設定が必要です。他に SSL を有効にするとか色々あるのですが、その辺りは割愛します。

あと、既に ports から www/apache24/ をインストールしていて httpd.conf を編集している状態の場合、MPM_EVENT を有効にして make && make deinstall && make reinstall した場合は mpm_event_module の設定が httpd.conf に現れません。
『あれ? MPM の設定はどこでしているのだ?』となるのですが、そのときは /usr/local/etc/apache24/modules.d/ の下の 000_mpm_prefork_fallback.conf を見ましょう。ここで mpm_prefork_module をロードしているので、その部分を mpm_event_module に書き換えてあげる必要があります。

o. /usr/local/etc/apache24/modules.d/000_mpm_prefork_fallback.conf

#LoadModule mpm_prefork_module libexec/apache24/mod_mpm_prefork.so
LoadModule mpm_event_module libexec/apache24/mod_mpm_event.so

 
ports からインストールし直した apache24 の設定の場合、これで大丈夫;-)。

o. /usr/local/etc/apache24/extra/httpd-ssl.conf

  :
その他の SSL の設定は略
  :
SSLProtocol -ALL +TLSv1.2 +TLSv1.3

<VirtualHost *:443>
      :
    その他の SSL の設定は略
      :
    SSLEngine on
    SSLCertificateFile    "/usr/local/etc/apache24/SSL/CRT.crt"
    SSLCertificateKeyFile "/usr/local/etc/apache24/SSL/KEY.key"

    ErrorLog  "/var/log/ssl_error.log"
    CustomLog "/var/log/ssl_access.log" common
    CustomLog "/var/log/ssl_request.log" "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"

    Protocols h2 http/1.1
</VirtualHost>

 
HTTP/2+TLSv1.3 にするので SSLProtocol で +TLSv1.3 してあげるのは当然でしょうかね。あとは VirtualHost ディレクティブの中で、最後に書いてある Protocols h2 http/1.1 を記述します。

これで良いのですが、SSL でアクセスがあったときに本当に TLSv1.3 でアクセスしているのかログを残したいためエラーログ・アクセスログの他に ssl_request.log というのを出力するように設定しました。
自分のブラウザからアクセスして TLSv1.3 でアクセスできているか、確認することができます。

 
とまぁ、設定はだいたいこんな感じでしょうか。 SSLCipherSuite をより強固にしてみる。なんてチューニングも良いかもですね。僕の場合は以下のように設定しています。あ、設定する場合は改行なしで一行で書いてください。

SSLCipherSuite \
ECDHE-RSA-AES128-GCM-SHA256:\
ECDHE-RSA-AES128-GCM-SHA:\
ECDHE-RSA-AES128-SHA256:\
ECDHE-RSA-AES128-SHA:\
ECDHE-ECDSA-AES256-GCM-SHA384:\
ECDHE-ECDSA-AES256-GCM-SHA:\
!LOW:!MD5:!aNULL:!eNULL:!3DES:!EXP:!PSK:!SRP:!DSS:!ADH:!DH

 

 
と、まぁ、こんな感じで準備が整いました。あとは apache24 を restart してアクセスしてみて ssl_request.log を覗いてみると TLSv1.3 で、どの暗号スイートを利用していて HTTP/2 でアクセスしている。と、いう情報が確認できるかと思います。

それにしても、ウェブページの表示は速くなったのか? と、聞かれると、実測はしてないですが、感覚的に『多少速くなったかな?』みたいな雰囲気ではありますf(^^;;。

9月 232018
 

KDE5 をインストールして、最近色々遊んでいるところです。デスクトップにも NotePC にもインストールしたので利用頻度はグググと上がりました。

そんなこんなで色々遊びつつ・調べつつしていたら latte-dock というのを発見しました。 KDE5 のパネルの代わりになるシロモノです。 FreeBSD の ports 的には deskutils/latte-dock になります。

まずはキャプチャを;-)。

レイアウトは My Layout・Plasma・Unity の、全部で三種類から選べます。 My LayOut は macOS 風、 Plasma は KDE5 の default のパネル風、 Unity というのは NextStep のランチャー風で、macOS の上にあるステータスバーみたいなのも表示されます。上記キャプチャはMン Layout でドックの設定で配置してみました。

KDE5 のウィジェットはガシガシ登録できるし、プログラムのショートカットも登録可能です。 KDE5 の標準のパネルが macOS 風になった。と、いういう認識で問題ないかと思われます。と、いうのも macOS と一緒でマウスオーバーするとアイコンがズズズと大きくなります。おぉっ!!

そして、ドックの上で右クリックすると設定画面が現れてことこまかに色々と設定することができます。設定画面ではドックとして利用したときのアイコンサイズのだとか、ウィンドの下に隠れるとか、 3D や影を付けたり、現在利用中のアプリのアイコンを光らせたりとか。

フツーの KDE5 のパネルではつまらないと思う人は是非とも体験してみてください;-)。

ただ、一部動作が多少怪しいと思う点が、使い込むほど出てきているので、今使っているパネルは小さいままデスクトップ上に置いといたほうが良いかもです。バージョン 1 が出たときには安定してくれていると嬉しい;-)。

 
それにしても KDE3 の頃だったか? パネルのアイコンが OS X (当時) 風に、普段は小さいのにマウスオーバーで大きくなったりする機能を持っていたんだけど Apple からクレームが入りその機能がなくなって、マウスオーバーしてもアイコンサイズが変わらなくなってしまった。と、記憶しています。 KDE 本体から分離したプロジェクトとして用意された latte-dock ではその機能が復活している。と、いうのはなんだか感慨深い;-P。

 
さてと。話が横道にそれましたが、設定画面のキャプチャを掲載しましょうかね。

僕の設定は日本語表示されています;-)。 この latte-dock というのは gettext で po ファイル化されているので独自に翻訳してみました。もうちょっと精査したあと kde-jp@kde.org に送る予定なので、次のバージョン辺りから最初から日本語化対応になっているのではないかと思われます。

あ。このブログでは何回か書いていますが僕は JKUG のメンバでもあるので、 KDE 自体の翻訳は特に気にはならずに Opendesktop.org に協力している次第です。

それにしても先行して日本語 po/mo フアイルが欲しい方は以下の URL に置きましたので持って行ってください。

https://icmpv6.org/Prog/ja.po/latte-dock-0.8.1-po-ja.tgz

deskutils/latte-dock を ports からインストールしたあと、ダウンロードした tgz を展開して、その中にある mo ファイルを /usr/local/share/locale/ja/LC_MESSAGES/ にほーりこんで latte-dock を再起動すると設定画面が日本語化されます。

日本語化されていたほうが設定しやすいとは思うのですが、一部へんちくりんな日本語や機能的に間違っている部分があるかと思われますが、随時更新して行きたいと思います。

9月 172018
 

KDE の 4 や 5 を使っていると ps -ax とか打つと気が滅入るときがあります。『どうしてこんなにakonadi が起動しているのだっ!?』と。まぁ、 akonadi は kdepim 系のユーザ情報管理や各種サービスへのアクセスを一手に引き受けているのでさまざまなプロセスが動くのはしょーがいなのではありますが・・。

akonadi はバックエンドにデータベースを利用していて、必要な情報はそこに格納します。選べるのは全部で三つ。 MySQL・PostgreSQL・SQLite3 ですね。 KDE4 の頃は複数のプロセスからアクセスするとデータベースがぶっ壊れるから MySQL を使え。と、いうお達しが出ていて、『まじかよー。デスクトップのバックエンドに mysqld 動かすんかよぉ・・。orz』などと思っていたのですが、 KDE5 からはいよいよ純粋に上記三つのデータベースが選択可能になったようです。

と、いうことで ports の databases/akonadi をインストールする場合は以下のようにオプションを選択すると良いでしょう。

今回は非常に負荷の軽い SQLite3 をチョイスしました。この状態で akonadi をコンパイルすると関連性により databases/qt5-sqldrivers-sqlite3 がインストールされます。 akonadi が利用するデータベースドライバですね。
ちなみに MySQL を選択すると databases/qt5-sqldrivers-mysql がインストールされます。

これで今日は akonadi は SQLite3 を利用するようになる。わーいっ!! などと喜んではいけません。 akonadi は今でも default で MySQL を利用するようになっているので、設定を変更して上げる必要があります。

設定変更するファイルは ${HOME}/.config/akonadi/akonadiserverrc になります。 akonadi を一回起動(しようと)すると生成されます。

[Debug]
Tracer=null

[%General]
Driver=QSQLITE3

[QSQLITE3]
Name=/home/USERNAME/.local/share/akonadi/akonadi.db

 
起動直後は [%General] では Driver=QMYSQL と書かれていると思いまずが、これを上記のように変更し、更に [QSQLITE3] を書いてデータベースを指定してあげます。

設定ファイルが完成したら akonadictl restart するか、一回ログアウトしてから再度ログインし直すと良いでしょうか。再度ログインすると mysqld が起動していないのに akonadi が動作しているのが嬉しいですね;-)。

これで mysqld が起動しない分 PC の負荷が多少は軽くったでしょうか? もしかしたら気分的な問題かぁ?

 
では、そもそも akonadi 自体を起動したくない場合はどうするか?

一番簡単なのはコンパイルのオプションで SQLite3 を指定して、設定フアイルである akonadiserverrc には MySQL を利用する設定を記載することです。

databases/qt5-sqldrivers-sqlite3 や databases/qt5-sqldrivers-mysql などがデータベースドライバになるのですが、設定ファイルで選択したデータベースのドライバが無い場合には akonadi が起動しません。

それとは別に [QSQLITE3] や [QMYSQL] の中に StartServer=false と掛けば akonadi が起動しない。と、いう話のようですが、実際に記載した設定ファイルを用意しても akonadi は起動してしまいました。残念。

[Debug]
Tracer=null

[%General]
#Driver=QSQLITE3
Driver=QMYSQL

[QSQLITE3]
Name=/home/USERNAME/.local/share/akonadi/akonadi.db
StartServer=false

[QMYSQL]
Host=
Name=akonadi
Options="UNIX_SOCKET=/tmp/akonadi-USERNAME.73cx0k/mysql.socket"
ServerPath=/usr/local/libexec/mysqld
StartServer=false

 
と、いうことで akonadi のコンパイル時に SQLite3 を指定して、上記のように設定ファイルを記載すると、起動しなくなります。

起動したい場合には [[%General] で Driver=QSQLITE3 を有効にして Driver=QMYSQL をコメントアウトすれば OK です。

これで akonadi がずいぶんと楽しいものになったかな? ;-)。

9月 092018
 

僕が利用している ThinkPad E145 はカーネルがずっと 10.1-RELEASE のままで、ユーザランドが 10.4-RELEASE だったりしていました。これは以前にも書いていますが suspend/resume が動作しなくなる。resume 後にバックライトの調整ができなくなるため、しかた無く。の対応だったんですね。

あと、ThinkPad E145 はグラフィックスカードに Radeon HD 8330 を利用していて、このチップは radeonkms.ko では未対応で Xorg のドライバでは VESA を利用していたんですね。

そして、 KDE5 は 10.4-RELEASE でコンパイルしたものは、コンパイルしたバージョンとは違う 10.1-RELEASE 上では動作しない。と、いうことになり、そろそろ新しい NotePC を買うことを考えていたところに drm-next-kmod がバリバリと動作する。 Radeon HD 8330 も radeonkms.ko で動作するようだ。と、いうので 10.1-RELEASE から 11.2-RELEASE にいっきに上げてみることにしました。

と、ここまでが前振りです(^^;;。
freebsd-update でいっきに 11.2-RELEASE にして pkg delete -a で古い packages を削除したあとに 11.2-RELEASE でコンパイルした KDE5 一式をドドドとインストール。その他 NotePC に必要なモノをインストールします。

そして、今回はそこに graphics/drm-next-kmod をインストールします。 /usr/ports/graphics/ の下を見ると、全部で以下があるようです。

・drm-devel-kmod/
・drm-legacy-kmod/
・drm-next-kmod/
・drm-stable-kmod/

まぁ、見て、雰囲気が大体解ると思われますが;-)。

graphics/drm-next-kmod をインストールすると /boot/modules/ の中がずいぶんとにぎやかになります。

この中から radeonkms.ko を見つけ出してブート時に kldload するように、/etc/rc.conf に設定します。

# --- kernel module load --- #
kld_list="/boot/modules/radeonkms.ko"

 
radeonkms.ko は今回 graphics/drm-next-kmod でインストールしたモノと別にシステム標準の /boot/kernel/radeonkms.ko があります。 /boot/loader.conf に radeonkms_load=”YES” と書くとシステム標準のカーネルモジュールがロードされてしまうため、上記のように記載します。

インストールが完了したあとは /etc/X11/Xorg.conf を編集してあげます。最近は /usr/local/etc/X11/xorg.conf.d/ 内にドライバ・キーボード・マウスなど、個別のファイルを用意して /etc/X11/Xorg.conf は書かない。ってのが流行みたいですねぇ。まぁ、どっちにしろ Section “Device” の項を書き換えます。

Section "Device"
        Option      "TwinView" "true"
        Option      "TwinViewOrientation" "LeftOf"
#       Option      "RegistryDwords" "EnableBrightnessControl=1"
        Identifier  "Card0"
#       Driver      "radeon"
#       Driver      "vesa"
        Driver      "modesetting"
        BusID       "PCI:0:1:0"
EndSection

 
Driver radeon は動作しないので、しょーがない。今までは Driver vesa で使っていたのですが、今回 graphics/drm-next-kmod にしたので Driver modesetting にしました。最近の Xorg は賢くなって色々なモノを自動認識するようになり、デバイスにあったカーネルモジュールをロードしてくれるようです。

と、いうことで上記の設定ができたらリブートしましょう。
リブート後、僕の ThinkPad E145 では以下のカーネルモジュールがロードされるようになりました。 linuxkpi.ko が今回のカナメでしょうかねぇ。

--- <上略> ---
23    1 0xffffffff82421000 15d6d9   radeonkms.ko
24    1 0xffffffff8257f000 74b70    drm.ko
25    4 0xffffffff825f4000 edc8     linuxkpi.ko
26    3 0xffffffff82603000 114b8    linuxkpi_gplv2.ko
27    2 0xffffffff82615000 6b8      debugfs.ko
28    1 0xffffffff82616000 23f8     radeon_kabini_pfp_bin.ko
29    1 0xffffffff82619000 23f8     radeon_kabini_me_bin.ko
30    1 0xffffffff8261c000 23f8     radeon_kabini_ce_bin.ko
31    1 0xffffffff8261f000 43f8     radeon_kabini_mec_bin.ko
32    1 0xffffffff82624000 2a78     radeon_kabini_rlc_bin.ko
33    1 0xffffffff82627000 12e8     radeon_kabini_sdma_bin.ko
34    1 0xffffffff82629000 38eb0    radeon_bonaire_uvd_bin.ko
35    1 0xffffffff82662000 13328    radeon_BONAIRE_vce_bin.ko
36    1 0xffffffff82676000 37528    linux.ko
37    2 0xffffffff826ae000 2d28     linux_common.ko
38    1 0xffffffff826b1000 31e50    linux64.ko
--- <以下略> ---

 
Xorg を起動し、ログインマネージャの x11/sddm を起動し KDE5 にログインします。そして、 「KDE システム設定」から[ディスプレイとモニタ]->[Compositor]ときて、[レンダリングバックエンド]を確認します。VESA ドライバを利用していたときは選択できるのは xdandr のみだったのですが、今は OpenGL2.0 や 3.1 が指定できます。おぉっ!! これで 「ゆれるウインド」とか「魔法のランプ」などが利用できるようになるっ!!

ってんで、 graphics/drm-next-kmod の恩恵が受けられるのでありました。

 
で、次のステップですが、 まだ、以下の二点が残っております。

・suspend/resume はちゃんと動くの?
・バックライトの明るさ調整はできるの?

まず、suspend/resume についてですが、最初の 1,2 回はフタを閉じた段階でシステムごとフリーズしていたので『むむむ。 graphics/drm-next-kmod は suspend/resume に対応してないのか?』などと思ったのですが、ロードするカーネルモジュールとかその他設定を見直すことで無事に suspend/redume が動作するようになりました。

ThinkPad E145 では acpi_video.ko はまともに動作してないので利用していません。 acpi_ibm.ko はバックライト調整はできないけどボリューム調整はできるのでロードしています。

 
次にバックライト問題ですが、これは、本家でも wiki の掲載があるほどなので、ことは一大事なのでしょうなぁ。

https://wiki.freebsd.org/Graphics/Brightness

ここに書いているのは一通り試しました。上にも書いた通り ThinkPad E145 は Radeon HD 8330 なので intel_backlight (ports 的には graphics/intel-backlight) を使うと Device not found. です。あら。つべたい。

accessibility/sct はオプションの数値を変えると色が変わるので、 LCD brightness とはちょっと違う。

で、結局、僕は xrandr を使うことにしました。xrandr は VESA ドライバを利用している頃はまともに動作しなかった (Can’t open display と表示される) のですが、 graphics/drm-next-kmod を使うと無事に動作するようになりました。

まず、以下のコマンドを打ってディスプレー名を取得します。

$ xrandr --listmonitors
Monitors: 1
 0: +*LVDS-1 1366/256x768/144+0+0  LVDS-1

 
最後の LVDS-1 が重要で VESA ドライバを利用していた頃はこの値が表示されず xrandr で明るさの調整ができなかったんですね。今回 graphics/drm-next-kmod を利用することによりちゃんと動作するようになりました。ここまで来ればラクショーです。あとは以下のようにコマンドを打って画面の明るさ調整をすれば良いだけ。

$ xrandr --output LVDS-1 --brightness 0.8

 
今動作している明るさが 1 で、それよりも暗くしたい場合は 1 以下の数値を小数点で指定し、更に明るくしたい場合は 1.2 とか指定すれば良いです。

雰囲気的には機械的にバックライトを調整するのではなく、画面の色をグレーにすることで暗くなったように見える。と、いう機能ですね。ハードウェア的にバックライトを暗くしてないのでバッテリー運用のときは要注意って感じでしょうか。

 
と、いうことで CPU/GPU 共に AMD な NotePC である ThinkPad E145 ですが、

・11.2-RELEASE にした
・graphics/drm-next-kmod で Radeon HD 8330 を認識してくれる
・KDE5 が使えるぞぉ (これは当たり前;-)
・suspend/resume ができる
・バックライト調整も一応できる

と、いう状態になり、ほぼほぼ満足な結果です。細かく言うと

・キーボードが 101 のままだぁ
・マウスの動作があやすぃー
・音の出るところ調整(スピーカーかイヤホンか)

など、ありますが、それらは Xorg の設定で調整するもヨシ。KDE5 側で設定するもヨシ。と、いう状態なので、道は色々あります。それらを一応全て解決できたので、僕の ThinkPad E145 は壊れなければあと 4,5 年は持つような気がしてきました;-)。

5月 202018
 

最近の ports-current を追いかけていると、統合デスクトップ環境 (懐かしい響きだ;-) に KDE4 を利用している人にとっては、関連性からインストールする packages が xxx-kde4 へと、名前が順次変わっていたので『むむむ。そろそろ KDE5 が降ってくるのか?』などと思っていたら、果たしてその通りで x11/kde5 と、いうのができました。

デスクトップが更新されたのはずいぶんと久しぶりだなぁ。以前のこのブログのエントリに「FreeBSD に KDE4.1 がやってきた。」と、いうのを書いているのですが、それが 2008 年 08 月ですね。約 10 年ほど KDE4 を使い続けた。と、いうことですが、このたび KDE5 に移行しました。今回のネタは FreeBSD で利用する KDE5 について、少々書いてみたいと思います。

 
それにしても 10 年も経つと色々なことが変わりつつあります。そもそも、今でもデスクトップ環境として FreeBSD+xorg を利用している人は何人くらいいるのでしょうか? このエントリを書いて、ちゃんと読んでくれて、設定を方法を見てくれる人がどれくらいいるのでしょうか? 不安です・・f(^^;;。

が、まぁ、しかし、初めてみましょう。

 
1). インストール
まぁ、簡単で ports の x11/kde5 を make install すれば良いだけです。make config で好きなモノを設定していけば良いでしょう。
ただし、KDE4 からのアップグレードの場合、KDE4 に関連する packages は全て削除しましょう。 KDE4 と KDE5 の ports/packages では confrict が発生し、 make install が途中で止まったりします。

インストールは qt5- ・ kf5- ・ plasma5- で始まるモノがドドドとインストールされます。 akonadi はまだ動かないようですね。なので korganizer やkmail などは動きませんし、インストールされません。 okular は QT4 ライブラリがくっ付いているのでインストールする気にもなれません。これらは 18.04.1 のバージョンで多分解決するのではないかな。と思われます。
オフィスアプリは calligra-3.1.0 よりも libreoffice のほうが良いでしょう。

あと、KDE5 や Qt5 では日本語言語パックがなくなりました。フツーにインストールすると i18n 対応です。一応、 devel/kf5-ki18n がインストールされているかだけ、確認しておきましょう。

ports から make すると PC の性能にもよりますが 40 時間程度でインストールされると思います;-)。

 
あと、ウィンドマネージャとしての kdm がなくなりました。変わりに sddm というのを利用します。 kde5 インストール時に関連性でインストールされないので、後から x11/sddm と deskutils/plasma5-sddm-kcm をインストールしましょう。

起動については kdm4 と一緒です。 /etc/rc.conf に以下のように記載すれば OK です。

sddm_enable="YES"
sddm_lang="ja_JP"

 
sddm は一回起動すると /usr/local/share/sddm/scripts/Xsession というログイン時のスクリプトを生成します。自分好みの起動にしたい場合はこのファイルを直接直しちゃいましょう;-)。

インストールについてはだいたいこんな感じでしょうかねぇ。

 
2). 環境構築。
sddm から左上の「セッション」から “plasma” を選択すると上記 sddm の Xsession から startkde が実行され、デスクトップが表示されます。
“User Session” を選択すると ${HOME}/.xsession が動き出します。

起動後についでてすが、 KDE4 を利用していた場合は ${HOME}/.kde4/ に設定ファイルが置かれていましたが、 KDE5 では ${HOME}/.config/ にバラけて入るようになりました。
僕の場合は、ややこすぃーのがイヤなので KDE4 の設定は引き継がず、新たに KDE5 の設定ファイルが新規に生成されるようにしました。しかし、KDE5 になっても ${HOME}/.kde/ に設定ファイルを置くプログラムが何個があるようですね。

KDE5 のデスクトップ環境は「KDE システム設定」 (systemsettings5) で様々な設定をします。

僕は「KDE システム設定」->「起動と終了」->「自動起動」から「スクリプトファイル」で以下を実行するようにしました。環境変数と X のキーボード周り、あと、言語設定などですね。

#!/bin/sh
# XmodMap Sesource Setup
Xkeybord=$HOME/.xmodmaprc
if [ -f $Xkeybord ]; then
        /usr/local/bin/xmodmap $Xkeybord > /dev/null
fi
UsrResource=$HOME/.Xresources
if [ -f $UsrResource ]; then
        /usr/local/bin/xrdb -load $UsrResource
fi

# Start some clients
xset s 300 300 &
xset s noblank &

export LC_TIME=C
export LANG=ja_JP.UTF-8
export LC_CTYPE=ja_JP.UTF-8

export TZ=JST-9

export TERM=xterm
export UNICODEMAP_JP=cp932

# Session Type Select
export KDE_UTF8_FILENAMES=true
export KDE_LANG=ja_JP.UTF-8
export QT_XFT=true
export GDK_USE_XFT=true

## IME Start
#export QT_IM_MODULE=xim        # Qt4 用設定
export QT_IM_MODULE=fcitx       # Qt5 用設定
export GTK_IM_MODULE=xim
export XMODIFIERS=@im=fcitx

exec /usr/local/bin/mozc start
exec /usr/local/bin/fcitx

# Other Wakeup Programs
# gkrellm
Gkrellm="/usr/local/bin/gkrellm"
if [ -f $Gkrellm ]; then
    exec $Gkrellm &
fi
# Emulate3Button
Xkb2mb2="/usr/local/bin/kb2mb2"
if [ -f $Xkb2mb2 ]; then
    exec $Xkb2mb2 -c 117 &
fi

 
日本語入力は fxitx+mozc を利用しています。 fcitx は Qt5 用に textproc/fcitx-qt5 をインストールする必要があります。そして、環境変数の設定方法も変わっています。

fcitx 自体は今でも GUI 部分に Qt4 ライブラリを利用しています。うーむ。早いところ Qt5 に移行してほしいなぁ。 fcitx5 というのがリリースされているので、早いところ FreeBSD の ports になってほしいモノです。
ちなみに japanese/mozc-tool は Qt5 に移行しています。

文字をベコベコ打っていると、キーボードが 101 形式であることがわかります。 106 キーボードに変更する人は「KDEシステム設定」->「入力デバイス」->「キーボード」から設定します。一番最初に表示される [ハードウェア] タブにのキーボードモデルには 106 キーボードが無いんですね。その横にある [レイアウト] タブの「レイアウトを設定」にチェックを入れて JP 日本語キーボードを新規に登録する必要があります。

以下、キャプチャです。

こんな感じでキーボードを登録すると KDE5 側でも 106 キーボードが利用可能です。 X の twm などでは 106 キーボードが使えるのに KDE5 を起動すると 101 キーボードになってしまうので困ってしまうですねぇ。

 
もっと困ったのがマウスでした。僕の場合 Apple が推奨する Natural Scroll 、それは俗にいうホイールの逆回転ですね。これが動かない。
「KDEシステム設定」->「入力デバイス」->「マウス」に『スクロール方向を逆にする』という項目があり、チェックを入れても逆になりません。あららぁ・・。

色々調べてみると KDE5 からは libinput というのがマウスを管理しているようです。ports 的には x11-drivers/xf86-input-libinput です。 xorg.conf の設定で以下のような感じで用意してあげれば動くようなのですが、 Linux のドキュメントはたくさんある。しかし、 FreeBSD のドキュメントは全く無いっ!!

FreeBSD のフツーの X の使い方では xf86-input-libinput は利用されません。

Section "InputClass"
        Identifier "libinput pointer catchall"
        MatchIsPointer "on"
#        MatchDevicePath "/dev/sysmouse"
        Driver "libinput"
        Option "NaturalScrolling" "true"
EndSection

 
詳細についてはインターネット上にある libinput のドキュメントを読んでください。Linux の場合は /dev/input/event* なるデバイスができるようですが、 FreeBSD の場合はそれができない。デバイスではなく MatchHoge でも装置を認識するようです。装置名などにマッチさせることもできるパラメータで何種類かのマッチ要素があるようです。装置を確認するには xinput list で特定するらしいです。

が、そもそも、現在の FreeBSD (少なくとも僕の環境) では libinput は Xorg で利用されないため必要ないようです。なので、この設定自体は無視してかまいません。

では、どうやってマウスのホイールを逆回転するか? いやはや。古典的な設定で実現しました。

 
o.回避策そのいち (xorg.conf)

Section "InputDevice"
    Identifier     "Mouse0"
    Driver         "mouse"
    Option         "Protocol" "auto"
    Option         "Device" "/dev/sysmouse"
#   Option         "ZAxisMapping" "4 5 6 7"
    Option         "ZAxisMapping" "5 4 6 7"
EndSection

 
o.回避策そのに (${HOME}/.xmodmaprc)

pointer = 1 2 3 5 4 6 7 8 9 10 11 12

 
マウスのスクロールボタンは 4,5 なので、その値をひっくり返すことにより対応しました。 KDE5 の設定でなんとかしようとせずに X の設定で対応した。と、いう感じでしょうか。これで、マウスの設定も完了です。ふぅ。

 
僕的にはこれで KDE5 を楽しむことができるようになりました。

 
3). 使ってみる。
KDE4 から KDE Plasma5 になり、画面の雰囲気がガラっと変わり、全体的に明るくなりました。ベースのワークスペースのテーマは Breeze というのになりました。そのおかげでちょっと明るめの気配かな。使用感は KDE4 と遜色ないです。

 
気がついた問題点を少々。

 
o.ディスク IO 負荷が高い
ログインしてしばらくすると /usr/local/bin/baloo_file_extractor が動き出します。これはデスクトップのフル検索のための情報収集プログラムだと思われます。 macOS で言うところの mdworker のようなモノですね。こいつが動いていると KDE5 がやたらと重いのでプロセスを kill してかつ、「KDEシステム設定」->「検索」から「Enable File Search」のチェックをはずすとフツーの速さに戻ります。

 
o.今まであったアプリがない
上にも書いた通り、FreeBSD だけかもしれませんが、まだ akonadi が無いためにオフィス系アプリはほとんどありません。別途インストールする必要があります。もしくは 05/19 以降の ports-current を利用するのが良いかと思われます。

あと、このエントリ書くためにスクリーンキャプチャ (スクリーンショット) を撮ろうとしたんだけど、グラフィックスのメニューの中もずいぶん静かで、ありませんでした。
で、調べてみると、なんとっ!! PrtScr ボタンを押すと起動するんですね。 Windows みたいだ。で、実態はというと /usr/local/bin/spectacle が起動するので、メニューに登録してあげると良いでしょう。 (よくよくメニューを眺めてみると「ユーティリティ」の中にありました)

 
o.konqueror は相変わらずか?
レンダリングエンジンが KHTML から Webengine に変わっていますが、firefox に比べて軽いブラウザなので嬉しいです。が、SSL なサイトは相変わらず閲覧できないのは KDE の証明書ライブラリが相変わらずぶっ壊れているからか?

 
とまぁ、ダラダラと書いてみましたが、一番最初にも書いた通り、約 10 年ぶりのデスクトップ環境のアップデートです。嬉しいですねぇ。途中 KDE4 が重くて xfce4 をインストールしたこともありましたが、やはり KDE は良いですねぇ。

Gtk2/3 の角ばった雰囲気よりも Qt4/5 の丸っこいアウトラインが好きだし、そー考えると GNOME はもう 8 年くらい触ってないし。

などと、書いていますが、皆さんも是非 KDE Plasma5 をお試しください;-)。

4月 302018
 

ゴールデンウィークの前半に秋葉原に NVIDIA GeForce GT 720 と 1TB の 3.5 インチの HDD を買いに行きました。古い PC (Athlon64 X2) で FreeBSD を動作させるためですね。
FreeBSD の場合 AMD (ATI) のビデオカードより ports の x11/nvidia-driver-340/ で動作する NVIDIA の NIC のほうが安心して 3D グリグリできるんですね。

で、お買い物終了後、アキバ散策していたら、新しくジャンク屋さんがオープンしていたのでちょっと覗いてみました。そしたらなんとっ!! PCI のグラフィックスカードの新品が 200yen で売っていたので購入してしまいました。当然ジャンク扱いですが。

購入したのはこんな感じ。もう一度繰り返しますが 200yen で、新品です;-)。

グラフィックスチップは往年の ATI の Rage XL です。メモリ 8Mbyte だそうです。うひひ。

今回再利用しようとしている古い PC には PCI スロットがあるので、この 200yen のグラフィックカードで X が表示できると嬉しいなぁ。などと思い、早速試してみました。

# X -configure
...

 
あらら・・。残念ながら、Xorg の -configure では自動的に xorg.conf を生成してくれないようです。挙句のはてには vesa ドライバが選択されました。
古いビデオカードは X -configure で xorg.conf が生成されないのかななぁ・・。

あと、サイズ的にはフル HD の 1920×1080 サイズで表示して欲しいんですけど・・。

やっぱりメモリ 8MB のグラフィックカードでは無理かなぁ?

あまり、格闘せずにさっさと NVIDIA GeForce GT 720 にしてしまったけど、あきらめがちと早いかな。まぁ 200yen だしなぁ・・。

 
話は突然変わりますが、今回購入した NVIDIA GeForce GT 720 を PRIMERGY MX130 S2 の PCI-e BUS にさして電源投入してみましたが、一回 BIOS 画面が出ただけで、まともに表示してくれませんでした。
今まで NVIDIA GeForce GT 210 を利用していたときは無事に起動してくれていたのですけどねぇ。多分電力量の不足が原因なのでしょうなぁ。 AMD FX-6100 な 6Core の CPU 載っているしなぁ。

と、いうことで古い PC の再利用は NVIDIA GeForce GT 720 で決定です。

3月 292018
 

以前のエントリで「FreeBSD で if_urtwm を使ってみる。」と、いうエントリを書いているのですが、今回はそれの続編です。と、いうか、僕は USB の Wi-Fi ドングルが好きなようで、今までにもこのブログでは何回か書きました。

最近は REALTEK の USB Wi-Fi ドングルは 802.11a の 5GHz 帯に対応しているものが多いので FreeBSD でもその恩恵にさずかりたいものだ。などと思っているのですけども。

 
前回の USB 接続機器はずいぶんと大きかったのですが、今回は手頃なサイズの USB 機器です。まずは写真を。

でもってこっちがパッケージ。僕の場合 Windows10 で動作確認する前にまずは FreeBSD に接続して確認するのですが、ご多分にもれず、今回も素直に ugen に落ちました(^^;;。

パッケージやドライバ DC の印刷を見てみると REALTEK の RTL8811AU というチップが使われているようです。

で、以前掲載した GitHub を見に行くと・・。おやまぁ。カーネルモジュールのは FreeBSD 12-CURRENT に対応した patch になっているようです。で、ちょっと違ったところを見に行くと、おぉ。 FreeBSD 本体に commit されたのかしら? 新しく rtwn_usb というカーネルモジュールになるようですねぇ。
もう少し待てば、自分でコンパイルせずとも、 OS 標準で利用できるようになるのかもしれません。

 
さてと。今回購入した USB Wi-Fi ドングルですが、仕様としては REALTEK RTL8811AU ですが、 if_urtwm.ko は RTL8821AU 対応です。大丈夫か? などと思い試しましたが、すんなりと動きました。

まぁ、当然の作業として if_urtwm.c にはエントリを記述して、 usbdevs にも product ID を登録する必要があるんですが。

o. if_urtwm.c に記述する行

        URTWM_DEV(REALTEK,      RTL8811AU),

 
o. usbdevs に記述する行

product REALTEK RTL8811AU       0xa811  RTL8811AU

 
これで利用可能になりました。

 
以前のエントリで試した AUKEY の AC1200 というのは USB3.0 接続でチップセットが RTL8812AU でしたが、今回のは USB2.0 で RTL8811AU なので、もしかしたら一個古いチップで USB2.0 対応なのかもしれません。

 
電波が外にもれない(と思われる)部屋で動作確認をしたところ、200MB のファイルを転送してみると 50Mbps 程度でいたので、ずいぶんと速度が速い USB WiFi で、それが FreeBSD で体験できることにある意味感動を覚えました;-)。

 
あ。FreeBSD で 802.11a を利用する場合 /etc/rc.conf のネットワークの設定のところにおまじないを書かないと動作しないようです。

o. /etc/rc.conf の記述例

wlans_urtwm0="wlan0"
ifconfig_wlan0="WPA DHCP ssid AP802-5 mode 11a country J5"
#ifconfig_wlan0="WPA inet 192.168.1.100 netmask 255.255.255.0 ssid AP802-5 mode 11a country J5"

 
上記の設定は SSID: AP802-5 という 802/11a (もしくは 802.11ac) の AP に接続するときの設定ですが、どこの国で接続するか指定してあげないと正しく動作しないようです。おかげでサクサクと動作しているー;-)。

今後は安定的に動作していることを確認して行きたいとは思うのですが、こってりと利用するのはちょっとはばかれるので、動作確認のみ。と、したいと思います。