2016年4月20日水曜日

別のMacに接続したHDDへTimeMachineバックアップした場合の復元方法

TimeMachineバックアップで簡単なのは、Apple製品に囲われること、つまりTimeCapsuleをWiFi APとして使い、それに内蔵されたHDDをTimeMachineバックアップの対象とすることなんでしょうが、それにはお金がかかるので、別のMacがTimeMachineバックアップにしているHDDにファイル共有で相乗りしたいと思う人も多いのではないかと思います。

このときですが、普通にFinderからリモートドライブをマウントすると、SMB(Windowsファイル共有)でマウントされてしまうので、TimeMachineバックアップするときは、AFPでマウントしないと、権限が違うという理由で、そもそもTImeMachineバックアップが作成できません。マウスクリックでやる方法はわかりませんが、明示的にafpを指定してあげれば大丈夫。FinderからCmd-Kで「afp://マシンのドメイン名/保存先」のように。

このあと、TImeMachieをONにすれば、バックアップが始まります。

すると不思議なのは、ローカルHDDへのTimeMachineバックアップは、そのまま普通にファイルシステムとして見えて、バックアップ先のファイルを普通にコピーできるのに(ACLの属性はあれですが)、ネットワークでマウントした場合には、バックアップそのものは、マシンごとにひとつのsparsebundleつまりフォルダになっていて、おなじみInfo.plistなどもそこにはあります。そこにあるデータはなんだかフラグメントされたデータファイルの塊であって、ファイルとして見えません。

それで、リストアできるのか心配なので、念のためtarballを自分で作ってGoogle Driveにあげておいたりしたのですが、杞憂でした。

1回目の修理のときにGeniusに尋ねたら、「ファイルシステムとしてマウントすると普通のファイルに見えるんですよ」とのこと。実はこの説明はひとつだけはしょっているところがあるんですが、後述します。

さて、いったん初期化されたマシンからリモートドライブ上のTimeMachineバックアップで復元する方法ですが、以下の手順となるようです。(参考
  1. Cmd-Rで起動して、リカバリモードに入る
  2. ターミナルを起動して、リモートドライブをマウントし、おまじないをする。
  3. すると「TimeMachineバックアップ」という名前で見えるようになる
  4. ターミナルを終了して、通常のリカバリ手順に入る
結局、ターミナルでコマンドラインを入力するのに慣れていないとちょっとつらい、ということです。コマンドライン無理な人はTimeCapsule買うがいい(と、突き放してみる)。

さて、参考サイトをみながらやった手順を以下に記しておきます。ご参考まで。
  1.  リカバリモードから[ユーティリティ]→[ターミナル]で、ターミナルを起動する
  2. rootのコマンドプロンプトが出るので、管理者(シングルユーザモード?)ということがわかる
  3. ネットワークを接続しておく(やはり有線が早くて良いけれど、WiFiの設定はこの時点でもできる)
  4.  以下のコマンドで、まずリモートドライブをマウントする
    • mkdir /Volumes/TimeMachine
    • mount_afs afp://ユーザ名:パスワード@マシン名/保存先 /Volumes/TimeMachine
  5. すると、/Volumes/TimeMachine以下に、バックアップしたマシン名のsparsebundleフォルダが見えるので、以下のコマンドで普通のファイルに見えるようにします
    • hdid /Volumes/TimeMachine/バックアップしたマシン名.sparsebundle
  6. ターミナルをexitして、Cmd-Qで終了すると、起動時のメニューになるので、「TimeMachieバックアップからリストア」に入る
  7. 「TimeMachineバックアップ」の名前があるので、それをクリックして選択し、先に進む
ということでした。hdidがキモになるコマンドだ、ということですね。で、man hdidすると、backward comatibilityのためにのみ存在するコマンド、とかあって、将来的にどうなのかわからないですけれど、OS X 10.4の頃のhdutilコマンド(現存しない模様)の機能を切り出したものだということで、必要性がある限りは残るんでしょう。El Capitan時点ではまだあります。

MBP Retine 13"ディスプレイ破損と交換、さらに再修理の顛末

前回の回復後、急いでTimeMachineバックアップをとったものの、次の打合せに持参したところで落としてしまい、ついにディスプレイがブラックアウトしたままどうにもならなくなりました。

一回目の修理


やむを得ず、Apple電話サポートと話をして、Genius Barの予約をとってもらいました。とはいえGenious BarはiPhone修理の人でいつも混雑していて、なかなかとれないこと。でも、電話サポートの人は、こちらが動ける4月3日(土)と6(水)の予約を2つ入れてくれました。

なんとか土曜の予約時間に間に合ったので、そこでみていただくと、iPadでステータスを確認しながら、見えない画面でいろいろキーボード操作して診断していた模様。ThunderboltにEthernetのドングルをつけた状態です。

それで、「外部ディスプレイに出力が出るかもしれません」ということで接続すると、普通に起動した状態の表示が出て、「たぶん本体とディスプレイの間のケーブルやコネクタの部分の問題でしょう」ということで、基本料金33,000円(税込み35,640円)の見積もりとなりました。うれしい金額です。キーボードのバックライトが点灯しない理由については、「環境光センサーで明るさが決まるので、その配線の問題では」ということで、いよいよ配線のみだろう、という気持ちが高まりました。

そして、修理センター送りにしたのですが、翌日すぐにApple Storeから電話が。業務があり気が付かなかったのですが、メールで連絡があり、リンクをクリックすると、詳しい診断結果が表示されました。
  • ディスプレイパネル折損。圧力によるものと考えられる
  • ロジックボードに分解痕、コネクタの一部はがれ
 でありまして、分解結果見つかった破損箇所を爪楊枝で指しているくっきりした写真つきのため、ぐうの音も出ません。占めて税込み81,000円の見積もり。この際、クラムシェルのディスプレイ側全体を交換ということになったようです。見積書にはこの金額だけが書かれていて、最初の見積もりとの差を考慮して、諸費用はまけてくれたようです。ついでにロジックボードの交換を含めた金額なので、かなり良心的な対応(Retinaディスプレイ全体の価格が8,1000円のようなので)。

さて困りました。そんな金額はどこにもありません。というか、これからかかる様々な費用に備えて積み立てていた3万円しかないわけです。前の金額なら、食費を削って捻出を考えていたんですが、もうだめ。やむなく、財務大臣に土下座して、華麗に無視されたわけですが、2日後にはなんだか5万円が無造作にテーブルに置かれておりました。「これ以上は出ないからあとはなんとかしろ」と理解して、積立全部崩すこと決定。仕事になりませんから。

で、そのままサイトで修理承諾のボタンを押したところ、4月11日(月)にはAppleStoreに届いたとの連絡がありました。動けるのが水曜だけなので、13日に受け取りに行きました.

2度目の修理


受け取りは特にGeniusではなく普通の店員が対応するので、単に倉庫からもってきて、受け取りサインをしたら引っ込もうとするわけですが、「念のため起動の確認させてください」と言って、立ち会いのもと電源を入れてみます。

すると、いきなりこの画面ですよ。
おなじみ(笑)kernel panicの画面
初めて見るので戸惑っていると、「工場のテストのあとこういうことはあるので、続ければいいです」というので、何かキーボードを押すとbootが進みます。で、まあ、それらしい画面になりました。というか、修理に出す前のままの画面でして、Chromeのタブも全部そのまま復元。SSDの消去などは一切しなかったようです。ありがたや。

それで、少し見ていると、まあ大丈夫そうだったので、そのままディスプレイを閉じてスリープしたんですが、なんだか嫌な予感が残りました。マウスカーソルが固まっている気配。

帰宅するとやっぱり固まっているので、電源長押しで電源断、再起動。まあ使えているようです。それで、その日は疲れていたのでそのまま寝落ちして、朝起きたらやっぱり固まっていました。

この際、セルフテストすべきだろうと思って、キーボードの「d」を押しながら起動すると、2つぐらい進んだところで固まります。え。

強制電源断、 再起動して、仕事を始めようとするんですが、ログイン画面の背景の上に、画面左上からだーっと小さな文字でkernel panicのメッセージが流れます。をを! これでこそUNIX。

感動と戸惑いを抱えつつ再起動すると、今度はログイン画面に入る前に、同じく上からkernel panicメッセージ。さすがに心配になったので、もう一度セルフテストにかけると、こんどは「異常なし」できれいに終わります。なんなんだ。

変なkernel moduleでもいるのかな、と、追加で入れたデバイスドライバなどを消してみるも、特に改善しません。というか、だんだんkernel panicの間隔が短くなってきたので、これはOSのクリーンインストールをして、それでもだめならハードウェアの問題、セルフテストは通るけど。と考えて帰宅。自宅でCmd-Rで再起動し、ディスクユーティリティでパーティションを再作成して、ファイルシステムの消去(フォーマット)をしてから、リカバリに入ります。リカバリ領域に入っていたのは購入時のMaveriks。インストールを進めるのですが、しばらくするとkernel panic! 素敵すぎる。単に再起動してみるとどうなるんだろうと思ったら、続きのインストールをはじめます。再びkernel panic! 再起動して、ようやくMavericksが入りました。しばらく触っていて、なんとなく普通に動いているようにみえます。ハードウェアはおかしそうだけれど、まあいいやと思って、El Capitanにアップグレードするも、こちらはkernel panicのメッセージは出ないもののプログレスバー(iOSと同じ感じのやつ)が動かなくなるので、そこで電源断、再起動を2回やったらインストールが終わりました。でも、しばらく触るとすぐにkernel panic(上の図の画面)するので、Safariでメールの用事を少し片付けたところで諦め、翌朝からApple電話サポートに電話。

といっても、セルフテスト通るので、「これは詳細調査させてください」ということで、再びGenius Barを2つ予約。今度は13日(水)の夕方と閉店前の2つ。もう宅配ピックアップでいいと思ったんですが、「いったんお店でみてもらってからのほうが」ということで、こうなったんですが、正解でした。

Genius Barの本領発揮


水曜日の前の日に最終バスを逃してしまい帰れなくなったので翌日そのまま仕事して、早めに上がりたかったけれど業務が終わらないので、自宅にいったんMBPをとりに戻り、そのままAppleStoreに直行。8時過ぎについたので、45分の予約よりはずいぶん早いのですが、iPhone修理の人がいっぱいいるなか、10分ほどで呼び出してくれました。

で、マシンを出すのですが、これといって異常を見せないわけです。こういうときって。

そこで登場したのが、Genius Barにある、ネットワークブートでの診断ツール。例によってEthernetドングルをつないで、[Option]キーで起動すると、ずらりとネットワークブートの地球が並びます。それぞれ名前がついていて、目的に応じた専用ツールがあるようです。「nを押して起動する方法もあるんですよ」とのこと。なんだか、NetBootとよばれる機能があるようですね。詳しい説明がここにありました。NFS使うんですかへえ。

それでハードウェア診断のツールでboot。今度はグラフィカルな表示で、プログレスバーやチェック項目のアイコンが現れては診断結果をアイコンにつけつつ進みます。結局すべてのハードウェアに緑色のチェックマークがついて、OK。

別のツールで見るも、これといった異常がなくて、「少しお待ち下さい」ということで現れたのは、エンジニアリングに最も詳しいと思われるスタッフのお兄さん。同じように診断結果がオールグリーンなのを確認して、普通にSSDから起動しようとするときの、ちょっとしたもたつきを彼は見落としませんでした。

「ログを見てみましょう」といって、コンソールを開くと「SSDのアクセス失敗が大量に出ていますね」という。僕も見ればすぐにそれとわかります。

そう思ってみると、起動時にも、メニューバーがなかなか出なかったりします。

すぐに、最初に対応したスタッフのおねえさんに指示を出します。「ロジックボード交換と、念のためSSDの交換」、診断状況の報告についてもいくつか文言の指示を出します。

それで出てきた見積書が、ロジックボード47,100円を無償、128GB SSD 33,500円を無償、ハードウェア修理の技術費3,300円を無償、合計83,900円を90日保障で無償というもの。前回の修理でロジックボード交換されているのは明らかですが、これだけ割り引いてくれたんだという感慨がありました。最後の修理費とはなにかと思ったら、AppleStore店内でパーツを取り寄せて交換するときの料金とのこと。「修理センター送りでいいんですけど」と言ってみたら、「やることは同じですけど、確かめておきたいので」と。修理センター送りにするとどこが悪いのか確認できないから自分の目でしっかり見たいという、エンジニアの性なんでしょう。「仲間だ」と思ったので、「お願いします」ということで、店舗へのパーツ到着を待って交換したのち、一定の負荷テストをすることに。

しばらく日数がかかると思っていたのですが、昨日、4月19日に修理完了のメールが届いたので、本日(水)に受け取ってきた次第。今度も、店内の一般店員はあまり技術に明るくなさそうでしたが、「前回受け取った時にちゃんと起動しなかったので」と言って、きちんと起動し、しばらく問題がないことを自分で確認しました。そのときに、「こちらでも、一定時間電源を入れて、いくつかアプリを使って正しく動作することを確認していますので」という説明がありました。

というわけで、いま、このエントリを書いている間にTimeMachineバックアップを戻し終わったところ。 ネットワーク共有先のドライブの場合どうするかについて、次のエントリに続きます。

ちなみに、なんだかSSDがめちゃくちゃ早いです。これが単に、リカバリ直後だからなのか、それとも、もしかして、もしかするとMBP Early 2015以後のPCIe 3.0x4のSSDだったりしたら、細かな心遣いに感謝したいわけですが、そればっかりは分解してみないとわからないわけで、ひとまず気にしないことにします。システム情報見たら、STAT/STAT Expressのところで「リンク幅: x2」とあったので気のせいでしたはい。

2016年4月18日月曜日

I-O DataのWN-AC433UAをArch Linuxで使う

(追記:2017年4月19日)最近のカーネルでは、この記事のドライバでは問題がありそうです。新たに記事を起こしましたので、ご参照ください。

WiFi APの構築をしています。NCUで。

当初はVyOSを使おうとしていたんですが、IntelのNCUではbootできませんでした。あと、内蔵Wi-FiモジュールはLinux Kernel 4.2以上が必要ということで、3であるVyOSは対象から除外することとなりました。それでいろいろ苦労しております。

そのあたりは後述するとして、この際LinuxはArch Linuxにしようと決めました。理由はただひとつ、どんどん新しくなるからセキュリティ対応も早かろうと。

Wi-FiのAPなので、アンテナが外部に出ていたほうがなにかと便利と思い、I-O DataのWN-AC433UAがなんだか在庫があるということで、何も考えずに注文して届いたわけですが、当然Arch Linuxでは認識できないわけです。動いたという報告が見当たらなくて、しばらく途方に暮れていたのですが、日をあらためて調べ直すと、チップセットは「Realtek RTL8811AU」とのこと。つまり、このカーネルモジュールを入れればよいということになります。

すると簡単に、AURとして「rtl8812au_rtl8821au-dkms-git」があることがわかりました。名前はあれですが、RTL8811AUもサポートすると書かれています。

そうくればあとは簡単です。

とりあえず、AURの環境が準備されていなかったので、こちらの手続きにしたがって、yaourtでAURのパッケージコンパイルとインストールができるようにします。

そして、linux-headers、dkms、rtl8812au_rtl8821au-dkms-gitをインストールすることになります。最初はカーネルモジュールだけ入れて、dkmsが必要と言われてdkms、linux-headersがないと言われてlinux-headersを入れたのですが、この逆がよいのではないかと思います。

sudo yaourt -S linux-headers dkms
sudo yaourt -S rtl8812au_rtl8821au-dkms-git
dkmsを使うのは初めてだったので再起動してしまったのですが、そうしなくてもなんとかなるんだろうとは思います。

これでdkms statusすると
$ dkms status
rtl8812au_rtl8821au, 4.3.22_beta.r9.928e27f, 4.5.0-1-ARCH, x86_64: installed
と、カーネルに組み込まれていることがわかります。そこでおもむろにWN-AC433UAをUSBポートに挿し、lsusbすると
$ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 006: ID 8087:0a2a Intel Corp.
Bus 001 Device 004: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
Bus 001 Device 002: ID 04bb:0953 I-O Data Device, Inc.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
こんな感じで見えるようになりました。ip linkすると、
$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
3: wlp2s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
4: wlp0s20u1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether yy:yy:yy:yy:yy:yy brd ff:ff:ff:ff:ff:ff
ちゃんとデバイスが生えています。よかった。

まだ通信テストができていませんが、それはこれから。