徒然なるままに

 SDカードは壊れます USBメモリも壊れます…。 ということを皆さんは知らないのか、自分のは壊れないと思っているのか…。 忘れているのか…。 お客さんから急な連絡がありました。 カメラのSDカードが使えなくなったと…。 ELECOM製の32GBだというので、ELECOMに聞いてみると良いですよと、最初は返答。 すると2日ほどして、「3万円以上かかると言われたので躊躇している。一度チェックしてくれないか？」 いや、オイラがやったって、出来るかどうかわからんし…。 手間暇かけると、それくらいの費用になりますよと返答したけど、無理矢理メディアを渡され…。 仕方なく、持ち帰ってチェック。 確かに認識はしないが、fdiskで見ると、パーティションは認識している。 $ sudo fdisk -l ディスク /dev/sdb: 29.45 GiB, 31609323520 バイト, 61736960 セクタ Disk model: SD Card Reader   単位: セクタ (1 * 512 = 512 バイト) セクタサイズ (論理 / 物理): 512 バイト / 512 バイト I/O サイズ (最小 / 推奨): 512 バイト / 512 バイト ディスクラベルのタイプ: dos ディスク識別子: 0x00000000 デバイス   起動 開始位置 最後から   セクタ サイズ Id タイプ /dev/sdb1           8192 61736959 61728768  29.4G  c W95 FAT32 (LBA) ということは、論理的に壊れたのか？ $ lsblk NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT sdb      8:16   1  29.4G  1 disk  └─sdb1   8:17   1  29.4G  1 part  OKっぽい感じ…。 これなら修復...

タイミング的にはギリギリ Macが不調になっておかしくなったのか、そもそもおかしかったのか…。 バックアップに使用している2TBの外付けHDDへのバックアップが完了しなくなっている。 LaCieのHDDなんだけど、しばしば接続が切れることがある。 Yosemiteにアップグレードした頃から、頻発するようになって、El Capitanでも相変わらずだった。 スリープに入らないようにして、頻度は下がったものの、気づくと「ディスクの不正な取り出し」通知が表示されていて、ディスク自体の電源OFF/ONしか復旧の手立てがない状態が続いていた。 それで、バックアップがしっかり取れているのなら問題は少ないのだけれど、今回はバックアップが完全に取れない。 調査してみる これは困るので、ディスクユーティリティから修復を試みる。 何度か試すが、全く修復する気配がない。 OS自体は前回書き戻しに使用し、正常に動くようになっているので、今のうちになんとかしたい。 格闘してみたものの、どうもだめだ。 これまでの、バックアップを捨ててフォーマットするか、別のディスクを用意するか…。 結局、フォーマットをかけることに。 でもって、即座にバックアップ開始。 数時間かかって、全てのバックアップが完了。 念のため、再度省エネルギー設定から、スリープしないように再設定。 それから数日経つけれど、朝確認するのは正常にバックアップが実行されたかのチェック。 今のところ、以上はなく正常に動作している。 表示がおかしいのは… ちなみに、デスクトップ上のHDDアイコンがTimeMacheineではない事がこれまで多々あった。 これが正常な状態なんだけど、下のディスクと同じ黄色のHDDで表示されていて、一向に変わらない。 こんな時は、デスクトップ上で「表示オプションを表示」で操作。 「アイコンプレビューを表示」となっているのを、一旦「OFF」にして再度「ON」すると、正常に表示されるようになる。 このあたり、Sieraになると改善されているのだろうか…。 もうしばらく、ディスクの様子を見て、問題なければ一度アップグレードしてみようかなぁ。 ...

Guestでしかログインできない SkypeでのMeetingの予定があったので、10分ほど前に起動しようとしたら、何故か起動しない。 あれれ？ プロセスが上がっていて表示がおかしいのかな？などと思いながら、システムモニターで確認するが見つからない。 むむむ。 きっと再起動が必要な更新でもあって、その影響か？ などと思って、久しぶりに再起動をかける。 しばらくして、画面を見ると…。 「Guest」しか表示されていない。なぜ？ 自分のアカウントが表示されていないので、ログインできない…。 Meetingの時間が迫ったので、とりあえず携帯でSkypeをしつつ、Ubuntuのノートを慌てて持ってきて、何とか仕事は終えた。 修復するものの とりあえずGuestで入って、情報を集める。 結構な量の書き込みがある。 みな、同じような症状らしい。 ところが、復旧の手順は様々で、上手くいったりいかなかったり…。 https://discussionsjapan.apple.com/thread/10155314?start=0&tstart=0 まずは、シングルユーザモード（起動時に⌘＋S）で起動して、コンソールから以下のコマンドを実行してみる。 /sbin/fsck -fy /sbin/mount -uw / cd /Library/Preferences mv com.apple.loginwindow.plist com.apple.loginwindow.plist.old exit 残念ながら、復旧しない。 一応、ユーザフォルダは残っているし、バックアップディスクもOKそう。 次はセーフモードでの起動（起動音でShiftキーを押す→ロゴ表示で離す）する しかし、これでも戻らないことがあるとの情報… https://support.apple.com/ja-jp/HT201262 バックアップからリストアすることにした 翌日には確実に使用できないとまずいので、バックアップからの復元をすることにした。 再起動をかけ、⌘＋Rでリカバリモードに突入。 https://support.apple.com/ja...

母艦に戻ってみたら 先のブログを書いて、風呂に入って、メインマシンのiMacに戻ってみると、エラーらしき表示が出ている。 「正しく取り出し操作を行わなかった…」とかなんとか。 って、ずっと繋ぎっぱなしだし、そもそも母艦であるiMacを操作していないのに…。 よく見ると、すでにディスクはunmountされていて、見えていない。 仕方なく繋ぎ直して、認識させる。 ひょっとして、壊れているとバックアップの意味が無いので、確認しておく。 「ユーティリティ」→「ディスクユーティリティ」を選択。 まずは検証を行ってみる。 一部、異常があるようだ。 カタログファイルがおかしいらしい。 完了するまでに、1時間18分となっているが、これを書いている間に、予想時間が2時間になっている。 こりゃ、いつになったら終わるかわからない事態。 とりあえず、朝まで放置しておくか。 検証を中止して、修復に入ることにする。すでにエラーが有るわけだし、どうせ検証が終わってから修復するわけなので…。 修復を開始→予想時間：18分って…。 この予想はまったくもってあてにならないですな。 もうこのまま放置して、今日は寝る。

MacのTime Machineは秀逸 MacOSユーザなら、一度は聞いたことがある有名なバックアップソフトが「Time Machine」ですね。 標準で持っている、お利口なバックアップソフトです。 機能としては、差分バックアップを随時取ってくれて、過去の特定の時点のデータを取り出すことができるものです。 pdumpfs＋GUIといった感じです。 pdumpfsはrubyで書かれたバックアップ用スクリプトで、ハードリンクを使ってファイルをコピーバックアップするツールです。windowsでも動作します バックアップ用のHDDを接続して、そのディスクにバックアップを取るよう設定すれば作業完了。 初回だけフルバックアップになるので、少々時間がかかりますが、あとはチョロチョロ動いて、それ程邪魔になりませんし、 イザという時の保険としては安心な機能です。 これまでに、何度も助けられています。 もちろん、OSの入れなおしだとか、Updateの失敗なんて時も、簡単に復旧できるので必須ツールです。 まだ、使っていない人は、早めに導入すべきですね〜。 急にエラーを吐いた 突然、Time Machineがエラーを吐いてきたので少々慌てました。 朝見ると、バックアップが完了できなかったというじゃないですか…。 ディスクフルな場合は古いものから、順次消していくはずなので、ディスクが一杯ということはないはず。 思い当たる節がない。 Time Machineの環境設定を確認すると確かに「！」マークが表示されている。 0:04分で失敗していることには変わりがない。 この状態では安心して、ファイルの変更など行えない。 特に仕事のデータなども、結構な頻度で書き換えを行っているので、元に戻せないのはもの凄く不便だ。 放置しておくわけにもいかないので、正常に動作するように直すしか無い。 「ユーティリティ」→「ディスクユーティリティ」を開き、該当のHDDを選択。 「ディスクを検証」を行えば、状況が分かるはず。 ポチッとな…。約20分かかるらしい。 1TBあると、それなりに時間がかかりますね。 同階層のリンクが正しくありません スレッドレコードの数が正しくありませ...