たかちゃん。

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

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: に出力される前に吸収されてしまいます。

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 買おうかなー;-)。

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(^^;;。

12月 282018
 

ノッチのあるスマートフォンというのはどんな感じだ? などと思い、 Apple の iPhone は高くて手が出ないので、中国産の Android スマートフォンを購入しました。今回チョイスしたのは UMIDIGI というブランドの Z2 Updated Edition というモデルです。

色々調べてみると UMIDIGI Z2 というのは初代・スペシャル・アップデートと三種類あるらしいですが、僕が購入したのはタイトルにもある通り UMIDIGI Z2 Updated Edition です。

この端末、技適を通していないので、日本国外で使うのはちと無理です。正月に海外で過ごすときなど、成田空港の外側で利用するよあにしましょう。

 
スペックや、使用感などは既に他のブログなどあちこちで掲載されているのでここでは一切書きません。触ってみて、僕が『ん?』と思った部分のみ掲載してみます。

 
最初に断っておきますが、僕は google がキライです。なので、初期にインストールされている google 謹製のアプリはほとんど無効にしています。

カレンダー・ドライブ・GMail・Chrome・フォト・Play music/Movie などは google 謹製を利用していません。

 
1.メーラソフト無い?
GMail を無効にするとメーラアプリがなくなるんですね。 SONY Xperia Z5 Compact を購入したときは別にメーラアプリがあったので安心していたのですが・・。
しょーがないので、 TypeApp というメーラをインストールしました。

他にカレンダーも無くなったので OneCarender というのをインストールしました。このカレンダーアプリは CalDAV に対応しているので自宅に構築した DAViCal サーバのカレンダー情報を読み込むことができます。どちらも広告無しの秀悦なアプリです;-)。

 
2.カメラは GPS ポイントを書き込んでくれない
このスマートフォンで撮った写真は、特定のアプリでは地図上に写真を配置してくれる。それはつまりは EXIf に現在地情報を書き込んでくれるのですが、これを macOS の『写真』アプリに持っていくと位置情報無し。と、いうことになります。

と、いうことで純正のカメラアプリも無効化します。そして、google フォトも無効化しているので、それぞれに対応したアプリを探します。

カメラアプリは OpenCamera をインストールしました。こいつはしっかりと GPS ポイントを Exif に書き込んでくれます。また、このスマートフォンのカメラの機能も一応引き継いでくれているような気がします。まだ、被写体深度の深い写真はあまり撮ってないんですけどね。

写真管理のアプリはギャラリーをインストールしました。別に google に写真はバックアップしないので、これで全然問題はありません。逆に google に写真預けたくない;-)。

 
3. CPU 遅いよ・・
このスマートフォンは Helio P23 という CPU を利用していますが、こいつが遅い・・。orz
今まで利用していた SONY Xperia Z2 compact よりも遅いと感じるので実質的に、僕個人的なスマートフォン環境としてはデグレードしている感満載です・・。orz

ポケモン GO の起動も遅いし、フツーのタイミングで待たされることがある感じです。
アプリを終了してランチャーに戻るとき、重いランチャーだと、アプリアイコンが表示するまでに 3 秒くらい待たされる場合があったり、結構うんざりします。ランチャーアプリは軽いのをインストールするのがおすすめです・・。

素直に UMIDIGI F1 待ったほうが良かったかなぁ。などと思ったりもしていますが・・。

 
4. テザリングしくしく
やはりテザリングはボトルネックですねぇ。僕はトヨタのカローラフィールダーに乗っているのですが、カーナビはトヨタ純正でテザリングすると Android アプリの MyTOYOTA for T-Connect と同期してくれて走行距離とか取ってきてくれたり T-Connect カーナビアプリは『G メモリ』に登録した行き先情報をカーナビからアクセスできたりと、連携してくれるのですが・・。

カーナビが要求してくる Wi-Fi AP の仕様は 2.4GHz の 1-13ch なのにこの UMIDIGI Z2 は基本的に 2.4GHz の場合 14ch で待ち受けます。なので、カーナビはデザリングできないんですね。

この写真はカーナビ側のアクセスポイントの詳細情報を表示しています。チャンネルが 14 なので、接続できない。見えるんだけど、パスワードを何回も聞いてくる状態なんですね。あれま・・。

 
しかし、時々は接続できる場合があるので、その場合 UMIDIGI Z2 側は 10ch になっていたりするので、テザリング時に 14ch 固定ということは無さそうです。

例えば USB のバスパワーで動作する Wi-Fi AP を 13ch に設定して車の中で電波を出したあとに UMIDIGI Z2 のテザリングをオンにすると、14ch に近い 13ch が使われていると認識して、もっと下のチャンネルを利用するタイミングがあります。

もっと言うと、駐車場の周りにある建物の Wi-Fi AP が外へ漏れている場合、その影響を受けて 14ch ではないチャンネルでテザリング待ち受けする場合があるのでトライしてみるのも良いかもしれないです。

 
ちなみに僕は USB バスパワーで 2.4GHz 帯でチャンネルを任意のチャンネルに指定できる Wi-Fi AP として WRH-583GN2-S を利用しています。

 
とまぁ、つらつらと書いてみましたが、機能的には DSDV 使えたり(まだ使ってないけど)、こまめに OS のバージョンアップ(バグ修正)してくれたりするので良い感じかな? とは思ってますが、今は Andorid8.1 で、多分 Android9 にはならないと思います。 Android9 が欲しいなら新しいの買ってね。安いんだし。って雰囲気出ています;-)。

 
なお、上にも書いていますが、ベンダはこまめにバグフィックスしてくれているようで、過去にリリースされた OS イメージは以下のサイトでダウンロード可能になっています。その点はありがたいですね。

https://community.umidigi.com/forum.php?mod=forumdisplay&fid=202

もう少し使い込んでみて、あまりに遅いようだと次のを購入するか、と、いう感じですが、 au の ガラホ SIM で DSDV を試してみたい。と、いうのはちょっと思いますねぇ。

 
この話、続きのエントリが書かれることがあるかな?

12月 012018
 

一個前のエントリで Mac mini を購入した件を書きましたが、今まで利用していた MacBook 2009 も一応健在です。OS は Sierra でしたが、インストールできる最新の Hight Sierra にしたいモノですが、中々バージョンアップが行えない。

あ。 MacBook 2009 は Mojave は非対応な機種となりました。しかし、 Aplle は Sirra も Hight Sierra もまだサポート対象 OS としているので一応、安心して利用可能です。

 
今まで利用していた環境は MacBook 2009 に Sierra をインストールしていましたが、自分で交換した 128GByte の内蔵 SSD は容量不足になりつつあったので、これを機会に 256GByte に容量を増やし、そのタイミングでなんとか Sierra -> Hight Sierra にバージョンアップしようとの目論見です。

既に多くのウェブサイトに記載されていますが Sierra -> Hight Sierra へのバージョンアップは非常に厄介です。ファイルシステムが HFS+ から APFS に変更になったため容易にはインストールできません。

そして、自分で個別に、僕のように初期の HDD から SSD に変更した人は更に高い壁が立ちはだかりインストールができません。
MacBook系 の HDD を SSD に変更した人がはまる道。


https://applech2.com/archives/20171002-high-sierra-upgrade-issue-due-to-third-party-ssd.html

純正の HDD もしくは SSD を自分で、別の SSD に換装した場合にファームウェアの更新ができなくて Hight Sierra にアップデートできない。と、言うんですね。

僕もこの壁にぶち当たりましたが、なんとか回避しました。その手順を書いておきます。

1. 今の状態
MacBook 2009 は HDD であったが、遅いで 128GB の SSD に換装したのは今から 2,3 年前。
macOS Sierra までは順当にアップデートができたが Hight Sierra にアップデートしようとしたらちっともアップデートできないのでそのままにしていた。
ちっともアップデートできないとき、以下のメッセージが表示されていた。

「macOSをこのコンピュータにはインストールできません。ファームウェアの検証でエラーが発生しました」

Hight Sierra を USB メモリでインストールできるようにインストールイメージを USB メモリ上に作成。
作成についてはあちこちのサイトに記載されているのでそちらを参考にしてください;-)。

USB メモリでのインストールも何回か試みるも上記メッセージが表示されちっともアップデートできない。

 
2. 128GB の SSD を 256GB の SSD に換装
ちょうど良いタイミングで 128GB の SSD の容量が足りなくなってきたので 256GB の SSD に換装し、 Hight Sierra をクリーンインストールすることにする。
タイムマシンでバックアップし、 128GB の HDD はもしものためにきっちりとキープしておく。

Hight Sierra のインストールイメージが入っている USB メモリからブートし、クリーンインストールを試みるも上記メッセージが出てやはりインストールできず。

おやおや・・。orz

このときに NVRAM のリセットを試みる。option+command+P+R の同時押しの電源投入で、二回『ちゃらーん』(音が違うか。これは笑点だ;-)と聞こえたら NVRAM の初期化完了。

その後、再度 USB メモリからクリーンインストールに挑戦するもやはりダメ。

 
3. 256GB の SSD に Sierra をインストール
USB メモリから Hight Sierra をインストールするのを断念し、以前利用していた 128GB の SSD を USB 接続してから MacBook を起動し、復旧バーティションから Sierra をインストールします。これは無事にインストール完了。
新しい 256GB の SSD には今まで利用していた OS と同じ macOS Sierra がインストールされました。

この状態で、 macOS Sierra のアップデートをドドドと適用します。クリーンインストールなのでマッサラな状態です。

で、何個かのアップデートを適用していくのですが、2018-005 だけが適用できないのであります。
で、 2018-005 は何をしているのか? と、いうと、上記のようにエラーとなるファームウェアのアップデートなんですね。 2018-005 が適用できないと、いつまで経っても Hight Sierra がインストールできません。
裏を返すと 2018-005 が適用できると Hight Sierra のインストールが可能になるわけです。

僕は、 2018-005 未適用な状態、 2018-004 まで適用した状態で再度 NVRAM のリセットを試みました。そして再起動後にアップデートを実行すると、あぁら不思議。 2018-005 が適用できて最新 Sierra は最新の状態になりました。

そして、半分嬉しさを噛み締めつつ『この状態だと Hight Sierra にバージョンアップできんじゃね?!』などと思い、 App Store から Hight Sierra をダウンロードしアップデートインストールを試みたのであります。

 
4. 来たゼッ!! Hight Sierra
新しい 256GB の SSD に macOS Sierra をインストールし、サラの状態で Hight Sierra にアップデートするので特にゴミなど無いであろう。と、思われるのであります。

アップデートの途中で失敗することもなくインストーラは最後まで完走し、無事に Hight Sierra にアップデート完了ですっ!!

いやぁ。長かった。無事にアップデートできて良かった。

 
以上が macOS Sierra から Hight Sierra へのアップデートの道のりです。アップデートに失敗した人は僕も含めて色々な探しモノをするのですが、『ファームウェア初期化でインストールできた。』と、いう人がいるのですが、 NVRAM のリセットをいつ行ったら良いか?と、いうのが中々つかめない。

僕の場合都合二回ほど NVRAM のリセットを行うタイミングがあり、そのうちのどちらかがバシっと効果的に効いて、 2018-005 が適用できたのでしょうなぁ。

Mac の SSD 換装による Hight Sierra へのアップデートができない人は多分 2018-005 も適用できていないと思います。 まずは Sierra の 2018-005 のアップデートを適用するために NVRAM のリセットを行う。と、いう手もあるのではないかと思われます。

 
まぁ、ここに書いたのは『僕の MacBook 2009 の場合。』のお話かもしれませんが、同一機種で問題が発生している人の参考になれば嬉しく思います。

11月 222018
 

久しぶりに Apple の PC を購入しました。今まで使っていたのが MacBook 2009 なので約 8,9 年ぶりくらいですかね。

MacBook 2009 は macOS Sierra で、 Hight Sierra にバージョンアップできなくて困っていたのですが、それについては別途エントリを書く予定なので置いといて、 macOS mojave には対応しなくなるので、いよいよ新製品を購入。と、なったのであります。

それにしても MacBook は遅かった。 Core2Duo 2Core で mdworker が動き出すと CPU 食われまくり。新しい、絶大なパワーを持った Mac mini を買おうとしていたら Apple から 4 年ぶりに発売されたそれのパワーは絶大ですかさず飛び付いた。と、言う感じですね。

 
今回購入したのは intel i7 とメモリ 16GB で SSD は 256GB にしました。これで、消費税込み 19 万 yen コースです。高いなぁ。とは思うのですが、有り余るパワーの Mac が持てて非常に満足です;-)。

 
Mac mini に直接的に購入したのは USB-C の USB HUB 二個ですね。 USB ポートが少ないので USB-C の口にゾロゾロと色々接続するために購入しました。

その他、 Mac mini を利用するときに気付いた点を少々。

 
o. T2 チップ内蔵でスリープ状態が解らない
これはあちこちで書かれていますね。本体がスリープしてもフロントの LED が点灯しっぱなしでスリープしているのか解らない。
ディスプレーが省電力モードに移行していると『あ。寝ているね。』と、判断するしかないですかね。

 
o. Siri 起動
『へい。しり。』って言っても macOS は Siri が起動してくれない。コマンドキー+スペースキー長押しで起動しますが、そもそも Mac mini にはマイクが付いてないので意味ないじゃーん。と、いうことになるのですが、僕の場合、以前 PC 用に購入した USB サウンドカードがあったのでそれを接続し、その昔 Pod Cast やろうとして購入した SONY のステレオマイクがあったのでそれを接続しました。
これで Siri に対して色々聞くことができるようになりました。

しかし、上の項目にもマッチするのですが、 USB サウンドカードは電源が供給されていると LED が点灯するんですね。なので、 Mac mini がスリープしたか起きているかは USB サウンドカードを見るとこで確認できるようになり、一石二鳥なのであります。

こんなのを利用しています。

 
o. CPU パワーすげー。
僕は Mac のリソース確認のために MenuMeters と、いうのを利用しているのですが、 CPU コアが 6 個、 HTT 対応で計 12 Core に見えるのは圧巻です。今までに利用した PC は AMD の FX-6100 が 6 Core で最高だったのですが、Mac mini が一番コア数の多い PC になりました。

おかげでサクサク、コンパイルもサクサク、上にも書いた通り mdworker どんと来やがれ状態です;-)。

 
o. epkg も動いているよ
以前、このブログにも書いていますが、epkg を /usr/local/ 配下にインストールして動作できる環境を整えています。

なので、FreeBSD の ports 的に、自分で必要なものは自分で make && make install して利用しています。もし良ければ使ってみてください。

https://icmpv6.org/EPKG/

epkg を作成する上で、今回一番困ったのが、最近の macOS から ftp コマンドが消えている。と、いう点です。しかも wget がないのでどうやってファイルを取ってくるのだ?と、なるのであります。

epkg-mojave-20181203.tgz には epkg で作成した wget のバイナリも入れておいたので epkg install すれば良いと思います。
自分で Makefile を書いてコンパイルしてバイナリを作成したのですが、一応 OpenSSL も enable しています。 なので上記 URL からも色々取って来られると思います。

自分でソースからコンパイルすると、やっぱり楽しいですねぇ。 epkg の Makefile には make -j 12 と書かれたモノが何個かあるかもしれないです;-)。
cmake とか emacs などは make していて気持ちが良い;-)。

 
新しい Mac mini はこんな感じてでしょうか。コンパイルメインに利用しているなんて、いかにも間違った使い方かもしれませんが、他の人とは違う使い方を書いているのでまぁ、ヨシとしておきましょう;-)。

 
さてと。今回は Mac mini の他にディスプレーも買い替えてしまいました。今まではフルハイビジョンの 21.5 インチのディスプレーを約 10 年くらい利用していたのですが、そろそろ買い替えどきかと思い 4K にするか、悩んだのですが、2K で表示する 23.8 インチのものにました。

Mac mini から 2k (2560×1440) サイズは利用可能でず。ただ、MacBook 系とは違い文字サイズの変更ができません。

「システム環境設定」から「ディスプレイ」を選択し、[解像度]を[変更]しても文字サイズを変更するメニューが出ないのであります。なので、 2k サイズで利用する場合にはちっこい文字での表示となります。

あ。今回購入したディスプレーは IO-DATA の EX-LDQ241DB です。 NTT-X で購入したのですが、僕の場合はタイミングが良くクーポン券が付いていて 19,980yen で購入できました。ずいぶんお得で助かりました。

 
とまぁ、こんな感じで macOS を利用する環境が新たに整ったので、今後はガシガシ使い込んで行きたいと思います。

何か気付いた点が、今後出てきたらまた何か書きたいと思います;-)。

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 がずいぶんと楽しいものになったかな? ;-)。