徒然なるままに

 Windows10 → 11へ そろそろ、windows11も詳細にテストしておきたいのだけれど、普通にアップグレードすると、ハードウェア要件に満たないケースが多々ある。 今回は、無理矢理10→11する簡単な方法を紹介して使えるようにしてみようと思う。 個人的な環境 メインマシンはLinuxを使っていて、仮想マシン（VirtualBox）内でWindows10をたまに使用している。 　でもって、仮想マシン上での更新は要件Checkで弾かれてしまうため、アップできない状況。 実機で作業する人は、インストールのところまで飛ばしてくれればOK なお、ストレージを一時的に使用するので、12GB程度は空きがないと、準備ができないので注意。（ISOイメージが5GB、そのコピーに5GBが必須） 仮想マシンのクローン うまく行かなかった場合に、元の10に戻すのは怠いので、先にクローン（コピー）を作成しておいて、作業を行うことにする。 　万一だめだったら、環境ごと破棄して終わることにする。 問題が起きると嫌なので、ディスク名とハードウェアUUIDを保持しておく。 使用しているディスクサイズが大きいと、若干クローンに時間がかかるけど、我慢。 クローンが完了したら、クローンしたマシンを起動する。 インストール まずは、Windows11のインストールイメージをダウンロード。 ここでは、ISOディスクイメージをダウンロードする。 multi-edition ISO 日本語 64bit　ダウンロード を選択すればOKなはず。およそ5GBあるので、回線が細いと時間かかるかもしれない。 ダウンロードしたISOイメージを開く（マウントする） マウントすると、DVDのイメージとして見えるので、作業用に全部をコピーする。 今回は、Desktop上に「新しいフォルダー」を作成し、まるっとコピーする。 重要 sourcesフォルダがあるので、その中から「appraiserres.dll」を探して削除する。 こいつが、インストールのハードウェアをチェックするプログラム。 こいつを削除することで、Checkを回避する。 では、「新しいフォルダー」のsetup.exeを実行する。 ここで、慌てて「次へ」を押さない！ まずは、「セットアップで更新プログラムのダウンロード方法の変更」を選択する。 でもって、「今は

アップデートで超改善 前回構築したM1 Mac上の仮想マシン でキー入力などがうまくいかず、苦労していたところが、あっけなく解消してしまった。 homebrewを使用しているので、各種updateを行っている時に、utmのバージョンが上がっているのに気づいた。 でもって、2.2.4にversionを上げたところ、機能アップと不具合の改善が行われていた。 まずは、前回苦戦したキーボードの入力を認識しない件に関して、大きな変化があった。 ほぼ全てのキーを正しく認識することが分かった。 ほぼ、というのは、「英数」と「かな」のみ全く認識していない。ただそれ以外は、一応OKっぽい。 問題は、mozcでの日本語入力の切り替えだ。 デフォルトでは「⌘+スペース」を押すことで、入力ソースの切り替えに設定されているのだが、MacOS側の入力が先に反応してしまい、仮想マシンに入力が渡らない。 　Mac上での⌘+スペースはspotlightがデフォルトになっているので、画面上にspotlightの検索画面が表示されてしまう。 そこで、基本使用してしないspotlightをオフにしてみると、難なく仮想マシンに入力が渡ることが判明した。 これで、無事に入力の切り替えが可能になった。 本当は、「英数」「かな」でOFF/ONを切り替えたかったけれど、まったくキーを認識していないので、仕方なくこの方法で運用することにした。 ネットワークも楽に 前回のバージョンでは、ホストと仮想マシン間でNATでしか接続できない状況だったのが、あらたにbridge接続ができるようになった。 これで、外部の他のマシンからのアクセスが容易に利用できるようになった。 設定は以下の箇所を変更するだけ。 設定を保存し、仮想マシンを起動すると、ホストマシンと同じセグメントでIPを取得できている。 これで、Apacheを起動すれば、外部のマシンからWebサーバとしてアクセスできる。 ポートフォワードなどの設定をする必要もなく、簡単にサーバ環境をテストできるわけだ…。 ということで、utmを利用する価値は格段に上がった感じです。 ちなみに、iOS版も出ているので、その上でも仮想マシンが構築できるような感じ？なのかな。試していないのでなんとも言えないけれど…。

 M1 Mac速いけどまだ足りない… M1 Chip搭載のMacbookProを入手して、いろいろとテストしている。 確かに速い！メモリ8GBで苦しいんじゃ？と思ったけど全然そんなことないし、Intelの16GB相当と言えるような感じ。 バッテリーの持ちも本当に良いし、ZoomやSkypeを使うときはメインマシンとなっている。 さて、今回はこれまでx86対応が遅れている箇所を検証してみた。 目的はM1 Mac上に仮想環境を構築し、その中でLinuxを動作させること。 VirtualBoxが動作しないので、他に方法はないのかと探してみると、OpenSource Base（QEMUを使用したもの）で、UTMというのが存在することがわかった。 しばらく、OSXから離れていたので、情報不足でした。 そこで、こいつを使用して構築を試みる。 intel系のコードの場合、rosset2が変換して動かすものの、初期変換に時間がかかることと、ドライバ等は正常動作しないことが多い。 仮想マシンは、M1のnativeで動作させたいので、以下の方針で進める。 仮想マシンはArm64 CPUとする OSは、Arm64に対応したもの できれば、使い慣れているUbuntuもしくは他のLinux 色々と探してみると、すでに同じ構成でのレポートがあった。 参考にしたのは、「 第672回　UTMを使ってM1 Mac上でUbuntuを動かす 」だ。 UTMのインストール これは、どのインストール方法を選択するかで、変わってくる。自分のマシンはHomebrewを導入済みなので、当然brewでインストールする。 (https://github.com/utmapp/UTM/releases/tag/v2.1.2) $ brew update $ arch -arm64 brew upgrade $ arch -arm64 brew install --cask utm 何の問題もなく進む。 brewを使用していない人は、dmgを落とすか、AppleStoreで有料購入できるらしい。 仮想マシンの構築 さて、UTMを起動して、仮想マシンを作成する。 メモリは8GBしかないので、とりあえず3GB割り当てることにした。 Ubuntu程度なら、2GBでも充分動くけど、快適に動かせるように少し余分に…。 Ubuntu

やっと動くようになった 土曜の夜に、仕事でskypeを2時間ほど行って、ミーティング終わってからの調子がすこぶる悪くなった。 でもって、 リカバリーモードで、ディスクのチェックを掛けた のが、昨日。 しかも、昨日のブログは、携帯で書いているので、今見ると読みにくいわ…。 昨日、仕事から戻ると、バックアップディスクのチェックは完了していて、問題なし。 OK。 これで安心して、本体のHDDが触れる。 続いて本体のHDDをチェックする。 しばらく待つと、エラーが出ます。修復かけます。直りません。 これを、数回繰り返したが、結局、起動することは出来ず。 ディスク自体が逝っているのか、理論的に逝っているのか現時点では分からない。 S.M.A.R.T.情報でもすぐに見られれば、良いのだが…。 最悪、HDDの交換かマシンの買い替えも視野に入れつつ、作業をすすめる。 まずは、フォーマットをかけてみる。 この時点で、ダメならHDDを諦める。→問題なし。 念のため、クイックなフォーマットではなく、実際に0埋めをさせてみる。 これは多少時間がかかるだろうと思いつつ、実行→問題なし。 ならばと、TimeMachineのバックデータを元に書き戻しを実行。 ぐはぁっ、14時間かよ…。 ということで、放置しつつ他のWindowsマシンで仕事して寝た。 修復完了 朝起きたら、まだ4時間かかると出ていたので、もう少し放置。 で、9時半頃に完了。本当に10時間以上掛かっているゎ。 やっと、ログイン画面を拝むことが出来た。 動作確認を兼ねて、ブログ書き中。 今のところ、正常に動作している感じ。 ただ、key_chainなどが消えているっぽくて、やたらとパスワードを入力させられる。 バックアップ対象に入れていないDownloadフォルダは、すっかり空だけどまあいいや。 と思って確認していたら…。 仮想マシンのイメージが消えていた orz あまりに容量がでかいので、対象から外していた。 少しやばい。 Windows用の開発ソースが、残っていないかも。 殆どはOneDriveに移行していたんだけど、その前のものが残っているかな。 別のWindo