3月 112017
 

僕が持っている ThinkPad e145 は FreeBSD がインストールされていて、 suspend/resume するんだけど、resume 時、それはつまり目覚めたとき、パカっとフタを明けたときに default gateway が消えていたりして、ネットワーク的にはちょっと問題があったんですね。
まぁ、目覚めたあとにいつも route add していたんですけども。

そんなこんなで、resume 後に route add が必要なわけ、挙動をいよいよ調査してみることにしたんですね。

僕の FreeBSD の環境は以下です。

・FreeBSD/amd64 10.1-RELEASE
・ネットワーク環境は USB 接続の run0 -> wlan0

OS はまたもっと面白いことになってます。カーネル は 10.1-RELEASE でユーザランドが 10.3-RELEASE です。やってはいけない環境で動かしている。と、いうことですね。どうしてこんな環境で動かしているかについてはあとで少しお話します。

今の話題は resume 後に routing テーブルが消えている点についてですね。話を元に戻しましょう。

 
suspend して、その後 resume したときに起き上がってきた FreeBSD の動作ですが、だいたい以下のようになっているようです。

0. 実は suspend 時に USB デバイスが全部抜去される
1. resume 後に USB を認識してデバイスが接続される
2. resume 後に /etc/rc.resume が動く
3. devd が色々良きに計らってくれる (僕の環境では webcamd の再起動と pccard_ether のすーたと)
4. 自分で記述したスクリプトの動作
5. /etc/rc.resume の終了

まぁ、こんな感じですが、問題は 5. ですかね。

suspend で USB 機器が外されたということはつまりは wlan0 が無くなった。と、いうことなので、これで routing テーブルは全て消えます。
その後 resume して USB 機器が接続され wlan0 が認識され、wpa_supplicant が動き出してネットワークインターフェースには IP アドレスが付加されるようになります。

じゃぁ /etc/rc.resume の中で route add すりゃいんじゃね?

とか思うんですが /etc/rc.resume 内で route add してもそのときはまだ wlan0 に IP アドレスが付く前なので意味無いんですよね。

じゃぁ /etc/rc.resume の中で route add する前に sleep 30 とかすりゃいんじゃね?

とか、次に思いますよね。ところがっ!! /et/rc.resume はちょっとおかしな動作をしていて、 /etc/rc.resume が動作し終わったあとに wlan0 に IP アドレスが付加されるようです。

なので /etc/rc.resume の中で

sleep 30
route add default 192.168.1.1
route add -inet6 default fe80::1

 

などと書いても全く意味ない状態です。では、どうするか?と、いうと、上記の部分をスクリプト、例えば /usr/local/bin/routeadd.sh などとして準備します。
/etc/rc.resume には以下のように書きます。

/usr/bin/logger -t $subsystem route add default.
/usr/local/bin/routeadd.sh &

 

ここで注意しなければならないのは、スクリプトを記載したあと、最後に “&” を付けてバックグラウンドで処理させる必要があります。
動作的には /etc/rc.resume の実行後に wlan0 に IP アドレスが付くので /etc/rc.resume が実行中に sleep 30 してもまるで意味なくて route add されない状態です。なので “&” を書いてバックグラウンドに飛ばして、バックグラウンドのスクリプトが sleep 30 している間に /etc/rc.resume が終了して wlan0 に IP アドレスが付いたあと、 sleep 30 が終わり route add されるようにしないとダメなのであります。

この現象は USB NIC を利用しているからかもしれません。
動作的に resume 後に routing デーブルが消えていて、毎回、自分で route add 打つのが困難な人は上記のようにすれば良いのではないかと思います。

 
で、もう一個のネタを簡単に。

上のほうにも書きましたが、僕の ThinkPad e145 上で動作している FreeBSD はカーネル は 10.1-RELEASE でユーザランドが 10.3-RELEASE です。これ、FreeBSD の動作保証対象外の構成らしいですね。カーネルは新しく、ユーザランドが古い場合には問題ないらしいですが・・。

どうしてこんな環境で動かしているかというと ThinkPad を使っている人は 10.2-RELEASE 以降、suspend して resume したら LCD の明るさが最大になってしまい変更できなくなってしまったんですね。
10.1-RELEASE までだと Fn7,8 などで明るさが変更できた。 acpi_ibm や acpi_video がなくとも変更ができた。しかし、10.2-RELEASE 以降では Fn7,8 ボタンが効かなくなって、acpi_ibm の dev.acpi_ibm.0.lcd_brightness も有効にならなくて acpi_viode の hw.acpi.video.lcd0.brightness も使えなくなった。
resume 後に明るさを変えることができなくなったので、僕はいつまでもカーネルは 10.1-RELEASE を使い続けている。と、いうことです。

あと、別の手段としては ports から sysutils/acpi_call/ をインストールして ACPI のパラメータを表示したり変更したりできるようですが \_SB_.PCI0.VGA.LCD._BCM なパラメータなどをいじったりするなど、ちょっと試してみましたがダメでした。

acpi_call のコマンドイメージをちょっと書いておきます。使うには kldload acpi_call.ko する必要があります。

# acpi_call -vp '\_SB_.PCI0.VGA.LCD._BCM' -o i -i 50
Path: \_SB_.PCI0.VGA.LCD._BCM
Number of arguments: 1
Argument 1 type: Integer
Argument 1 value: 50
Status: 0
Result: 1

 
acpidump -d の結果を確認すると _BCM ってのが “Brightness Control Method” らしいです。他にも _BCL ってのがあって、こいつは “Brightness Control Levels” らしいです。
acpi_call で _BCM の値を 50 に変更してあげる。ってのが上記のコマンドと、その結果です。
しかし、値は反映されない・・。 orz

 
ThinkPad でも Nvidia のグラフィックスカードを利用しているヤツは Nvidia のツールで画面の明るさを変えられたり Intel の場合は graphics/intel-backlight/ などで画面の明るさを変えられるらしいです。
僕の ThinkPad e145 は Radeon のチップなので・・。orz

多分 10.2-RELEASE 以降で ACPI 周りに変更が入ったのでしょうなぁ。

ThinkPad e145 は BIOS モードと UEFI モードの両方で 11.0-RELEASE で試しましたが画面の明るさは変えることができませんでした・・。

と、いうことでももうしばらく、ってか、壊れるまで? 10.1-RELEASE の利用は続きそうです・・。

2月 282017
 

多分、全然、誰も知らないと思うのですが、 FreeBSD の ports に net-mgmt/sysmon/ というのがあります。デーモンモードでサーバなどを監視するプログラムです。開発自体はもうずいぶんと前に止まっている。裏を返せば枯れた監視プログラムなのであろうと思われますが。

以下の URL が参考になるでしょうか。

https://puck.nether.net/sysmon/

プロトコル的には SMTP, IMAP, HTTP, TCP, UDP, NNTP の監視に対応しています。また PING に対応しているのと、個別にポート番号を指定しての監視も行えます。

 
今回、このプログラムを改修するバッチを書いたのでここに掲載しておきます。改修内容は以下です。

o.pingv6 で IPv6 アドレスを記載できるようにした
o.監視ホストの最大数が 1,024 個だったので 4,096 個に拡張した

以上二つの patch が含まれた net-mgmt/sysmon/ の ports の tar 玉を以下の URL に置きました。

http://icmpv6.org/Prog/FreeBSD_ports/ports-sysmon-20170227.tgz

新しく files/ というディレクトリを作成し、そこに二つのパッチを入れてあります。

IPv6 のパッチについてちょっと説明すると監視用の設定ファイルに “type pingv6;” と記載して、監視できるのに “ip” のところに IPv6 アドレスを記載できないんですね。なので IPv6 アドレスを記載できるようにしました。

まぁ /etc/hosts に書けばいーじゃーん。って話もあるんですが、一応 IPv6 記載 OK なパッチを書いた。と、いうことです。

 
監視対象ホストを 1,024 -> 4,096 に拡張してどうすんだ? という話もあるんですが、大規模ネットワーク用の監視になるでしょうかねぇf(^^;;。

実は sysmond を一台のサーバで複数プロセス起動する改修を当初考えたのですが、複数のプロセス(スレッド)を立ち上げると、メモリ上に持っている(1,024個の)監視対象ホストの情報テーブルを各プロセスがシェアしてしまい、上書きしつつ値がぐちゃぐちゃになってしまったので、派手な改修は断念してただ単に対象数を増やした。と、いうことですf(^^;;。

もし、必要な人いましたら使ってみてください。多分、誰もいないであろうと思われますがf(^^;;。

2月 222017
 

ある意味悲しいのかもしれないですが、僕は今も昔も IPv6 を利用するときに IPv6 Over IPv4 トンネルを利用する機会が多いです。
そもそも FreeBSD をずっと利用しているので dtcp を利用すると簡単に接続できます。 FreeBSD の ports 的に言うと net/dtcp になりますが、サーバ側とクライアント側の両方がインストールされます。通常、サーバ側に net/dtcp をインストールして dtcpd を利用し、クライアント側には net/dtcpclient をインストールしたりしますが、まぁ、とりあえずは net/dtcp をクライアント側にもインストールすることで、グローバルアドレスがあれば簡単に IPv6 Over IPv4 なトンネルが掘れるのであります。

が、そろそろ FreeBSD でのルータ機能は引退させたいものだ。などと思っていて、 NTT-X で超格安の Cisco841J を買いそびれた今、 VyOS で実装するしかなんかべ。と、なり IPv6 Over IPv4 トンネル で利用する dtcp を引退することにしたのでありました。

今回は VyOS と FreeBSD との間で IPv6 Over IPv4 トンネルを掘る設定を書いてみたいと思います。何を今更。感が満載ではありますがf(^^;;。

 
まずは構成図を。

真ん中の黄色いのが IPv6 ゲートウェイなルータでで FreeBSD/amd64 10.3-RELEASE から VyOS-1.1.7 にネットワーク機能を変更しました。
周りのピンクのセグメントは dtcpclient が動いていたのですが、これを VyOS に接続するために設定変更しなおします。

 
1. ゲートウェイスイッチ側の設定
FreeBSD から VyOS にリプレイスしたので設定は VyOS の設定になります。だいたいこんな感じ。

    tunnel tun10 {
        address 2001:470:fe36:1111::1/64
        description "# IPv6 Tunnel No1 #"
        encapsulation sit
        local-ip 192.168.1.210
        multicast disable
        policy {
            route mss
        }
        remote-ip 172.16.1.211
    }

 
VyOS は基本的に Linux なので sit なんてのが見えますが、こんな感じの設定ですね。

・local-ip で自分の IPv4 アドレスを設定
・remote-ip には接続先 IPv4 アドレスを設定
・policy route mss は IPv6 Path MTU Discovery にはまらないためのおまじない

以下の設定で MSS の値を調整しています。

policy {
    route mss {
        rule 5 {
            protocol tcp
            set {
                tcp-mss 1386
            }
            tcp {
                flags SYN
            }
        }
        rule 10 {
            protocol tcp
            set {
                tcp-mss 1386
            }
            tcp {
                flags SYN,RST
            }
        }
    }
}

 
簡単ですねぇ;-)。
ただ、 IPv6 Path MTU Discovery にハマると http とか接続できない問題が発生するのでその対応が必要になります。 tcp-mss 1386 の数値の部分は自分の環境によって変わるので過去に書いた記事を参考にしてみてください。

 
1. dtcpclient 側の設定
ルータ側の設定が終わったので、次にクライアント側の FreeBSD の設定になります。

とりあえず、以下のコマンドを打てばトンネルは掘ってくれます。

ifconfig gif0 create
ifconfig gif0 tunnel 172.16.1.211 192.168.1.210
ifconfig gif0 inet6 2001:470:fe36:2222::1 2001:470:fe36:1111::1 prefixlen 128
route -n add -inet6 default 2001:470:fe36:1111::1
ifconfig gif0 up

 
起動時に IPv6 トンネルを自動的に掘りたい場合はどうしますかねぇ・・。 /etc/rc.conf に色々設定するのが大変なので、僕の場合は /etc/rc.local というファイルを作って、そこに記述して起動時にどうにかしてもらっていますf(^^;;。

3. 確認方法
両方で設定が完了するとあとは確認になります。FreeBSD 側から以下のコマンドが有効ですね。

$ ping6 ff02::1%gif0
PING6(56=40+8+8 bytes) fe80::a1f:29ff:fefe:9696%gif0 --> ff02::1%gif0
16 bytes from fe80::a1f:29ff:fefe:9696%gif0, icmp_seq=0 hlim=64 time=0.089 ms
16 bytes from fe80::ccaa:f1d2%gif0, icmp_seq=0 hlim=64 time=8.663 ms(DUP!)
16 bytes from fe80::a1f:29ff:fefe:9696%gif0, icmp_seq=1 hlim=64 time=0.047 ms
16 bytes from fe80::ccaa:f1d2%gif0, icmp_seq=1 hlim=64 time=7.081 ms(DUP!)
^C

 
二つのリンクローカルアドレスから ping6 の応答があれば無事に接続しました。これで IPv6 Over IPv4 トンネルが掘れました。
グローバル IPv6 に ping6 を打って返ってこない場合はルーティングに問題があるので、ゲートウェイ側の設定を見直すなどしましょう。

 
と、いうことでゲートウェイ側を FreeBSD から VyOS に移行し、更に dtcp の利用をやめて接続しても、いとも簡単にトンネルが掘れました。良かったですぅ;-)。

2月 022017
 

IT 系のニュースサイトを会社でお昼休みに見ていたら Amazonセール速報:本日限りの特価! と、いうのを発見。かねてより会社で使うためのマウスを探していたので、すかさず購入しました。

購入後、次の日には届いたので早速使ってみることに。が・・。あたたたたた。使えることは使えるんだけど、ホイールが軽すぎて真ん中ボタンを押したら上下にホイールしてしまう状態である意味全然全く使えない。

例えばブラウザでとあるサイトのアンカータグを真ん中ボタンでクリックすると新規タブで開いてくれるんだけど、真ん中ボタンを押した表示されているコンテンツが上下にズズズと動いてしまう状態。全然使えないじゃん・・。

と、いうことで届いたその日のうちに分解。何とかカスタマイズできないかなぁ?などと思うわけです。分解の手順は至って簡単。

1. 電池を抜きます。
2. すると電池の溝の影のところにネジが一本あるのでそれを抜きます。
3. 裏ブタを下にずらしつつ上のほうのロックが外れる。
4. 上ブタのボタンのコネクタを爪などで抜きます。

以上で分解完了。

ホイールの部分を眺めてみるとどこかでテンションというか抵抗を付けてあげるとホイールの回転が渋くなるのになぁ。と思います。それに相当するのが、あったー。

写真でいう針金のようなものがホイールを回り込んているようです。

これを曲げてホイールに対して抵抗を作ってあげるとクルクル回る現象はある程度回避できそうです。
針金は本体プラスチックの爪で固定さているので横 (右ボタン側) にずらして外します。このときスプリングがびよーーんっ!! とどこかに飛んでいってしまうので注意が必要です。

抜き出した針金はこんな感じ。

これを、ちょうど良い硬さのホイールになるように曲げてあげます。僕はラジオペンチで曲げつつ調整しました。ビタっとしたちょうど良いホイールの硬さにするために三回くらいトライしました。もし、このエントリを読んだ人が同じことをする場合は、自分の感覚を信じて色々曲げてみてください;-)。

と、いうことでホイールは無事にちょうど良い硬さになり、ホイールの真ん中ボタンを押してもコンテンツが上下にブレる。と、いうことから開放されたのでありました;-)。

 
と、いうことで、これだけで終わってしまったらただ単にフツーの、そこいら中にある分解・改造の記事になってしまうので一歩踏み込みます;-P。

まず、僕の PC の環境についてですが、キーボードとマウスは二台の PC で共有しています。 USB 切替器で FreeBSD と Widnows10 を行ったり来たりしている状態です。

で、この Logicool の M5454 というマウスはホイールが前後に回転する他に左右に倒すことによってイベントが発生するようです。しかも右側には更にボタンが二つあります。

パッっと思いつくのは『このボタン達は FreeBSD で使えないのかな?』と、いう点。 Windows10 の場合は専用ドライバをインストールすると、ホイールの左右方向と左側の二個のボタンには色々な動作を割り当てられます。

これを FreeBSD+Xorg で似たようなことできるのかな?とか思い、ちょっと調べてみました。

まずは Xorg のマウスの設定。

Section "InputDevice"
        Identifier  "Mouse0"
        Driver      "mouse"
        Option      "Protocol" "auto"
        Option      "Device" "/dev/sysmouse"
        Option      "ZAxisMapping" "4 5 6 7"
        Option      "ButtonMapping" "1 9 3 2 2"
EndSection

 
最後に ButtonMapping と、いうオプションを付けてみました。

オプションの数値はボタンの番号を表しています。ボタンの番号は xeve で取得できます。数値が “1 9 3 2 2” となっていますが、これは “左 左横前 右 ホイール ホイール” の各ボタンを指しています。
動作的には “左ボタン 真ん中ボタン 右ボタン ホイールの前 ホイールの後” ということになります。 FreeBSD のマウスによるペースト動作を左横前ボタンで代用する。と、いう設定ですね。

さてと。X を再起動して /var/log/Xorg.0.log を眺めてみましたが X からは ButtonMapping の設定がまるで無視されていました・・。orz

 
次に FreeBSD の ports で何かないんかい?と思い調べたのですが x11-drivers/xf86-input-evdev という、 X のドライバでマウスの様々なボタンに対応できるらしい。とのことで調査開始。

Linux では動作するらしいですね。 /dev/input/* なデバイスを利用するとマウスで色々なボタンが利用できるようになったり、Logicool M565 などは専用カーネルモジュールがあるようで。

FreeBSD ではまだ evdev.ko なるカーネルモジュールがないので実質的に xf86-input-evdev は利用できないようです。 CURRENT で現在検証中らしいのですが、それ以上は追うのはやめました。

 
と、いうことで FreeBSD においてはフツーの無線の USB マウスとして利用しようとおもった矢先、ブラウザでとあるサイト見ているときにホイールを左右に振ってみると。あれれ?

ホイールを左に振ると戻るボタン
ホイールを右に振ると進むポタン

と、して動作するようですねぇ。あれれ? X で制御しているのかな? KDE 側で対応しているのかな?あれあれ? ソースコード追ってません。すみません。ただの動作確認のみですf(^^;;。
一応 firefox rekonq では上記のように動作しました。 konqueror では動作しませんでした。

xmodmap で進む・戻るボタンが設定できるようですね。詳細は書きませんが。 evdev が動かなくても xinput などでも色々設定が可能らしいです。ここでは詳細は書きませんが。

まぁ、珍しい機能が動くモノだ。と、いうことで Windows10 側でもドライバユーティリティで設定を FreeBSD に合わせた。と、いうことで、二つの OS で動作が一緒になったのでありました;-)。

 
今回はマウスを一個購入して、エントリを書いていますが、タネは二つ。

・ホイールクルクルがイヤな人は分解して針金曲げてみましょう
・FreeBSD ではホイール左右で戻る・進むが動作する

と、いうことですね。中々楽しめた一品だったのでありました;-)。

あ。お約束ですが、『分解』することになるので、自己責任でお願いしますね。

1月 292017
 

MacBook 2009 に OS X El Capitan をインストールして利用しているのですが、最近になって 10.11.6 のアップデートが出ているのを知ったのでロクにバックアップも取らずにバージョンアップしました。
ただ Time Machine は動かしていたので、最悪そこからバックアップできるので良いかぁ。と、いう漠然としたモノはありました。

Mac App Store からアップデートを実行。その後リブートしたことろで、なんとっ!! OS イメージが見つからない。などとなり、リカバリーモードで起動しました。orz

この時点でガクゼンとしているのですが、リカバリーモードのメニューに「Time Machine から復旧」というのがあったので 10.11.6 アップデートを適用する前の状態にしてなんとかモトの環境に戻ったのでありました。ふぅ。

ここまでが第一段階。

 
このあと、El Capitan を使い続けるも Mac App Store が「10.11.6 にアップデートしろー。」などとしつこく言ってくるので『しょーがねぇなぁ。もう一回トライしてみるかぁ。』と、いうことで再実行。

 
ここからが第二段階の始まり;-)。

二回目の 10.11.6 アップデートは無事にインストールできたようで『あれ?一回目の失敗はなんだったんだぁ?』などと思いつつ、再起動後に現れたログイン画面からログインし、フツーにアプリを起動するのですが SSL 通信を必要とするアカウントにおいては全てパスワード認証エラーが発生するようになりました。あれ?

ウェブで調べてみると OS X のバージョンアップのタイミングで SSL 証明書ファイルがぶっ壊れる可能性がある。というのを発見。

iCal の https:// な CalDav サーバに接続してカレンダーの管理を行うアカウントでは認証の問題で接続できなかったり、 メールアプリ の全てのアカウントがログインできなかったりと、確かにそんな感じの気配はする。
しょーがないのでキーチェンから SSL 証明書を何個か削除して再起動を数回繰り返したら今度はログイン後の全てのアプリの動作が緩慢になってしまった。

 
いよいよ第三段階に突入です;-)。

ログイン後、アプリを起動すると 2,3 分後に起動したり、メニューのウィンドを出そうとすると同じくらい待たされたり、アプリ終了時にも待たされる事態が発生し、全く使えない状態。

試しにリモートから ssh で El Capitan にログインするとサクサク動作し、ロードアベレージを確認するも特に問題は無いみたい。

どーしたモンかいのぉ・・。

などと悩みつつひらめいた。b(^^)。 片っ端から怪しそうなプロセスを kill してしまえ。と。
リモートから ssh した端末はサクサク動作するので sudo して kill -9 PID で原因を特定していきます。

まずは OneDrive ・ DropBox ・ google 系のアプリなど。次に iTunes や iCal ・ Safari などの Apple 系のアプリ本体とヘルパーアプリなど。それでも特に問題解決にはならなかったので、おやまぁ。などと思い ps -axwww などと打つと ATOK for Mac のプロセスが動作していることを発見。こいつを kill したけど、すぐに起動するので結局 /Library/Input\ Methods/ATOK29.app/ ディレクトリを強引に移動しました。

 $ sudo mv /Library/Input¥ Methods/ATOK29.app /Library/Input\ Methods/ATOK29.app_

 
そーなのです。僕は ATOK Passport で ATOK for Mac 2016 を利用している JustSystem の正規ユーザなのであります;-)。

上記のコマンド実行後に MacBook を再起動すると、おぉっ!! 緩慢な動作がキビキビ動くようになった!! これにて一見落着かぁ?などと思うわけであります。そう。サクサク動く状況では ATOK for Mac のプロセスは起動していない状態なのであります。

想定できる原因としては SSL が利用できない(SSL 証明書がぶっ壊れた)状態で ATOK for Mac を利用していると、 ATOK は何かしらの通信を SSL で行うが、その通信ができなくて問題が発生し、ウィンド上の全てのアプリケーションの動作が緩慢になってしまったのでしょうなぁ。恐るべしインプットメソッド。って感じがしないでもないですが。

 
このあと、インターネット上の情報を探しまくると El Capitan 10.11.6 統合アップデート というのがダウンロードできて、それを利用してもアップデートできる。ということを知ったのですが、ダウンロードを三回試して、三回ともチェックサムエラーが発生したのであきらめました。

 
と、いうことで第三段階の問題は ATOK が引き起こしていたとしても、結局のところ SSL 証明書の破損については何の問題解決にも至っていないワケでして・・。

しかし、今度は画面上のアプリはサクサク動くので iCal のカレンダーやアドレス帳のバックアップは取ることが可能な状態です。ふぅ。

あ。僕は iCloud はあまり使っていません。カレンダーやアドレス帳は iPhone とは同期するけど iCloud には上げていない。メールは imap-ssl を利用しているので実データは持っていない。

iTunes の楽曲と 写真アプリ で読み込んだ写真・動画は外付け HDD に保存しているので MacBook 本体には保存していない。
バックアップは必要最小限で済みます。

 
で、第四段階に突入かぁ?

なんか、SSL 証明書が壊れているとしても、他にも色々ガタが来ているだろうと思われるので『この際』でもあるし、遅ればせながら macOS Sierra に移行することにしました。

Mac App Store でダウンロードは完了していたのでそのまま実行。目指すのはクリーンインストールです。
クリーンインストールを行うためには、まず一回目に上書きアップデートする必要があります。多分、リカバリー領域に Sierra のインストールイメージを書き込む必要があるのでしょうなぁ。

上書きインストールで El Capitan で破損した SSL 証明書は無事に復旧したようです。が、目指すのは Sierra のクリーンインストールです。再起動して Command+R で起動し、 HDD の内容を一旦全部消しクリーンインストールで事なきを得たのでありました。

ふぅ。何とか復活しましたが、このタイミングで macOS Sierra にするとは思わなかった。 Apple の策略にまんまと引っかかったのかな?

 
最後にですが、クリーンインストール後の SIerra での復旧について少々書いておきます。

まず自分で、手動でバックアップして、復活させたのは $HOME の Desktop/ Downloads/ Mail/ Music/ Documents/ Movies/ Pictures/ のみです。あと /usr/local/epkg/ も復旧しています;-)。
そして保存した iCal のローカルカレンダーとアドレス帳データを戻しました。

メールのアカウントは一から設定し直しかぁ。ウンザリだなぁ。などと思っていたら、 iPhone と同期しているアカウントについてはクリーンインストールなのに自動的に復活していました。あと iCal の CalDav アカウントも復活していました。

更に驚くのが safari を起動したときなのですが、なんとっ!! ブラウザに記憶させていたサイトにアクセスするためのログイン ID やパスワードがちゃんと記憶されている。これは多分キーチェーンを iCloud で保存しているからなんでしょうなぁ。かなりラクチン。と、いうか助かりました;-)。

iCloud には相対的には保存していないのに、また iPhone のバックアップはローカルに保存しているのに復活しました。楽だったので助かった。と、言えばとの通りなのですが、元データはどこから取ってきたんだろう? ちょっと心配だ・・。

 
と、いうことで、今回のエントリーはほぼテキストのみな状態になってしまいましたが、 El Capitan 10.11.6 アップデートに失敗して、その後 macOS Sierra にバージョンアップした顛末をまとめてみました。

注意点としては

・正式アップデートで SSL 証明書ファイルがぶっ壊れる場合があるのかもしれない
・ATOK for Mac が原因でウィンド上のほぼ全てのアプリの動作が緩慢になる

の二点でしょうかねぇ。