いろいろやってみるにっき

なんとか自分の会社を立ち上げるところまで漕ぎ着けた、てきとーに生きている奴の日記

https化に伴い、表示できなくなっているリンクについて修復中。
2018年から遡って修正し、2015年分まで修正完了。


REGZAのDVDレコーダーで外付けHDDを認識しなくなったので その3

 

負けたような気はするけど、Ubuntu 11.04のVMを作成。元の手順はPCをUbuntuでブートなので、一応違いはある。

f:id:shigeo-t:20181008104601p:plain

 

インストールしている時から、マウスクリックが効かない。ThinkPadトラックポイントなんですけど。というわけで、キーボードで[TAB]キーと[Enter]キーで操作。ここまで来た。

f:id:shigeo-t:20181008110103p:plain

しかし、パスワードが入らない。このVMは破棄し、あえて簡易インストールで入れてみた。

f:id:shigeo-t:20181008112120p:plain

 勝手にVMware Toolsを入れてくれるのね。

f:id:shigeo-t:20181008112824p:plain

 こんなエラーがやっぱり出て(最初も出ていた)、そしてやはりマウスクリックができない。

f:id:shigeo-t:20181008112918p:plain

 

マウスクリックができないなか、ここまで来たが今度は別のエラー。XFS関係が足りないようだ。

f:id:shigeo-t:20181008113300p:plain


そこでxfsprogsをマウスクリックができない中、xfsprogsをインストールしようかと調べていたら、12.04でも動くしxfsprogsが最初から入っているという情報を見つけた。

 

そこで12.04を簡易インストール。

f:id:shigeo-t:20181008115053p:plain

しかし、やはりマウスクリックは効かず。12.04以降だとアプリを起動することもできない。

f:id:shigeo-t:20181008121144p:plain

 

ここで既存のWindows VMでも確かめてみた。やはりマウスクリックはできない。つまりUbuntuの古いバージョンとの相性とかそういう問題ではなく、オレのPCにトラブルがあるということ。

探してみるとオレと同じ状態になった人がいた。

最終的には、VMWareをアンインストールしたのち、再インストールで正常復帰した。(バージョンはいっしょ)

原因は不明。

Ubuntu側じゃなくVMware Workstation Playerだった。作業していたThinkPad T430sのVMware Workstation Playerはこれ。

f:id:shigeo-t:20181008125050p:plain

VMware Workstation Playerをアンインストールする作戦は2回実施。1回目はアンインストールしてインストールしたが、やはりマウスクリックはできず。2回目はC:\Users\(ユーザ名)\AppDataのVMware関係も削除してから再インストール。一瞬マウスクリックできたかに思えたが、やはりダメ。

 

今度はT430sのトラックポイントのドライバを消して再インストール。やはりダメ。PS/2マウスドライバで動いている時もダメ。タッチパッドを生かしてもダメ。

 

USBマウスを発掘して(1年300日くらいはマウスを触らないので、自分のマウスは引越しの時にしまったままだった)、T430sに接続してみるも、やはりクリックはできない。つまりハードウェア的にもソフトウェア的にもトラックポイントだからマウスクリックできないわけではないということになる。

 

msconfigでMicrosoft以外のサービスを止めるというVMwareのKB(Knowledge Base)でもダメ。

 

VMware Fusion用のKBもやってみたがダメ。

 

Dockerのために入れたVirtualBoxをはじめ、色々アンインストールしたが変わらず。

 

上記をやっていたら、T430sを10回くらいリブートするはめになったがVMware Workstation Playerは改善せず。

 

 ----

ということで、別のフロアにあるThinkPad W530で環境を作ることも考えたが、もう一度WSLのUbuntu 18.04に戻ってきた。

jarファイルのインストールができていないのではなく、jreがインストールされていなかった。jarファイルは存在する。javaコマンドが無い。素直に指定のコマンドでインストール。

f:id:shigeo-t:20181010090940p:plain

 

一個目のjreインストールの最後にエラー。

f:id:shigeo-t:20181010092609p:plain

結局3つともエラーが出たがjavaコマンドはインストールされた。

f:id:shigeo-t:20181010094828p:plain

色々試行錯誤したが起動した。

f:id:shigeo-t:20181010093821p:plain

起動した画面はこちら。

f:id:shigeo-t:20181010093940p:plain

 

次はPCに接続したHDDをWSLに渡せるか。通常のLinux上だとHDDを接続すると/dev/~になるがWSLではWindowsが先にアクセスするので/mnt/~ (~はドライブレター)になる。

 

とりあえず、接続できなくなったHDDをT430sにつないでみることに。REGZAで使用している時にどのようなファイルシステムかはわからないが、Windowsがマウントできる形式ではないので、このようになる。

f:id:shigeo-t:20181010095136p:plain

 

そして、REGZA HDD EASY REPAIRでは/dev/~ を期待しているはずなので把握できない。

f:id:shigeo-t:20181010095405p:plain

 

ということでWSLで修復することは不可能と確定。VMならUSB渡しでワンチャンスある気もするけど。なにがなんでも動かすという意思だけは完遂したw

 

UbuntuでブートしてREGZA HDD EASY REPAIRを動かすというのは正攻法だが、WSLで動いたことで満足したので、同じサイトにあったtestdiskで復旧する方法を試してみることに。

 解凍して起動。

f:id:shigeo-t:20181010095823p:plain

 開始したが実に遅い。こんなに遅いとは思わなかった。

f:id:shigeo-t:20181010095950p:plain

この状態だと下のフロアにいる時に使うPCが無い。とても不便。

f:id:shigeo-t:20181010180744j:plain


そこで起動しっぱなしでも問題が無い上階のW530で実施することにした。HDDを外して上に運んだ。それなら最初からそうすればよかった。T430sでやっていたのはラックからHDDを出すのがめんどくさいからだったのに。あと、W530を下に運ぶのはもっと大変なのでHDDを外す方が簡単。

 

あと、途中で止めて再度実行したのでもうダメかもしれない。W530には同じbuffaloの2TBがつながっていて見分けがつかないので通常使用の方は電源を落としてからtestdiskを実行。 

 W530では、確実にUSB3.0で動かすためにこんな感じの奴(メーカーは違うと思う)を使用。マウスを発掘した際に一緒に発掘された。

 

 11:30くらいに開始して放っておいたら、21時過ぎに勝手にWindows Updateでリブートされてた。上のフロアに上がった時にW530に眼をやったらまんなかにWindowsのマークがでてその下でプログレスインジケーターが回っていた。つまり再起動の起動段階。手遅れw

f:id:shigeo-t:20181011035232j:plain

 

今どきFlash使っているのはアレなんで、Flashは開かないのに(>_<)。

 

testdiskを再度開始したらOS全体が固まったので(多分testdisk以外の理由)、強制シャットダウン後、再度testdiskを開始したのがおおよそ21:30。

7時間くらい経過した時点で12%。一体いつまで掛かるのやら。

f:id:shigeo-t:20181011040231p:plain