HDDの物理障害をDIY復帰

Thunderbolt で iMac に接続していた EyeTV の録画用途に3TBの3.5インチハードディスクを使っていました。


深刻な物理障害は3回目ということもあり、バックアップなどの準備は問題ないのが幸いでした。


と思って検索してみるとこんなのがありました。


アマゾンで安価だったのですが、今回は外れ製品だったようです。


しばらくするとヘッドの異音はなくなり、こんな希望が見えたのでメールで問い合わせてみたところ、PCB 故障の疑いがあるということでした。

http://hkitago.tumblr.com/post/168312509896


そこで回路の修理に無水エタノールを近所のドラッグストアで買ってきました。

eBay で交換用の基板もあったのですが、ファームウェアを偽装するのに一度大陸へ送還するという面倒さもあって断念し、データと電源部分の接点を綿棒を使って拭いてみました。

真ん中上と右下に二つあるネジ穴近くにある3箇所の接点です。

すると、なんということでしょう。


接点復活スプレーという選択肢もありましたが、成分が精密過ぎや価格、など考慮した結果。


結構残っているので眼鏡のレンズ拭きに毎日使っています。

http://hkitago.tumblr.com/post/168313351751


最後に、誤字埋込ばかりで失礼しました。

参考:

High Sierraで不明なログイン項目を削除する

High Sierra へ移行してから気持ちが悪かった事の一つに、システム環境設定>ユーザとグループにあるログイン項目に不明な項目が30個ほど並んでいるという現象がありました。

公式のサポートフォーラムでも同様の質問があり、従来の ~/Library/Preferences/com.apple.loginitems.plist やキャッシュファイルの削除という方法が使えなくなってしまいその時点では有益な回答がありませんでしたが、一ヶ月ほど経ってもう一度確認してみると解決方法を見つけた人がいました。

http://hkitago.tumblr.com/post/166022085256

具体的には、~/Library/Application Support/com.apple.backgroundtaskmanagementagent/backgrounditems.btm をゴミ箱やデスクトップなどに移動して再起動すると直ります。

実際には参考にあるギリシャ語サイトを先に見つけましたが、投稿の日付を見るとサポートフォーラムの方が早いようで流石本家は違うなと感心。

参考:

photoanalysisdプロセスの挙動 High Sierra編

近年更新毎に何かのプロセスが悪さをしてくる MacOS ですが、引き続き photoanalysisd プロセスが昨年のものとはちょっと違った挙動をしていたので紹介します。iTunes と 写真アプリのライブラリは 4TB の外付けドライブに置いているのですが、排出しようとした時に次のようなエラーを返してきたことで発見しました。

そこで lsof コマンドを使って調べてみると、photoanalysisd プロセスが写真アプリを起動していないにも関わらず常時ライブラリの中にあるデータベースファイルを読んでいることが分かりました。これは OS の起動直後から開始しているようで、アクティビティモニタを見ても CPU 時間が圧倒的な数値を記録しています。

hkitago$ sudo lsof | grep /Volumes/TOURO\ Desk/
photoanal 497 hkitago txt REG 1,18 32768 6114807 /Volumes/TOURO Desk/写真 Library.photoslibrary/private/com.apple.mediaanalysisd/MediaAnalysis/mediaanalysis.db-shm
photoanal 497 hkitago 29u REG 1,18 45486080 6114800 /Volumes/TOURO Desk/写真 Library.photoslibrary/private/com.apple.mediaanalysisd/MediaAnalysis/mediaanalysis.db
photoanal 497 hkitago 30u REG 1,18 4152 6114806 /Volumes/TOURO Desk/写真 Library.photoslibrary/private/com.apple.mediaanalysisd/MediaAnalysis/mediaanalysis.db-wal
photoanal 497 hkitago 31u REG 1,18 32768 6114807 /Volumes/TOURO Desk/写真 Library.photoslibrary/private/com.apple.mediaanalysisd/MediaAnalysis/mediaanalysis.db-shm

「強制的に取り出す」を選択すると取り出すことはできた(データベースファイルの破損も気になる)のですが問題は起きなかったので、このことから設計志向を察するにメディアファイルを外付けディスクに配置することは例外なのかと思う一方、近年の SSD の普及などから内臓ディスクの容量は小さくなっていることや、iCloud ストレージを売り出したい意図などを考えると唸ってしまうものがあります。

関連して mediaanalysisd プロセスが DarkWake (ディスプレイスリープ)時に CPU を常時 50% ほど使っていることがあったりとやはり OS アップデートは人柱になること請け合いで、当面は iTunes や写真アプリを使わない時は外部ディスクを排出しておくという措置しかなさそうです。ただ、妻のアカウントでは状況が同じにも関わらず問題が起きないので発生条件は不明なのが不思議なところで、解決方法をもう少し模索したいと思います。

参考:

SSDを増設したiMacを調整

SSD を増設して起動ディスクにした iMac はその後 Apple Hardware Test を行ったところ次のような 4SNS/1/40000000: TH00-9.000 というエラーを返してきました。これは電源分岐を行ったことが原因でハードディスクの温度センサーが接続されていないために起こるようで、言われてみればファンの音が若干大きいかなという気がしたので、iFixit の方法に習って SSD の電源をマザーボードから直接引っ張ることにしました。

電源ケーブルは 922-9862 という商品コードらしいので、eBay で検索して $5.29 (Free international shipping) で中国から発送のものを購入しました。

前回の作業で分解の要領は得ているので淡々と作業を進めて行ったのですが、購入した電源ケーブルの接続部分が逆方向に曲がっていたので両面テープを貼り直し SSD を裏返してくっ付けることになりました。

再度行なった Apple Hardware Test は問題もなく、ファンもおとなしくなり、ようやく修理完了です。

最後にハードウェアネタが続いた余談で、”Apple is Really Bad At Design“ という記事に、電子レンジやテレビを例に「多くの人は部品を交換しないで本体を買い替えるんだよ」というコメントがあり、今回の作業を終えた後だけあって興味深く読みました。

参考:

iMacにSSDを増設

注意:ここで紹介した電源を分岐する方法は、Apple Hardware Test でエラーとなるので、電源を直接マザーボードから引く方法について書きました。「SSDを増設したiMacを調整

開発用途の機種に未だ iMac Intel 21.5インチ Mid 2011 EMC 2428 を使っています。購入時は 8GB だったメモリ容量は3年ほど前に Parallels と Photoshop の同時利用で重たくなったので最大 16GB に増設したのですが、近年は Xcode と Android Studio の同時利用に加えて、ハードウェア買い替えの目安の一つである IME(インプット・メソッド・エディタ)の和英文字入力切り替え時、特にライブ変換の際にもたつきと引っかかりが感じられるようになりました。その度にアクティビティモニタから日本語入力プログラムのプロセスの強制終了して騙し騙し使っていましたが、丁度(改造に失敗しても潔く買い替えの理由になる)iMac シリーズの刷新の噂もあり内臓 SSD を設置して起動ディスクを変更することにしました。

もう今更感たっぷりな作業なのは恐縮ながら Amazon で用意したものはこちら。

余談で SSD は 2TB が激安価格だったので一度挑戦しましたが、案の定返金されて 525GB を買い直しました。


SSD の固定は Vintage Computer のキットを使わずにホームセンターで買ってあった両面テープにし、

前例報告は多々あるので作業を要約しますと、OWC が提供しているインストールビデオの通り片方に二枚貼り DVD ドライブ裏の曲面に合うようにしました。

マザーボードの背面側から、シリアルケーブルは下から回すという説明だったのですがヒートシンクに沿って通っていた黒いケーブルがあったので上方向にしました。

その結果 SSD 上部で折り返す羽目になってしまったので、0.3m の短いものでも良かったなと少し後悔しました。

最終的には下L型の二股電源ケーブルのお陰でヒートシンク部分と衝突することなくうまく収まりました。


最後に失敗談として、HDD のサーモセンサーのピンが抜けずマイナスドライバで押したところどこか遠くの方でカラ〜ンと音がしてプラスチックの接合部分を無くしてしまいました。幸運なことに金属部分は残っていたので組立時には iFixit の拡大図で極を確認しラジオペンチで差し込み絶縁テープを貼っておきました。(焦って写真がピンボケ笑)

起動後に元の内臓 HDD からデータを移行し sudo trimforce enable を実行し完了です。Fusion Drive 化も検討しましたが、ファイル配置が自動的に決定されることがなんとなく嫌だったので却下し、SSD をシステム用に、HDD をデータ用として運用しています。デスクトップ機種でシステム終了することが少ないため起動時の速度に喜びを感じることが少ないのですが、Parallels などのアプリの起動時や IME 切り替えの滑らかさなど、OS の更新による快適さも考えられるので結局買い替えをまた逃すことになってしまいました。


それでも片方の USB 2.0バスが逝ってしまったり限界がかなり近くなっていることは間違いないので、子供に譲るまでもう少し頑張ってもらいたいところです。

参考:

Chromeブラウザのトップサイトを変更する

近年 Netflix や DAZN と言ったストリーミング配信サービスが充実してきました。開発環境では Safari ブラウザを使っていますがこれら動画配信系のサービスを利用するとエラーを起こして止まってしまうことがよくあったので Google Chrome ブラウザを使用することにしています。その際に、Google Chrome ブラウザで新規タブを開いた時の「起動ページ」に表示されている8つのページリンクのサムネール、これを Safari ブラウザでは「トップサイト」と呼んでいてドラッグ&ドロップのマウス操作で追加操作ができるものの、Chrome ではページの読み込み回数でのみの判定となっていて且つ期待した様に追加ができないという挙動があったので調べてみました。

まず辿り着いた StackExchange では、Chrome のデータファイル Preferences に記述されている locations の値を編集すれば良いということが分かったので、macOS でのファイルパス ~/Library/Application Support/Google/Chrome/Default に移動して探してみたところ、該当する値がありませんでした。そこで回答の2つ目を見ると、2012年にリリースしたバージョン 17.0.963.56 以降の Chrome ブラウザは Preferences テキストファイルの記述によるデータ管理を止めて SQLite に変更したことが分かりました。

同じ Default 内に Top Sites という拡張子の無いファイルがあったので DB Browser for SQLite で開いて見ると thumbnails テーブルにずらずらと該当データが保存してありました。

url_rank 項目の値順に左上から並ぶことになっていると推測できるのですが、この状態でもトップサイトにサムネールが表示されないのは問題です。

http://hkitago.tumblr.com/post/164159265281

この理由は、トップサイトの各サムネールをマウスオーバーすることで表示される右上の「バツボタン」を押し消去すると Preferences JSON ファイルの most_visited_blacklist キーに MD5ハッシュで短縮した redirects 項目にある URL の値を格納し、起動ページを表示する度に参照していることが原因でした。現時点(バージョン 61.0.3163.39)でこの仕様ですと、過去によく閲覧してトップページに表示されていたサムネールでも、一旦バツボタンを押して消去してしまうと再びトップサイトに加えることができないというもので、実際に DAZN のサムネールはあったのですが、まだコンテンツが不足していたことからアカウントを作成しなかったのでバツボタンを押してサムネールを消去していました。

ということで SQLite データはそのままに、Preferences JSON ファイルを TextWrangler で most_visited_blacklist":{} と編集し保存、Chrome の起動ページに8つのサムネールの表示を確認し、改めて表示させないサムネールのバツボタンを押しました。ただ、DAZN サムネールの画像が表示されておらず SQLite データを確認したところ、 thumbnails テーブルの thumbnails 項目が NULL となっていたため、適当に画面のスクリーンショットを 424×284ピクセルの JPEG データに変換して BLOB データとして格納しました。

「利用頻度の高いトップサイトに表示させたくないから二度と現れることがないブラックリスト行き」という設計は如何なものかとは思いますが、データの移行からと思われる url_rank 項目の値に -1 を持っているものもあったりと、今後の改善に期待したいところです。

参考:

安価な子供の位置情報確認方法

昨年から子供が習い事を始めたのでスマホを使った位置情報の共有方法を模索してきました。最善策は、iOS にデフォルトで組み込まれている「友達を探す」アプリの利用(実際夫婦間ではこれ)なのですが iPhone 端末が高価なので、開発時に検証用に使っている「Huawei SIMフリースマートフォン P8 lite」に、月間通信量500MB未満は無料の「0 SIM」を挿して渡すことにしました。そしてこの頃、Google の位置情報共有サービスは Google+ を使った複雑な設置が必要だったので Glympse をインストールしました。

iPhone と比較して Android 端末は GPS の性能が貧相な(位置情報ゲームではこのブレを悪用する場合もあるとかないとか…)ので、少しでも改善すべく GPS Locker をインストールしました。

また10秒以上電源ボタンを押すと強制再起動するというハードウェアのユーザインタフェースの難癖があり鞄の中での置き方を教えるという事もありました。さらに Glympse は最大で4時間までしか共有の設定ができず、Gps Tracker を使った自作システムなどを試しましたが、端末のスリープ時に位置情報を更新できない Android 特有の問題を解決できず悶々としていたところ、遂に Google マップがサービスに対応したので移行しました。

子供用の Google アカウントを取得し Google マップの共有設定は問題なく Wi-Fi 環境下で検証できましたが、端末の「設定>データ通信量の管理>ネットワーク通信を行うアプリ>システムアプリ」の設定はどれを選ぶべきか説明がなく一つずつチェックを入れて試してみたところ、次の3つを有効にする必要がありました。

  • マップ
  • Google Backup Transport
  • Android OS

Google マップアプリは常時起動しておく必要がなく、位置情報共有も停止にチェックを入れるまで事実上恒久的に設定しておく(急に遊びに行く場合に手渡すだけ)ことができ、ブラウザ上のマップでも問題なく位置情報が確認が可能です。一つ問題が残るのは、友達を探すアプリのような出発/到着の通知機能がないので FB Messenger アプリをインストールしました。前述のように GPS の性能上、ごく稀に1Km以上ブレたりすることがあるので、その場合メッセージを送って確認するようにしています。

最後に気になるデータ通信量について、設定>Googleから全てのデータの自動同期をオフに設定し、1日3時間ほどの利用で(メッセ通信などが)多い時でも10MB程度で、もちろん毎月の運用費は掛かりません。

以上、携帯端末を公共の場所で利用する場合のルールとマナーについて子供に教える良い機会にもなっている、お勧めの利用方法の紹介でした。お年寄りにも是非どうぞ。

P.S. バッテリ容量を考慮すると今から端末を用意する場合、アマゾンでベストセラー1位の P9 lite が良いかと思います。

参考:

MySQL 5.7のLaunch Daemonを使う

Sierra に更新し前投稿の問題以降に再起動をすると、ERROR! The server quit without updating PID file というエラーを出力し MySQL が起動しなくなるという新たな問題が解決しなかったため、MySQL 自体の更新も兼ねて MySQL 5.7をクリーンインストールしました。そこでマニュアルを参照してみると、意外にも MySQL の起動にコントロールパネルの利用を推奨していたので試してみたところ、またまたうまく機能しなかったので少し調べてみました。

その結果、MySQL 5.6 を Yosemite にインストールした時は、起動アイテムを使っていた公式のコントロールパネルが機能せず、別途起動デーモンを書いていた(まさかの公式マニュアルに掲載)のですが、MySQL 5.7 のインストーラは独自の起動デーモン com.oracle.oss.mysql.mysqld.plist/Library/LaunchDaemons/ に配置するそうなので、前バージョンからの移行で 5.7 を利用する場合は com.mysql.mysql.plist を削除する必要がある、という簡単な解決方法でした。

ただ、前バージョンに引き続きコントロールパネルを利用しないという方法も可能なので、その場合は上述のように com.mysql.mysql.plist を削除することなく、コンパネやコマンドを使って公式の com.oracle.oss.mysql.mysqld.plist を読み込まないように、ファイルの場所を代えるなど注意をする必要があります。

参考:

Please DISCARD the tablespace before IMPORT エラー対処

MacOS Sierra 移行前の話なのですが、innoDB を扱う案件があり開発環境で設定してみたところ、phpMyAdmin 4.6 上でテーブル名は見えているのだけど「テーブルがありません」というエラーを返してきたので、で該当テーブルを削除した後に再度同じ名前でテーブルを作ろうとすると今度は、”Please DISCARD the tablespace before IMPORT” というエラーを返してきて、二進も三進もいかなくなったということがありました。

そこで例によっておググりなさってみると、/usr/local/mysql/data にある問題となっている DB 名のファイルを消去する方法を見つけたので試してみたところうまくいかなかったので、MySQL の起動を停止し他のファイルを消すか名称変更しつつ再度 MySQL を起動する、という手順を繰り返しディレクトリ内を観察してみた結果、[PC_Name].local.err や [PC_Name].local.pid も関係することが判明し、元々開発環境でデータの消失は問題がないということもあり、次のように MySQL が起動時に参照したり生成するファイルも削除してみたところ、無事テーブル生成が可能になりました。

$ cd /usr/local/mysql/data
$ sudo launchctl unload -F /Library/LaunchDaemons/com.mysql.mysql.plist
$ sudo rm -rf [問題のDB名]
$ sudo rm -rf ib_logfile0
$ sudo rm -rf ib_logfile1
$ sudo rm -rf ibdata1
$ sudo rm -rf [PC_Name].local.err
$ sudo rm -rf [PC_Name].local.pid
$ sudo rm -rf phpmyadmin/
$ sudo launchctl load -F /Library/LaunchDaemons/com.mysql.mysql.plist

もちろんこの後で再び phpMyAdmin を利用するには phpmyadmin/sql/create_tables.sql をインポートし再設定する必要があります。

参考:

photoanalysisdプロセスの挙動

MacOS Sierra に更新してアクティビティモニタを見てみると photoanalysisd というプロセスが常時100%超えを示していて、丁度重い作業をするところだったのでリソース不足を解消するために次のような launchctl コマンドを使って一旦止めることしました。

http://hkitago.tumblr.com/post/151969879196

作業も終わったところでさてこのプロセスは何をしているのかと、アクティビティモニタのプロセスを開いて「開いているファイルとポート」タブからログを眺めていると、写真アプリのライブラリ内データを読んでいることが分かりました。

更に “~/Library/Application Support/AddressBook/…” というログを見つけたので、写真アプリのアルバム>ピープルを見るとこのようなメッセージを表示していました。
%e3%82%b9%e3%82%af%e3%83%aa%e3%83%bc%e3%83%b3%e3%82%b7%e3%83%a7%e3%83%83%e3%83%88-2016-10-19-6-40-18

実際に写真アプリを起動すると photoanalysisd プロセスの CPU 使用率は0%になり、閉じると再び上昇するという挙動をしていましたので、作業中は上述したコマンドでプロセスを終了し、夜間など使用しない際に再度プロセスを読み直すという方法が良いのかと思います。

夜間に放置しておいたところ、約4万2千枚ある写真のライブラリを12時間くらいかけて解析していました。
%e3%82%b9%e3%82%af%e3%83%aa%e3%83%bc%e3%83%b3%e3%82%b7%e3%83%a7%e3%83%83%e3%83%88-2016-10-19-8-19-33

参考: