起動ディスクをSSDにした
SSDに換装したのではなくHDDはそのままに起動ドライブをSSDにコピーする形。OSはWindows 7。
HDDはC, D, E, Fの4パーティションでC:が起動ドライブ。このC:のみをSSD化したわけだ。
CFD販売のSSDなのでクローンはOEM版のEasyDiskCopyをサイトからダウンロードして使った。余談だが付属のネジ8本中4本はSSDにはうまくハマらず使えなかった。HDDには使えるようなのでSSD側のネジ穴がシビアなのだろう。
まずSSDを内臓SATA接続し起動、EasyDiskCopyでSSDにCドライブをコピー。ジャンクションは維持する設定にした。コピー速度はファイル単位でパス名順に行なうので割と遅く、30GBが40分程度かかった。
画面に従い電源を落とし、内蔵HDDの電源ケーブルをはずして(SATAケーブルはそのまま)起動すると、普通に立ち上がった。一点、ページファイルを置いていたFドライブ(HDD)が無いためそのエラーが表示され、一時的にSSDのC:にページファイルが置かれた状態になった。
次にWindowsを起動したままHDDの電源ケーブルを繋ぎ、HDDを認識させる。ドライブのシグネチャがクローンしたSSDと衝突するため繋いだだけではマウントされない。ちなみにAHCIモードのSATAはホットプラグしてOKのはずだが、古いPCなのでマザーボードくらいなら仮に故障しても構わないと考えての乱暴な行動。*1
コンピュータの管理>ディスクの管理で接続したHDDを右クリックし、オンラインを選択。HDDの旧C〜Fパーティションがばらばらの順序でD〜Gとしてマウントされる。EasyDiskCopyの説明によると、オンラインにした段階でSSDをはずしてHDDのみに戻しても旧Cドライブは起動ドライブにはならなくなる可能性がある。
各パーティションを右クリックし、ドライブ文字とパスの変更でドライブレターを変える。旧C:は適当な未使用文字に変更し、旧D:〜F:を改めてD:〜F:に割り当てなおした。
再起動し、BIOSのHard Disk Boot PriorityでSSDを優先設定したところ、C:のみSSDになった形で他のHDDパーティションも元通り認識された。
念のためC:のジャンクションを確認して、移行完了。
失敗パターン
と書くと順調にできた様に見えるが、その前に2回失敗している。
1度目はEasyDiskCopyでコピーした後、HDDを外さずにSSDを優先設定して起動した時。
windows failed to start. A recent hardware or software change might be the cause... File: \windows\system32\kdcom.dll Status: 0xc000000f Info: □□□...□□□DLL□□□...□□□windows□□□...(おそらく日本語が文字化けしている)
というメッセージが黒画面に表示され、起動しなかった。Windowsのシステム回復オプションで修復しようとしても前出のファイルが壊れているが修復不能というメッセージがでる。
もしやコピーが失敗していたのかと、もう一度コピーから試そうと思いEasyDiskCopyを起動すると
「dvshadowの実行に失敗しました」と出てコピーできなくなっている。ドキュメントにあるようにサービスの状態を確認したが変わらず。ログを見ても解決できそうにない。
ERROR: Selected writer 'Registry Writer' is in failed state! - Status: 9 (VSS_WS_FAILED_AT_FREEZE) - Writer Failure code: 0x800423f4 (VSS_E_WRITERERROR_NONRETRYABLE)
そこで次善の策としてネットで評判のよさそうなEaseUS ToDo Backupの無料版*2を使ってクローンすることにした。パーティションのクローン自体は15分程度と速く完了したのだが、起動してみるとX:(SSD)のWindowsから起動してProgramDataもSSDだがProgram FilesやUsersはC:(HDD)を参照するという変な結果に。
そこでドライブレターの変更でC:(HDD)を適当なものにして再起動したところ、今度はログインすると「デスクトップの準備をしています...」というメッセージが出るように。数分表示された後で画面は切り替わったが、今度は青っぽい背景に「このWindowsのコピーは正規品ではありません」というメッセージが右下に出るだけで何も起こらない。マウスポインタはあるのだがアイコンもなくキーにも反応しないのでどうしようもない。
そこからもう一度手順を検討しなおして前述の通りにしたら、移行できたわけだ。
dvshadowが一度失敗していた理由は不明。添付ドキュメントの通り1 NTFSパーティションのHDDを換装する場合は十分スムーズにできる気がする。
注意点としてファイルの作成日とアクセス日が保持されない。ディレクトリの場合は修正日も移行時間になってしまう。
シャドウコピーの削除
失敗パターンでEasyDiskCopy (dvshadow)が途中で終了したせいだろうか。シャドウコピーがHDDにいくつも残っていた。
vssadmin list shadows で確認できる。そのままにしておくとフォーマットでもしない限りデータが残ってディスクを圧迫する。
削除方法はvssadmin delete shadows /?にある。今回は復元ポイントなどもなくすべて移行時にできたものだったので vssadmin delete shadows /all で一括して削除した。
Java (JRE 1.8.0 update 91)が動作しない (Windows 7, 32bit)
実行・アンインストールできない
Javaを使ったプログラムを実行しようとしても何も起きない。タスクマネージャを見るとjavaw.exeが暴走している。Javaのコントロールパネルを開こうとしても同様。
再インストールするためにアンインストールしようとしても同じ。javaw.exeを強制終了したところ正常にアンインストールが始まった。
インストールできない
しかし改めてJREをインストールしようとすると、最後の段階でやはりjavaw.exeが暴走して途中で止まってしまう。
javaw.exeを強制終了すると今度はjavaws.exeが暴走して、それを終了するとエラー1603でインストールが失敗した。
ファイル自体は展開されているのだが、そこからjava.exeを使おうとしてもやはりフリーズする。
符号化方式"UTF8"文字0xHEX<は"EUC_JP"と同じではありません
PostgreSQL 8.4 のメッセージでこんなのが出た。
意味が理解不能なので元のメッセージを見ると、"character 0xHEX of encoding "UTF8" has no equivalent in "EUC_JP"となっていた。
つまり正しくは「エンコーディング UTF8 の文字 0xHEX は対応する文字が EUC_JP にない」ということ。*1
今回の場合はクライアント側はすべてEUCjp-winなので理論上はそれ以外の文字が入る余地はない。該当するデータを見てみたところ単にpsqlで直接データを挿入した時に表外の文字を入れてしまっていたと判明したのでデータを修正して対応した。
古いシステムのメンテで出くわしたメッセージなので今はどうかと見てみたところ、9.5では "符号化方式"UTF8"におけるHEXバイトシーケンスを持つ文字は"EUC_JP"符号化方式では等しくありません" と、やはりおかしい。
ただ誤訳の報告はどこに投げればいいのかがわからなかった。GitHubは単なるミラーのようなので公式のアカウントを作ってチケットを作成するのだろうか。ドキュメントの翻訳は別プロジェクトがある雰囲気なので、メッセージの翻訳も別なのかもしれない。割といろいろなプロジェクトで細々と翻訳やその訂正を投げているが、検索しても窓口や手順がわからなかったため断念した。
Windows 10への更新予告が出た。
Windows Updateを自動にしているPC。GWXのKBは入っているものの、そこからの予約は行なっていない。いきなり15分後にWindows 10にアップグレードするという通知が出た。
予約していない場合でもウインドウを閉じると強制アップデートされるという話は聞いていたので検索した手順でキャンセルを行なった。
更新する場合は通常90分で終了するという表示だったが別のより新しいPCで更新したところ3時間かかった。
KB3035583を入れておらず手動アップデートにしているPCでは通知は何も出なかった。ただしKBを何回隠しても時たま復活してくるので油断できない。中身が変わると復活するのだろうか。
/以下のパーミッションを壊してしまった
find . -print0 | xargs -0 chmod o+rするつもりが.の代わりに/を打ってしまった。しかもrootでサーバ設定をいじっていた流れで作業していたので権限に不足無し。なぜchmod -R o+r .ではなくわざわざ長いコマンドにしたのか不明だが、だからこそtypoもしたのだろう。/proc以下でエラーが多発したところで気づいたが、^Cを押す前に処理が完了してしまった。
バックアップは当日分があるがデータの復旧用として一部ディレクトリしか取っていない。
大惨事ではあるがchmodするときは数値指定したり対象をallにしないように癖を付けていたのですべてが644になるような悲劇は免れた。とりあえず大事なshadowとhome直下、それに公開鍵認証や証明書のあたりを戻す。
chmod -c o-r /etc/shadow* /etc/ssh/*_key chmod -cR o-r /home/hoge /home/*/.ssh ...
当該サーバ(corrupted)は幸い設置したばかりなので同じディストロ(el7)を使っている他のサーバ(master)から設定をコピーすればそれなりに復旧する(はず)。
完全に壊した場合はrsync -aで正しい状態のファイルを参考用に転送してchmod --referenceする手があるようだ。今回o+rしただけなので、考えた末、更に簡単にmasterでo-rなファイルの一覧を取得してそれをcorruptedに適用することにした。
# master find / ! -perm -004 > perms.txt scp perms.txt user@corrupted: # corrupted xargs -d '\n' -a perms.txt chmod o-r 2>&1 | less
/proc, /sys, /tmpで多少エラーが出たが、/home/*/以下の細々としたものを除外すればかなり元に戻ったと思う。
最後に問題のコマンドを再実行しないように、upキーでbashの履歴をたどって、やらかした行をコメントアウトしてdownで戻る。
