hiro99ma old blog

2021年1月23日

Pi Pico

2021年になって何の記事を書こうかと悩んでいたところ、こういう情報を見つけた。

Raspberry Pi財団が550円の「Raspberry Pi Pico」発表、日本でもスイッチサイエンスが発売 | TechCrunch Japan
https://jp.techcrunch.com/2021/01/21/raspberry-pi-pico-raspberry-silicon/

Raspberry Piの系統と言うことはArmだろうけど、550円ってことはCortex-Aは難しいだろうな・・・と思ったら、M0+であった。

基板を見た感じでは、小さく整列したようなチップがなさそうだから、無線は使えないのだろう。無線があるんだったらスイッチサイエンスさんも発売に時間かかるだろうし。

本家はこちらか。

Meet Raspberry Silicon: Raspberry Pi Pico now on sale at $4 - Raspberry Pi
https://www.raspberrypi.org/blog/raspberry-pi-silicon-pico-now-on-sale/

やはり無線ものはなさそうだ。

USBでFLASHが焼けるとなると、これMbedじゃないの？と思ったのだけど、そういう単語はコメントにしか出てきてない。ということは違うのだろう。
まあ、Mbed enabledにもできるのかもしれんが、この情報では分からんな。

Raspberry Piは教育用(現実がどうかはさておき)だったと思っていたのだが、これも教育用なのだろうか。Arduinoなどと分野が重なるので、ちょっと不思議な気がしたのだ。「our first microcontroller-class product」とあるから、ラインナップとして必要と感じたのかもしれない。あるいはRaspberry Piの冠で市場を奪えるという目算が取れたのか。

そういうのはさておき、M0+の133MHzで、RAMも264KBというのはなかなかのスペックだ。特にRAMね。
サイプレスさんのFAQにM0とM0+の違いが載っていた。

Cortex-M0 と Cortex-M0+ - Community Translated (JA) - Cypress Developer Community
https://community.cypress.com/t5/Knowledge-Base-Articles/Cortex-M0-%E3%81%A8-Cortex-M0-Community-Translated-JA/ta-p/256652

パイプラインが3段から2段になると性能が落ちるような気がしたのだが、M0クラスだとそんなにパイプラインがあってもねぇ、ということなのだろうか。

CortexのM4はほとんど触っていないのだが、最初に出たM3やM0には良い印象を持っている。というよりも、それ以前の8bitや16bitのCPUの置き換えになってありがたいというのが正直なところだ。とにかく、デフォルトで32bitという安心感がある。intが32bitなのだ。私も実装するまで全然気に留めていなかったのだけど、意外と16bit CPUだと無意識のうちに範囲を超えてしまっていたりしたのだ。

ああ、理解不足だと笑いたければ笑うがよい。だが、こういう感覚でうまくいっているときもあるので、なかなか馬鹿にはできないのだ。まあ、失敗することもあるんだけど、そういうのはテストで、ね。

ともかく、最近は組み込みっぽいことをやってないので、こういうニュースに触れるのはうれしいところだ。

2020年12月6日

[js]Buffer.from()に'hex'を使えるが0xはいらない

いらないというか、付けたらいかん、という話だ。
JavaScriptとしたが、Node.jsだけの話かもしれん(違いがよくわからん)。

ハッシュ関数にBufferを引数に使うものがあった。

最初は文字列のハッシュを取っていたのだが、16進数のハッシュを取りたくなった。
あれこれ調べていたのだが、Buffer.from()の第2引数にencodingで'hex'とすればよさそうだ。
かんたんかんたん。

と思ったのだが、なんかハッシュ値がサンプルと違う結果になった。
Bufferがおかしい？

01: const value = '0x0000000000000000000000000000000000000000000000000000000000000000';
02: console.log(Buffer.from(value, 'hex'))

$ node buf.js
<Buffer >

あれ？

01: const value = '0000000000000000000000000000000000000000000000000000000000000000';
02: console.log(Buffer.from(value, 'hex'))

$ node buf.js
<Buffer 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00>

あー、第1引数を"0x"で始めてしまうと16進数ではない文字列ということでエラーにもならず処理してしまうのね・・・。

いくつか試してみたが、こんな感じだ。

"123" → 12
"1234jk56" → 12 34
"1y34" → (無し)

雰囲気だけでいえば、こうだ。

先頭から偶数文字数で16進数文字列(0-9, A-F, a-f)だけ処理する
文字列の途中で16進数文字列以外が現れたら、それより前の文字列を有効とする

それによって奇数文字数になるなら切り捨てる

エラーは出さない

Node.jsにも、その辺りのルールは書いてなかったのだが、共通仕様なのだろうか。

Buffer | Node.js v15.3.0 Documentation
https://nodejs.org/api/buffer.html#buffer_static_method_buffer_from_string_encoding

慎重にやるなら第1引数が16進数文字列かつ偶数であることをチェックするのだろうけど、JavaScript界隈の人なら格好良く処理できるのかもしれん。

2020年11月15日

[node]バイナリをHEX形式でconsole.logする

まだまだ初心者の域を出ない・・・というか、出るつもりがあまりなさそうなNode.js。
なんとなく書いて、なんとなく動いてしまうので、もういいんじゃないか、と思ってしまってね・・・。
それに、困ったらCやgolangで書きゃいいんじゃないの、と割り切ってしまっているのも原因だろう。
そもそも、必要がない限りNode.js使ってないし。

というわけで、今回はバイナリをHEX文字列でダンプしたいことについてだ。
Pythonのときもいろいろやったのだが、文字列ではないデータを扱うことが多いので、16進数を16進数のままコンソールに出力する手段がほしいのだ。

最初に出てきたのが、Bufferを使うやり方。

01: const data = "abc\x12\x34\x56def";
02: const dbuf = Buffer.from(data);
03: console.log(dbuf.toString("hex"));

$ node xx.js
616263123456646566

デバッグのためにBufferオブジェクトを作るのは嫌なのだが、デバッグと割り切ってしまえば良かろう。
デバッグ用の関数にしてしまうとかすれば心も痛むまい。

次に、文字列を1つ1つ16進数文字列に置き換える方式を考えたのだけど、こうなった。

01: const data = "abc\x12\x34\x56def";
02: for (let lp = 0; lp < data.length; lp++) {
03:     process.stdout.write(data.charCodeAt(lp).toString(16));
04: }
05: console.log();

$ node xx.js
616263123456646566

これのテストで「data.charCodeAt(lp)」をprocess.stdout.write()で出力させようとしていて、ずっとエラーになっていてね・・・。
consol.log()だと出力されるということに気付くのにかなり時間がかかった。
文字化けしたら考えよう、というやり方はよくないのだろう。

けど、「変なデータでも何でもいいから出力しやがれ」とは思ってしまうのだ。
それで動いてしまうと危険だから、ということなんだろうから、まあ文化の違いだろうね。

2020年11月4日

[vbox]おそるべしネステッド

数日前、WSL2とVirtualBoxを両方動かすためにネステッドなんとかをオフにした。

これはオンに戻した後の設定だが、この2つ。

ネステッドVT-x/AMD-Vを無効にすると両方とも無効になる。

で、その状態でゲストOS(ホストはWindows10で、ゲストはLubuntu18.04)を起動したのだが、どうにも遅い。
動いている間は気にならないのだが、起動するまでがとても遅い。

ただ、いつも立ち上がるまで他のことをしているので、ネステッドは関係ないかもしれない。

というわけで、目視で計測した。

ネステッドを両方オフ：2分くらい
ネステッドを両方オン：40秒くらい

うん、ここまで違うとは思わんかったよ。

ネステッドを一度オフにすると、GUIからはオンにできないようだ。
コンソールからできる。
Windowsだとパスも通ってるし、管理者権限とかもいらん。

virtualization - Virtualbox enable nested vtx/amd-v greyed out - Stack Overflow
https://stackoverflow.com/questions/54251855/virtualbox-enable-nested-vtx-amd-v-greyed-out

2020年11月3日

WSL2とVirtualBox 6.1.16(11月あたま)

前回、WSL2とVirtualBoxを試して失敗した。

hiro99ma blog: [wsl]何も考えずにWSL2にしたらVirtualBoxが起動しなくなった
https://hiro99ma.blogspot.com/2020/08/wslwsl2virtualbox.html

あれから2ヶ月ちょっと経ったが、どうなっただろうか？
失敗しても問題ない環境があったので、そこで試そう。

まず、「Windowsの機能の有効化または無効化」

Linux用Windowsサブシステム
Windowsハイパーバイザープラットフォーム

再起動して、まずWSL2をインストールする前にVirtualBoxのゲストOSを起動させる。
・・・エラーダイアログは表示されないが、起動の途中で止まったままになってしまった。

ネステッドページングをオフにしたら起動した。
前回もそうだったが、ネステッドVT-x/AMD-Vを有効化しないようになったおかげかもしれない。

そして、立ち上がりはするのだが、ゲストOSの動作が遅く感じる。
気のせいだろうか・・・。

元に戻す気がするので、ベンチマークを測っておこう。
そういえばLinuxでベンチマーク計測を行おうとするのは初めてだな。

CPUやメモリなどのシステム性能を比較するベンチマークツール | さくらのナレッジ
https://knowledge.sakura.ad.jp/1048/

こちらで、UnixBenchというものが紹介されていた。

https://github.com/kdlucas/byte-unixbench

cloneして、cdして、makeしたら"./Run"を走らせるだけで自動的にテストが開始される。

テストしたまま忘れて数時間放置していたが、最後は1218.8というスコアが出ていた。

次は、WindowsハイパーバイザープラットフォームだけをOFFにして、ゲストOSのネステッドVT-x/AMD-Vを有効化し、ネステッドページングも有効にした。

OFFにしても再起動を促されなかったが、ゲストOSを起動すると怒られた。
再起動すると起動できたので、まあよかろう。

今度のスコアは1278.4だった。
約60上がったのだが、これは有意な差なのだろうか？

正直なところ、このくらいだとよくわからんな・・・。

[node]base64urlのデコード

データで、base64urlでエンコードされている項目があった。

base64は、主にバイナリを文字列に置き換えたいときに使うものだ。
8bitの3バイトデータを、6bitの4バイトデータにする。同じ24bitだから。
6bitは64個なので、64個の文字列に当てはめる。A～Zとa～zで52個、0～9で10個。あと2個は”+”と”/”。

base64urlは、”+”と”/”を、”-“と”_”にしただけのものだ。
base64も最初からそうしておけば・・・と思わなくもないが、まあ時代的に仕方なかろう。

最初、base64urlというライブラリを使っていた。

https://www.npmjs.com/package/base64url

でも、なんか結果がおかしい(使い方が悪かっただけなのだが、このときはわからなかった)。

自信がないので、普通のbase64デコード方法で試そうとBufferを使うことにした。

https://nodejs.org/api/buffer.html#buffer_static_method_buffer_from_string_encoding

Buffer.from()にエンコードとして”base64”を指定すると、うまいことやってくれる。
固定文字列だったので、自分で”-“や”_”を置き換え、4文字ごとになっていなかったので”=”を追加。
そうすると、ちゃんと期待した値になった。

せっかくなので、base64urlの文字列でどういう例外が出るのかを確認しようとしたのだが・・・エラーにならない。
変な値になるわけでもなく、ちゃんとデコードできている。
あれ、そういうものなの？？

仕様としてできるのか、偶然できただけなのか、APIの説明では分からんな。。。

ちなみに、base64urlライブラリでもちゃんとできた。

Buffer.from(base64url.decode(“base64url文字列”))

のようにやっていたのだが、

base64url.toBuffer(“base64url文字列”)

だけでよかった。

でも、

Buffer.from(“base64url文字列”, "base64")

だけで済むのなら、それに越したことはないな。

GitHubを検索したら、base64はURLやファイル名で安全な文字列もいけるようなことが書いてあった。

https://github.com/nodejs/node/pull/5243/files

creatingとかencodingしか書いてないけど、decodeもいけるよね・・・？

探しづらいのだが、Node.jsのページだとここら辺だ。

https://nodejs.org/api/buffer.html#buffer_buffers_and_character_encodings

'base64': Base64 encoding. When creating a Buffer from a string, this encoding will also correctly accept "URL and Filename Safe Alphabet" as specified in RFC 4648, Section 5. Whitespace characters such as spaces, tabs, and new lines contained within the base64-encoded string are ignored.

ここのencodingは、エンコード・デコードの方じゃなくて、いわゆるエンコーディングだろう(そのまんまだが)。
それに、リンクが載っているRFC-4648 section5の表には"-"と"_"の方も載っているから、心配しなくても大丈夫だろう。

2020年11月1日

JWT

JWTという形式のデータが現れた。
現れたといっても、仕事の中で言葉が出てきたというだけだが。

JWTのJはJSONのJ、ということがわかって満足していたのだが、どうもちゃんと調べないとダメらしい。
ちっ。

JSON Web Tokenの略で、JWT。

JSON Web Tokens - jwt.io
https://jwt.io/

RFC 7519にもなっているので、私が知らなかっただけで巷では有名なのかもしれん。
AbstractだけDeepLで翻訳しておこう。

JSON Web Token (JWT) は、2 つの当事者間で転送されるクレームを表現するためのコンパクトで URL 安全な手段です。JWTのクレームは、JSON Web Signature（JWS）構造体のペイロードとして、またはJSON Web Encryption（JWE）構造体の平文として使用されるJSONオブジェクトとしてエンコードされ、クレームがデジタル署名されるか、メッセージ認証コード（MAC）で保護されるか、および／または暗号化されることを可能にする。

クレームというと、お店に文句を付けるというネガティブなイメージになるのだが、”claim”という単語としては「主張、要求、権利、資格」のようなもので、苦情っぽい要素はない。
和製英語だったら別に構わないのだけど、日本語で使うときに意味が変わるというのは止めてほしいな・・・。

JSON-RPCのリクエストみたいな使い方をするのだろうか？
使い道は後で調べるとして、まずは文法というかフォーマットを知っておきたい。

RFCは長いのでまだ読みたくない・・・ので、導入のドキュメントを見ておく。
無料のEBOOKもあるようなのだが、メールアドレスだけじゃなくてCompanyとかの入力もあったので、面倒なのでやめた。

JSON Web Token Introduction - jwt.io
https://jwt.io/introduction/

Introductionでは署名するタイプのJWTに焦点を当てるそうだ。まあ、単にJSONをJWTのフォーマットにするだけだとありがたみがあまり無いのだろう。

JWTの使いどころは、AuthorizationとInformation Exchange。承認と情報交換。
他にもあるのだろうけど、まあよかろう。

そしてフォーマット。

<Header>.<Payload>.<Signature>と、3つの部分をドットで区切ってあるそうだ。

Header

Base64Urlでエンコードされる。
エンコードするのはJSONデータで、JSONのところは署名アルゴリズムとトークンのタイプを載せる想定のようだ。他にitemがあってもよいのだろうが、”alg”と”typ”はたぶん必須だ。

”typ”は”JWT”でよいとして、”alg”は何が使えるかというと、RFC-7518の3.1章にJWSの”alg”ヘッダパラメータの一覧があった。
サンプルは“HS256”となっているが、これはHMAC SHA-256のことのようだ。

https://www.rfc-editor.org/rfc/rfc7518.html#section-3.1

そういえばHMACのしくみをよく知らない。
いつも使う署名といえば、署名する人が秘密鍵を持っていて、データをSHA256のようなハッシュ関数でハッシュ値を求め、それに対して署名計算している。データ長を気にせず署名できる計算があるのかどうか知らないが、私が知っているタイプはデータ長が決まっているので事前にハッシュ計算してデータ長を整えるのだ。

HMACの場合は共通鍵のようだ。
じゃあ、JWTというかJWSというか、署名がついてHMACの場合には事前に鍵を決めるというシーケンスがいるのだろうか？
それはそれで面倒だ。

ただ、署名は無視することもできる。
送っている方が「俺だよ、おれおれ」っていう証明を付けてきて、確かに俺さんの秘密鍵を持っていないと作ることが難しいデータを付加しているだけなので、その人が受信した人が思っている俺さんかどうかわからないし、そのデータが正常かどうかなどというのはさらに関係が無い。

“HS256”だけはRequiredなので、これだけはどの環境でも使えないとRFC-7518を名乗ることができないはずだ。

Payload

ここにはclaimが入っている。claimには3タイプある。

Registered claims
Public claims
Private claims

PayloadもBase64Urlでエンコードされている。

Signature

HeaderとPayloadをまとめて署名する。
HMAC-SHA256の例が載っているのがわかりやすかろう。

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret)

かなり省略した。。。すまぬ。
HMACのときにどうやって署名検証するかが気になって、残りがどうでも良くなってきたのだ。

JSON Web Token（JWT）の紹介とYahoo! JAPANにおけるJWTの活用 - Yahoo! JAPAN Tech Blog
https://techblog.yahoo.co.jp/advent-calendar-2017/jwt/

ここを読むと、”kid”というところで公開鍵を参照したりするそうだ。
しかし、HMACって共通鍵だから・・・？

まあ、今回は概要を知りたかっただけなので、これでよしとしよう。
あとは会社で詳しい人に聞くとするかね。

2020年10月18日

[win]回復ドライブが作成できない

まいった。

いつか忘れたのだが、USBメモリに回復ドライブを作っているので、以前は作成できていたのだ。
大きめのWindows Updateが行われたときに作成したと思うので、もう昨年のことか。

ここを見ながらやってみよう。

https://navigator3.com/windows-re-come-back/

reagentc.exeでdisabledだったので、ここのdiskpartのところをやっている。

回復パーティションは存在している。いるのだが、GUIでは1つなのだが、diskpartを見ると回復パーティションが2つ存在している。900MBくらいのと、1300MBくらいのだ。
GUIで回復パーティションになっているのは900MBの方だ。1300MBの方もGUIで見えているのだが、何にも割り当てられていない。
とりあえず、1300MBの方にvolumeを割り当てて、reagentc.exeしてみる。
うん、disabledのままだ。

再起動させると回復ドライブの作成が進むようになった。
いいのか、そんなことで？
reagentc.exeで見てもまだdisabledのままなのに？
というよりも、回復パーティションが複数あるのは変じゃないか？？
もう大混乱である。

検索すると、たくさん出てきた。
私のがどれに当たるのか分からないが、複数はいらんだろう。
そして、diskpartで削除する方法が載っている。なんでGUIから削除しないのかと思ったら、実行できないからだった。

回復パーティションを1つも残さないという選択もあるかもしれんが、リスクは減らしたい。この場合のリスクは、回復ディスクも使えないという場合だ。まあ、ネットでCreationToolみたいなものをダウンロードしてやればよさそうなことは書かれているのだが、時間かかるしね。

あれ・・・もしかして回復パーティションが増えたのはXubuntuをインストールするときに削除できずに残っていて、その後にフルリストアしておかしくなっているとか？
Xubuntuのインストーラでは全消しするように頼んだのだけど、Windowsのことだし特殊なパーティションに見せて(いや、隠して)いたのかもしれない。

ここを読む限りでは、回復パーティションはオリジナルに戻す機能くらいしかなさそうだ。

Windows 10回復パーティションを総合的に理解
https://www.partitionwizard.jp/partitionmagic/windows-10-recovery-partition.html

だが、ちょっと困ったときにコンソールが使えるだろうし(そういうときはもうどうしようもないかもしれんが)、残しておいても良かろう。
でも、回復ディスクの場合は16GB以上のUSBメモリがいるのよね・・・。サイズ的に納得がいかん。

ともかく、今は回復ディスクの作成中だ。
かなり時間がかかるので、寝る前に仕掛ける、くらいでいいのかもしれん。そこまではなくても、1時間以上はかかると考えておいた方が良かろう。

文章が滅裂な感じになっていて申し訳ないのだが、正直なところどれが正しくてどれが間違いなのかよくわからないのだ。
回復ディスクの作成が始まらなかったのは間違いなく、それについて調べていって試したのも間違いないのだが、どれによって作成が開始されるようになったのかが分からない。
disabledがenabledになったのであればdiskpartで行った処理がよかったのだと思えたのだろうが、disabledのままで動くようになってしまった。
そうなると、それより前に行ったことがリセットによって今回反映されたのかも？とか、USBメモリを一度抜いたのが良かったのでは？とか、いろいろ考えてしまうのだ。でも、リセットはそれまでに何度もやってるし、USBメモリを探すのはエラーダイアログが出るよりも後の処理だったから関係ないと思うのだが、とか。

そういうわけで、今の私の気持ちとしては、全部忘れてWindows10をインストールし直したい。
インストールし直すことによってすっきりするのと、インストールし直し自体の時間と精神的な負担を比べると、まだ負担の方に軍配が上がっているという状況だ。
これが逆転するのは、システムの動作自体が不安だと感じたときだろう。ネットワークが数日つながらなかったくらいでは、まだまだだ。

変なアプリが動くことによってネットがつながらなくなったという考えもできるのだが、私がそういうアプリを作る立場であれば変な動作を起こさないように最善を尽くすだろう。泥棒されたことに気付かないというのが最善なのだ。自分のPC管理に自信を持っているわけではないのだが、DropBoxなりGoogleドライブなりに置いている時点でもうダメだし、SlackやZoomなんかで打ち合わせしているのはもっとダメダメだろう。

嫌だけど、今のところ信用するしかない、という状況だ。

[win10]なぜかネットにつながらなくなった話

先週、急にノートPCがネットにつながらなくなった。
最初に書いておくが、技術的な話は何もないし、何かしたから直ったわけでもないし、そもそも今も解決したかどうか分からない。

うちにはデスクトップPCとノートPCがあり、リモートワークで会社から持ち帰ったノートPCもある。
そして、ノートPCたちだけがネットにつながらなくなった。
初日はルータ(うちはauひかりなので、ホームゲートウェイという)にpingがほぼ通らなかった。「ほぼ」で、たまーに通ることがある、という程度。
WiFiのせいかと思ったが、有線にしても同じ。

あれこれ試していると有線ではつながったようだった。
もう夜中だったので、その日は電源を落として寝た。

翌朝はつながった。
よかったよかったと思ったのだが・・・昼に見てみるとまたつながらなくなっていた。
私はほとんどの作業をデスクトップPCで行うので、なかなか気付かないのだ。

さすがにまずいので、Windows10のネットワークをリセット。直らない。
データを残しての初期化。直らない。
データを削除しての初期化。直った・・・？なんか微妙な感じがする。
なんか、pingは通るのだけど、一部のサイトだけしかつながらない。Googleとかauとかdocomoとか。Yahoo!なんかはダメだし、Dropboxなんかもダメだ(そもそもネットにつながらないと気付いたのはDropboxのアプリがグレーになってたから)。
DNSの問題っぽいけど、それならもっとつながらないはずだし。
WiFiのUSBドングルを試したが、変わらず。ノートPCのネットワークはIntelのチップセットで有線も無線もやってるので疑ったのだが、そこではなさそうだ。

VirtualBoxでXubuntuを立ち上げると、なんとそこからはブラウザで普通にアクセスできる。
ということは、問題は外部ではなくOS側にあるはずだ。
念のためUSB起動でXubuntuを立ち上げる。問題なし。
さらに念のためXubuntuをインストールして立ち上げ。問題なし。
じゃあ、なんでWindows10を初期化してもダメなんだ？？

そんなことをしている間に、もう1台のノートPCの方はつながっていた。
昨日ダメだったのに。今日は何もしてないのに。さっきダメだったのに。
有線でも無線でも大丈夫なのだ。
訳がわからんね。

いじくっていた方のノートPCも全リストアして元に戻した。ネットもつながった。
疲れた・・・。

メモを残しておく。

全バックアップは大切。各アプリの再インストールとかしたくなければ、だが。データはほとんどクラウドにあるのだけど、アプリのインストールは憂鬱だ。chocolateyの設定をバックアップしておけばもう少し楽なんだろうか？
Windows10の回復ディスクは大切。全リストアした後、Windowsが立ち上がらなくてね・・・。たぶんXubuntuをインストールしてMBRみたいなものが書き換わったせいだと思う。回復ディスクからコマンドプロンプトを立ち上げてなんかネットを見ながらコマンドを打つと直った。これが今回の騒動で一番面倒くさいところだった。
全リストアの準備も大切。バックアップはするけど、リストアはなかなかしないからねー。Paragon 17のFree版を使っていたのだけど、リカバリー用の起動ディスクを作ってなくてね。ディスクを作るために初期化したWindowsにFree版をインストールして、ADKとかあれこれインストールしたのだけど、どうも作成に失敗した。ネットを参考にしてParagon 16を使うと作成できた。今回の騒動で2番目に面倒だったのがこれだった。
BitLockerを使っている場合は、回復キーを残しておくのを忘れぬよう。どこでか忘れたけど、今回の作業で使うことになったのだ。

データはなんとかなることが多いのだけど、元の環境に戻すコストが高いので、そこをどうするかという課題が残るのだ。
まあ、新規でインストールするのが一番だし、そうすると環境もすっきりするのだけど、なかなかねぇ。。。
全部ストアアプリになればまた違うのだろうけど、そんなことにはならないし。

そして、最初に書いたとおり、何かして直ったというわけではない。
あのまま放置していても直っていたんじゃないかと思う。
また起きそうな気がするので、心配だ。

2020年8月26日

Windows10とVT-x有効化

前回の続き。

VT-xが有効に戻ったので、もう一度やってみよう。
T460sでどうやるとVT-xが無効になるか、だ。

「Linux用Windowsサブシステム」「仮想マシンプラットフォーム」をONにして再起動。

VT-x関係が無効になった。
念のため電源OFFして3分おいてみたが、同じ結果になった。

この状態で、以前動いていたゲストOSを起動するとこうなる。
まあ、確かにVT-xは有効になってないね。

なんか情報ないかと検索すると、いいのがあった。

WSL2とHyper-Vの関係 - Qiita
https://qiita.com/matarillo/items/ca1eecf8f9a3cd76f9ce#%E3%81%A7%E3%81%AA%E3%82%93%E3%81%A7wsl2%E3%81%AFvm%E3%81%98%E3%82%83%E3%81%AA%E3%81%8F%E3%81%A6%E3%82%B3%E3%83%B3%E3%83%86%E3%83%8A%E3%83%BC%E3%81%AA%E3%81%AE

どうやら「Windowsハイパーバイザープラットフォーム」も有効にするらしい。

有効にしてみたが、それだけではWindows再起動は不要だった。
だが、Intelのツールで見てもVT-xは無効なままだった。
再起動、いや電源OFFだ。