久しぶりに玄箱を復活させた（純正で。）が、Windows10からつなぐのに一苦労した話

　調べてみると、自分が持っている玄箱HGは2004年に発売されたらしい。もう15年以上も前だ。
15年前といえば、まだWinodwsは XPが全盛期だった時代で、もちろんスマホやタブレットもまだ登場しておらず、ガラケーが3Gになった頃だっただろうか(じぶんのblogを見てみたら、その当時はCDMAのガラケーau A5404Sを使っていたようだ。そう考えるとすごい昔だ・・・。)。
　それでも、2000年前後にPCのインターネットへのアクセス手段が、それまでのダイアルアップ接続からADSL接続への移行が一般化したこともあって、それによって宅内がLAN(ローカルエリアネットワーク)接続できるようになったことで、当時はNASを利用することの走りとなった、と記憶している。（ADSLによって多くのコンテンツをダウンロードすることになったことも。）

　そんな感じでわたしも購入して使っていた玄箱だったが、内蔵したHDDが故障して起動しなくなりその時のデータは飛ばしてしまった。それで、いつしか自分のガラクタ箱に眠ったままになっていた。
　ずーっと通電して使用しているとHDDが故障し、データを飛ばしてしまうことは自明なので、本来であればRAID-1対応の最新のNASに保存するのが正しい道なのだが、それほどのお金をかけるほどに重要なデータ保存でもない。
　ただ、Windows10のPCの内蔵SSDに保存したデータが容量を圧迫してきたので、そうした優先度の低いデータ退避させる先として、白羽の矢をたてた玄箱をなんとか復活させた、という話である。

　玄箱にHDDを入れて、設定用CD-ROMからLinuxを転送してあげればすぐに、ネットワーク上から見れるようになるし、telnetでアクセスできた。
　ただ、問題はそこからだった。
　たしか、Windows7ぐらいの時代までは使用していたはずの玄箱だったが、Windows10になってもう次のOSも出ている時代だ。Windows7から、NASへアクセスする環境がガラリと変わってしまい苦労した、というお話だ。

　

　どうやってもWindows10から玄箱の共有フォルダ（/mnt/share）を認識できなかったのだ。
　少し調べれば、SMB v1への対応が必要であることはわかったので、(1)Windows10でSMB v1を再設定（Windows10自体ではセキュリ上の問題で、すでにSMB v1は推奨されておらず、規定で無効化されているので、コンパネ内のWindowsの機能の有効化から、SMB 1.0ファイル共有のサポート 関連モジュールを明示的に有効化する必要がある。）したり、また、(2)LAN Manager 認証レベルも設定変更が必要、という要点は抑えたはずだった。
　しかしながら、それらを設定しても、なぜか玄箱の共有フォルダへアクセスできない状態が続いたので、それをログとして残しておく。

　まず、(1) SMBv1について。
　前述したWindowsの有効化からSMBv1のモジュールを導入しておくことだけでは、本当にv1が有効しているのか、はっきりしない。
　なので、管理者コマンドラインから、

sc.exe qc lanmanworkstation

と入力し、MRxSmb10が有効化して表示されているか確認します。
表示されなければ、つづけて、

sc.exe config lanmanworkstation depend= bowser/MRxSmb10/MRxSmb20/NSI
sc.exe config mrxsmb10 start= auto

と入力し、コマンドが成功したことを確認してから、PCを再起動してから、最初のコマンドをもう一回流して、MRxSmb10が有効化されたことを確認します。

次に、(2)について。とあるサイトで「玄箱はこれはNTLM（NT LanManager）のv1しか応答できないため、WindowsVista以降でのデフォルトNTLM v2応答だと接続できなくなる」、という情報を得た。つまり、

「手動でLAN Manager 認証レベルを「NTLM 応答のみ送信する」

と変更し、NTLM v1に対応させる必要がある、ということです。
　最初はRegeditでレジストリキーのLmCompatibilityLevelを0とか設定(一番、下位の設定にすれば大丈夫だろう、と勝手に判断していた。)してダメだ、ダメだ・・・、と思っていたのですが、上記の情報を得てLmCompatibilityLevelを2（つまり、NTLM 応答のみを送信する）にしてあげないと、いくらアクセスしても、撥ねられる・・・、という事がわかりました。

　すでにそのプラ素材の劣化が始まっており、HDDを玄箱に入れ直すときに外装が欠けたり割れたりし始めているので、もう活動限界を迎えている玄箱ではあるが、なにかのお役に立つこともあるかもしれないと思い、ログを残しておく。

Kindle(第８世代)のバッテリー問題とか、Surfase GoのNo Bootable Device問題

　まず、Kindle。
　予てよりAmazonの電子ブックリーダーのKindle第８世代を使っている。
　ここ一年弱くらいだろうか、ただしくbattery容量を検出できないのと、バッテリーが異常に減る状態となっていた。
　そのためか、起動のタイミングで「すでにbatteryが0%です」と、表示される状態になっていた。
買ってから結構経過しているので、バッテリー自体が古くなって動作ががおかしい（死にかけている）のかな？と、なんとなく半ばあきらめかけていた。

　

　バッテリー自体の交換ができるのかな？とかポツポツ探していたのだが、そうではなくて、どうやらKindleにバッテリードレインの問題があるらしい、という英語のビデオをYoutubeでみつけた。
　まずは、ビデオの通りリセットを実行してみたり、Kindleはファームウェアについても、調べてみると自動アップデートがOTAで走るようなのだが、自分のKindleでは最新版になっていないようだったので、３月のタイミングで出たより新しいファームウェア5.14.3.0.1も適用して様子を見てみた。（自分のKindleは5.14.2だった。）

　１－２ヶ月様子見したのだが、結局のところ改善せずバッテリーがすぐに０％になってしまう。ただ、不思議なことに「まもなくバッテリーが無くなりますよ。」というダイアログで警告が表示されるものの、OKを押してしておけば、そこからかなり使用できることである。
　なので、実使用上は特に問題はなくて、内蔵バッテリーを2,000円ほど支出して、Aliexpressで購入するかどうか、悩み中。

　つづいて、MicrosoftのSurface Goが起動しなくなった問題。
　No Bootable Deviceと表示され、電源ボタンを押しても起動デバイスが認識できなくなったのだ。子供が高校で使うため、学校で一律に購入したものなのだが保険には加入していなかった。

　それにしたって、子供が内部のデータをブートデバイスごと破壊できるとも思えないので、ひとまずネットをクロールして調査する。
　と、同様な問題が発生されている模様でWindows UpdateでアップデートのUEFI 1.0.34を配布したことでタブレットが起動しなくなる問題のようだ。
Redditにも"Do not take UEFI update 1.0.34 for Surface Go. It bricks your device." と書かれていたり（そんなこと言ったって、マイクロソフトは勝手にアップデートを適用してくるよね？）、ほかにもいくつかの書き込みがあって、世界的？にこのNo Bootalble Device問題が発生しているようだ。

　早速、マイクロソフトに電話してSurface自体のシリアル番号とUEFI画面で確認したバージョン番号（つまり1.0.34）を報告して対応をもとめると、すぐに交換の手続きに入ってくれた。
　後日メールを受信したら、ゆうぱっくの着払いで本体だけ送れ、そしたら交換品を送付する、という指示だった。
　ほどなくしてマイクロソフトからメールが届くので、それに従ってSurface Go本体だけを指定の箇所に送付すると、1週間弱で本体交換が終了した。
　しかしながら、No Bootable Deviceの表示だったので、全く内部のデータはサルベージできないので、本体は起動したとしても過去にローカルに保存したデータは救えなかった。

　マイクロソフトはバグったUEFEを勝手に撒いておいて、本体が起動しなくなったら、まっさらな本体に交換してハイ終了、である。酷い話だ。

ちょっと焦った…歳かな。

　メインのクレジットカード（家電店系）で、その家電店の通販サイトで購入したら、カード決済照会ではねられた。
　なんでだ〜？と思って、よくよくカードをみたら、セキュリティコードを間違えていた。

　あと、バイクの鍵が見当たらなくてガレージに行ったら、バイクに差したままだった（あぶな！）