m4のmacになって初のOSバージョンアップ。
物理ホスト、仮想ホストの順に更新してく。仮想ホストは去年からUTM使い始めた。
仮想ホストから先に更新しようとしたら、ipswがうまく読みこめんかったな。
m4mac用の26.0と26.0.1
を使ってみてアカンかった。
「tahoe 不具合」とかでググると、そもそもインストールが〜とか、Time Machineが〜とか、バッテリーが〜とか言うてる人がおられる。
2004年頃にpower pcからintelになったときもこういうハードウェア寄りの問題多かった気がするし、今回はintelからarmで同じかそれ以上障害あるはず。
自分の環境にあてはまるリスク考えたら大丈夫そうって判断。M4のmacminiやしwifi/bluetoothとか使ってへんし、特殊なハードウェアないし、あんまり神経質にならずやってった。
ときどき障害見つけることあるかもやけど、なんとなく使ってくか。
構成はこんな感じ。⭐️の箇所を上から順番にやってく。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
|
+-M4 macmini sequoia -> tahoe -----------------------------+ ⭐母艦tahoeのバージョン上げる(クリーンインストールはやらずバージョンアップ)
| +-utm -------------------------------------------------+ | ⭐utmのバージョンアップ
| | +-sequoia arm64 ------+ +-tahoe arm64 --------+ | | ⭐仮想sequoiaから仮想tahoeへ引っ越して、rdp/ssh接続ができるか確認
| | | vscode/cyberduck | -> | vscode/cyberduck | | | (ここはクリーンインストールに近い)
| | | office/brew/rdp | | office/brew/rdp | | |
| | +---------------------+ +---------------------+ | |
| | +-kubearm(ubu24) -----+ | | ⭐microk8sでkubernetes環境でPOD稼働できることを確認
| | | ctr microk8s | | |
| | |+-container-+ | | |
| | ||kubernetes | | | |
| | |+-----------+ | | |
| | |+-container-+ +/data+| | |
| | ||Django | | d1 || | |
| | |+-----------+ +-----+| | |
| | |+-container-+ | || | |
| | ||mariadb | | d2 || | |
| | |+-----------+ +-----+| | |
| | |+-container-+ | || | |
| | ||xrdp-ubu24 | | d3 || | |
| | |+-----------+ +-----+| | |
| | |+-container-+ +-----+| | |
| | ||https | | d4 || | |
| | |+-----------+ +-----+| | |
| | +---------------------+ | |
| +------------------------------------------------------+ |
| ^ ^ |
| | | +---------------+ | ⭐すぐはやらんけどdockerイメージをkubernetes環境へ流し込みできる確認
| | | |Django & xrdp | |
| | | |docker image to| |
| | | |ctr registry | |
| | | +---------------+ |
| | | |
| +-rancher desktop----------+ | ⭐rancherでdockerコンテナ開発環境維持
| | docker on lima | |
| | +-container-+ +------+ | |
| | | Django | | d1 | | |
| | +-----------+ +------+ | |
| | +-container-+ | | | |
| | | mariadb | | d2 | | | ⭐️mariadbのデータ原本はgoogle cloudにあってダンプからリストア
| | +-----------+ +------+ | |
| | +-container-+ | | | |
| | | xrdp-ubu24| | d3 | | |
| | +-----------+ +------+ | |
| | +-container-+ +------+ | |
| | | https | | d4 | | |
| | +-----------+ +------+ | |
| +--------------------------+ |
| |
| +-music----------+ | ⭐️iphoneで音楽聴くための維持
| | 8410(37GB) | |
| +----------------+ |
+----------------------------------------------------------+
|
母艦(macminiM4)のホストで以下確認。
- 母艦をsequoiaからtahoeへとバージョンアップの確認とUTM環境の起動確認
- ubu24arm - ubuntu24で展開したmicrok8sでのkuberntes環境稼働確認
- gvis-tahoe - apple virtualizationで動く仮想tahoeを動かしてhugo稼働確認
母艦(macminiM4)のホストでさらに以下確認。
- rancher desktop環境の中にあるコンテナ稼働確認
- dockerイメージの登録内容確認と、コンテナの稼働確認
UTM環境の中で、apple virtualizationで動く仮想tahoeの仮想ホストから以下確認。
- 仮想tahoe稼働の確認
- office365のモジュール更新
- kubernetes環境とdocker環境のpodとコンテナに接続
- windowsホスト(shanshan-64)にrdp接続してmac miniの中のmusicのホームシェアリングへ接続して音楽再生
その後、耐久テストとして土日の早朝から夜まで母艦tahoe・仮想tahoe動かして、不具合出ないことを確認した。
- kindle読みながらwebで調べごと
- JRAの３場開催全３６レース観覧と馬券購入
- google cloudからkubernetes/docker環境へのデータ流し込み
- 手持ちのiphoneのiosをアップグレードしてもmusicの同期ちゃんとできて、母艦でバックアップ取れる
「いつ切り替えるたらいいか」って相談してる人がネットの中にいるんやけど、「どう切り替えたら問題が出そうか、出た時どうするか」をある程度検討できたら、即切り替えしたらええと思う。
来年もまたよろピコ。以下、実施のメモ。
準備作業#
前はmacosのインストール用isoとか、onyxの最新版とか用意してた。
UTMからipsw使うし、移行アシスタントも使うし、今年からほぼ用意せずにやってみた。
論理的な準備#
ハードウェアの互換性確認は
Tahoeに対応しているコンピュータ
で見れる。
去年みたいにハードウェア購入したり、ケーブルつないだりはせんから物理的な準備なくて、利用アプリケーションがtahoeで動きそうか調べるだけ。
ほとんどbrewでインストールしてるし、office365は粘り強いから動きそうやし。
UTMはbrewでインストールしてへん。
brewでインストールしたら、仮想マシンの稼働が崩れてしもたとき困るし、あんまりホイホイとバージョン上げたくない。
OSのバージョン上げる時だけバージョン上げるから手動でやる。
仮想化のための用意#
UTMのバージョン履歴読む。
Releases · utmapp/UTM · GitHub
2025年10月は4.7.4ってある。使えそう。そのままUTMの公開サイトで「DOWNLOAD」ってリンクあるからダウンロードしてモジュール置き換える。
UTM | Virtual machines for Mac
onyxの確認#
これもダウンロードしとく。バージョン上げ終わってから、onyxをいったん削除してdmgをマウントしてインストールする。
Titanium Software | Operating System Utilities for Mac - OnyX
www.titanium-software.fr
アプリケーション#
仮想sequoiaから仮想tahoeへデータ移行するときにコピーしてくれる。
ただし、
Karabiner-Elements
だけはうまく設定が反映されんかったから、それだけ入れ直した。
IPアドレスの引き継ぎ#
宅内LANのIPアドレスとか、dnsとかはそのまま引き継ぐ。
引っ越し元の仮想sequoiaに割り当てた静的IPアドレスは、移行アシスタントによる移行が終わったら、dhcp利用に切り替える。
代わりに引っ越し先の仮想tahoeのdhcp利用は、静的IP利用に切り替える。
切り替えたら、windows側からteraterm経由でつながるし、mac側から.terminalのファイルとシェルスクリプトでつながる。
macminiM4のバージョンアップ#
先に物理ホストをバージョンアップしてく。次が仮想マシン。バージョンアップ手順は前からあんまり変わらんし、方法を紹介してるサイトはいっぱいあるから割愛。
UTMだけ手動でインストールしてるけど、他はbrewでインストールしてるから、OSバージョンアップ終わってからbrewでのモジュール更新したらええ。
小さなスクリプト
に仕込んであるんやけど、こういう内容で更新。
1
2
3
4
5
|
brew doctor
brew update
brew upgrade --cask --greedy
brew upgrade
brew cleanup
|
brewで一部やりなおし - xcode関連#
バージョンアップした直後にこんな内容が出る。
1
2
3
4
5
6
7
8
9
10
11
12
|
Warning: Your Command Line Tools (CLT) does not support macOS 26. ⭐️tahoe用のコマンドラインツール古いってよ
It is either outdated or was modified.
Please update your Command Line Tools (CLT) or delete it if no updates are available.
Update them from Software Update in System Settings.
If that doesn't show you any updates, run:
sudo rm -rf /Library/Developer/CommandLineTools ⭐️フォルダ潰せってよ
sudo xcode-select --install ⭐️実行せえってよ
Alternatively, manually download them from:
https://developer.apple.com/download/all/.
You should download the Command Line Tools for Xcode 26.0.
|
インストールしてみましょ。
1
2
3
4
5
|
nari@narimac-mini ~ % sudo rm -rf /Library/Developer/CommandLineTools
Password:
nari@narimac-mini ~ % sudo xcode-select --install ⭐️こっからGUI操作いるで
xcode-select: note: install requested for command line developer tools
nari@narimac-mini ~ %
|
GUI操作必要な箇所。インストール進めて完了待つだけ。
brewで一部やりなおし - pkgconf#
こういう警告も出てpkgconfを再インストールせなアカンらしい。
前からこんなんあったかなぁ。見落としてただけかも。
1
2
3
4
5
6
|
Warning: You have pkgconf installed that was built on macOS 15,
but you are running macOS 26.
This can cause issues with packages that depend on system libraries, such as libffi.
To fix this issue, reinstall pkgconf:
brew reinstall pkgconf ⭐️これやれってか
|
やってみたらこうなる。Already downloded？ もうやってたんかも？ まぁええか。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
nari@narimac-mini ~ % brew reinstall pkgconf
==> Fetching downloads for: pkgconf
==> Downloading https://ghcr.io/v2/homebrew/core/pkgconf/manifests/2.5.1
Already downloaded: /Users/nari/Library/Caches/Homebrew/downloads/e0bf05fafcedcfbde9a9a488dc3a083cadd19584ac19f4cc053a9c265f841120--pkgconf-2.5.1.bottle_manifest.json
==> Fetching pkgconf
==> Downloading https://ghcr.io/v2/homebrew/core/pkgconf/blobs/sha256:84f26aae5e27d846e00a9fb741dfe3b02a14cb2f
Already downloaded: /Users/nari/Library/Caches/Homebrew/downloads/f3c5bc65b0fc4da2addc0ca49b98a415b5c6961e374421bed7a6b09bdccd5acd--pkgconf--2.5.1.arm64_tahoe.bottle.tar.gz
==> Reinstalling pkgconf
==> Pouring pkgconf--2.5.1.arm64_tahoe.bottle.tar.gz
ðº /opt/homebrew/Cellar/pkgconf/2.5.1: 28 files, 519.8KB
==> Running `brew cleanup pkgconf`...
Disable this behaviour by setting `HOMEBREW_NO_INSTALL_CLEANUP=1`.
Hide these hints with `HOMEBREW_NO_ENV_HINTS=1` (see `man brew`).
nari@narimac-mini ~ %
|
brewのモジュール一覧#
母艦tahoeのbrewリスト。こっちではvscodeあんまり使わんから外した。
1
2
3
4
5
6
7
8
9
10
11
12
|
nari@narimac-mini ~ % brew list
==> Formulae
abseil glances llvm nmap python@3.13 xz
ca-certificates libgit2 lua openssl@3 readline z3
certifi libidn2 lz4 pcre2 rust zstd
cmake liblinear mactop pkgconf sqlite
gdbm libssh2 mpdecimal protobuf tree
gettext libunistring nginx python@3.10 wget
==> Casks
rancher
nari@narimac-mini ~ %
|
仮想tahoeのbrewリスト。
1
2
3
4
5
6
7
8
9
10
11
|
nari@gvis-mac ~ % brew list
==> Formulae
ca-certificates glances libssh2 mpdecimal readline zstd
certifi hugo libtiff nmap sqlite
gettext jpeg-turbo libunistring openssl@3 tree
giflib liblinear lua pcre2 webp
git libpng lz4 python@3.13 xz
==> Casks
beyond-compare diffmerge visual-studio-code
nari@gvis-mac ~ %
|
実験で何かインストールして元に戻す時は、上２つのリストの状態になるようにbrewでremoveしたらええ。
macminiM4の確認#
順番に確認してく。
tahoeへバージョンアップの確認とUTM環境の起動確認#
バージョン上げたらシステム情報がこうなる。
ターミナルにフルアクセスつけとかんと、フォルダ見えへん箇所出てくるから、フルディスクアクセスの許可設定つけとく。
appleがintelからarmにcpu変えたんはこういうことしたかったんかなぁ。
手持ちのiphoneのアプリが見えるようになった。気持ち悪いなぁ・・・。
アイコンの右下にマークがついてるのがiphoneのアプリってことか。便利な使い方あるんやろけど、今は放置。
ターミナル画面での確認#
カーネルバージョン確認と、sudoしてcrontabの確認。
今までもやってたけどメモってへんかったから書いとく。
カーネルバージョンの確認して、rootユーザが使えて、決まった時間にOS停止のcrontab設定が引き継がれてるかどうか。
1
2
3
4
5
6
7
8
9
10
|
nari@narimac-mini ~ % uname -a
Darwin narimac-mini.intra.gavann-it.com 25.0.0 Darwin Kernel Version 25.0.0: Wed Sep 17 21:42:08 PDT 2025; root:xnu-12377.1.9~141/RELEASE_ARM64_T8132 arm64
nari@narimac-mini ~ % sudo su -
Password:
narimac-mini:~ root# crontab -l
55 11 * * 1-5 /sbin/shutdown -h now ⭐️月〜金11:55にOS停止してちょ
55 23 * * 1-5 /sbin/shutdown -h now ⭐️月〜金23:55にOS停止してちょ
## 23 9 * * * /sbin/shutdown -h now
*/10 * * * * sync ; sync
narimac-mini:~ root#
|
はいOK。ついでに、仮想tahoeのほうは母艦のOS停止より５分前に設定してる。移行アシスタントが設定移してくれたんやろな。
1
2
3
4
5
6
7
8
9
10
|
nari@gvis-mac ~ % uname -a
Darwin gvis-mac.intra.gavann-it.com 25.0.0 Darwin Kernel Version 25.0.0: Wed Sep 17 21:41:26 PDT 2025; root:xnu-12377.1.9~141/RELEASE_ARM64_VMAPPLE arm64
nari@gvis-mac ~ % sudo su -
Password:
gvis-mac:~ root# crontab -l
50 11 * * 1-5 /sbin/shutdown -h now
50 23 * * 1-5 /sbin/shutdown -h now
### 08 0 * * * /sbin/shutdown -h now
*/10 * * * * sync ; sync
gvis-mac:~ root#
|
１１時に設定してるのは、慌てて出勤してOS停止忘れたときのため。
２３時に設定してるのは、寝落ちしてOS停止忘れた時のため。
ローカルのubuntuとgoogle cloudのubutuにも同じ設定入れてる。特にgoogle cloudは費用に直結するから停止してくれんと困る。
ただし、土日はメンテナンスしてるときあるから平日のみで1-5って入れてる。
nginxの稼働確認#
このへん
でやったnginxの設定が生きてるか確認。
1
2
3
4
5
|
nari@narimac-mini ~ % ps -efww | grep nginx
501 477 1 0 3:48午後 ?? 0:00.02 nginx: master process /opt/homebrew/opt/nginx/bin/nginx -g daemon off;
501 598 477 0 3:48午後 ?? 0:00.11 nginx: worker process
501 15836 15801 0 5:38午後 ttys000 0:00.01 grep nginx
nari@narimac-mini ~ %
|
ブラウザで見てもちゃんと稼働できとった。
ubuntu24で展開したmicrok8sでのkuberntes環境稼働確認 - ubu24arm#
UTMバージョンアップしてもデータフォルダを読み取って、使ってたOSの一覧即時で表示してくれる。
qemuで動くarmのubuntu24を起動して、kubernetes環境使えるか確認してみる。
pod/service/configmapできてたし、ポートフォワードもできる。
ポート3389が33389として接続できるから、xrdpのポッドに接続してその中でブラウザ開いたら、https/djangoのポッドにつながるし、mariadbのポッドにもdjangoからつながってデータ一覧見せてくれてた。
クラスタの状態確認
してみたら、ちゃんと維持できとる。onlchkって状態確認スクリプト作っといてよかった。kubectlナントカっていっぱい入力せずに済む。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
|
root@kubearm:~# onlchk
----- cluster status ------
microk8s is running
high-availability: no
datastore master nodes: 127.0.0.1:19001
datastore standby nodes: none
addons:
------ cluster node ------
PRETTY_NAME="Ubuntu 24.04.3 LTS"
Filesystem Size Used Avail Use% Mounted on
efivarfs 256K 37K 220K 15% /sys/firmware/efi/efivars
/dev/mapper/ubuntu--vg-ubuntu--lv 60G 41G 17G 72% / ⭐️それなりに消費
/dev/vda2 2.0G 67M 1.8G 4% /boot
/dev/vda1 1.1G 6.4M 1.1G 1% /boot/efi
share 461G 406G 56G 89% /microk8s
----- recent cluster ver -----
latest/stable: v1.34.1 2025-10-14 (8496) 160MB classic
installed: v1.34.1 (8472) 160MB classic ⭐️今の最新使えとるな
1.34/stable: v1.34.1 2025-10-13 (8497) 160MB classic
1.33/stable: v1.33.5 2025-10-13 (8509) 155MB classic
------- images in ctr ------- ⭐️自前のイメージ維持できとる
docker.io/library/save-django:gvis-saved 1.4 GiB
docker.io/library/save-xrdpubu:gvis-saved 6.7 GiB
-------kubectl version -------
clientVersion:
gitVersion: v1.34.1
serverVersion:
gitVersion: v1.34.1
----kubectl po/svc/configmap status ---- ⭐️ポッド・サービス・コンフィグマップ生きとる
NAME READY STATUS RESTARTS AGE
pod/cl-ubun 1/1 Running 3 (4m48s ago) 3d1h
pod/sv-django 1/1 Running 3 (4m48s ago) 3d1h
pod/sv-https-portal 1/1 Running 7 (3m21s ago) 3d1h
pod/sv-mariadb 1/1 Running 3 (4m48s ago) 3d1h
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/kubernetes ClusterIP 10.152.183.1 <none> 443/TCP 158d
service/sv-django ClusterIP 10.152.183.244 <none> 38080/TCP 158d
service/sv-https-portal ClusterIP 10.152.183.229 <none> 30080/TCP,30443/TCP 158d
service/sv-mariadb ClusterIP 10.152.183.179 <none> 13306/TCP 158d
NAME DATA AGE
configmap/kube-root-ca.crt 1 158d
configmap/sv-mariadb-txt 5 158d
-------kubectl PV ------- ⭐️永続化領域使えとる
NAME CAPACITY ACCESS RECLAIM
gvis-pv-django-sslcerts 1Gi RWO Bound
gvis-pv-django-uwsgi-nginx 1Gi RWO Bound
gvis-pv-mariadb 20Gi RWO Bound
gvis-pv-mariadbconf 5Gi RWO Bound
gvis-pv-ubun 10Gi RWO Bound
pvc-0682501b-65b6-4ee2-9a59-6c32f3ef51fa 30Gi RWX Bound
-------kubectl forward -------
root@kubearm:~#
|
apple virtualizationで動く仮想tahoeを動かしてhugo稼働確認 - gvis-tahoe#
仮想tahoeの引っ越し詳細はまた後で。
ここではkubernetes環境動かしながら、仮想tahoe使えるかやってみる。主に使うのはoffice365とhugoのpapermod。
hugo起動して、仮想tahoeからkubernetes稼働するubuntu24へ接続してポッドとサービスの状態確認。
hugoのバージョン1.51になっとったの忘れてたな。ubuntu24-armにつないでkubectlも使えとる。省くけど、もちろんクラスタのバージョンは今の最新の1.34.1を維持。
officeはライセンス認証やりなおすだけで即使える。やらんとexcelがreadonlyになって編集ができん。
kubernetes環境と仮想tahoeを同時に稼働させた時のmacminiM4側のメモリ利用率はこんな感じ。
それぞれメモリ8GB使わせる設定にしてるから、近い値。
QEMUで動いてるkubernetesはええけど、apple virtualizationで動いてる仮想tahoeは、プロセス名が前から文字化けしてしてるんは改善されてへん。
ちょっと気持ち悪いけど放置。
メモリは24GBしか積んでへんから、仮想tahoe/docker/kubernetes/ゲームのうち２つまで同時に動かせるのは前と同じ。
３つ同時に動かすと落ちるけど、２つずつしか普段は使わん。
ここまででUTMの中で動くホストいったん停止。
rancher desktop環境の中にあるコンテナ稼働確認#
前に作って維持してる
rancherでのdocker開発環境
が動く確認する。
母艦tahoeでrancher desktop起動してコンテナ動かす。
コマンドラインで見ても公開ポートが有効になっとるな。
dockerイメージの登録内容確認と、コンテナの稼働確認#
dockerイメージはrancherの中の仮想マシン(lima環境)で生きてる。ええ感じ、ええ感じ。
1
2
3
4
5
6
7
8
9
10
11
12
|
nari@narimac-mini docker % docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
save-django gvis-saved 1aafddd3d6cc 2 weeks ago 1.47GB ⭐️kubernetesに持ってくイメージあるな
save-xrdpubu gvis-saved 81b4e582d18e 2 weeks ago 7.06GB ⭐️kubernetesに持ってくイメージあるな
save-mariadb gvis-saved 7af2647bdac4 2 weeks ago 435MB ⭐️kubernetesに持ってくイメージあるな
sv_django 5 51af8fe7dcbb 4 months ago 1.15GB
gvis-ubu24 24gvis da58b5daf02c 4 months ago 5.12GB
ubu 24gvis 9ddc18596606 4 months ago 4.57GB
docker-sv_mariadb1104 latest 5b25829d1449 11 months ago 434MB
steveltn/https-portal 1 eb2a9175db4e 12 months ago 313MB
ghcr.io/rancher-sandbox/rancher-desktop/rdx-proxy latest 7bc83a2be6e6 55 years ago 5.7MB
nari@narimac-mini docker %
|
dockerコンテナにrdp接続して、そこからブラウザ経由でhttps公開したdjangoのコンテナが見えとる。ここも省くけどデータベースの内容もブラウザの中でちゃんと見えとる。
ゲームとps4コントローラ#
まずは
ps1のゲーム
やってみる。なんちゃってのps4コントローラは普通にOSが認識してくれてたから、いきなり起動してみる。
バージョンアップ通知があったから、まずは更新。
動いてくれるやろか。仮想tahoeが動いてるのを画面最小化してゼビウスやってみる。
１つ目のアンドアジェネシス見れるところまで行って、そこから３ステージぐらい進んだところぐらいでゲームオーバ。時間にして１５〜２０分ほど遊ぶ。
ゲームのステータスやハイスコアをメモリカードから読めてたし、３０分ほど動かしてみて安定してる感じ。
次は
ps2のゲーム
やってみる。
アフターバーナー
遊べるやん。
たまに遊ぶんやけど、このゲームようできてる。30年前にゲーセンでよーやったな。
仮想tahoe環境の作成と引っ越し#
環境壊して実験的なことをやりたいときに使う環境でもある。普段はここでdjangoとこの本文をvscodeで書くのに使うのがほとんど。
前にもやった
けど、UTMまだ慣れてへんからメモ作っとく。
UTMで仮想ホスト作成#
qemu使うんやのうてapple virtualizationの「仮想化」選ぶ。
OSはmacos26使うから「macOS12以降」選ぶ。
ipswダウンロードしとく手もあるけど、親ホスト先にアップグレードしたから何も入れんでええ。
「続ける」って次の画面に行ってから、いったん戻ると、ipswが入ってるのが見える。勝手にダウンロードしてくれるで。
仮想ホストの名前を設定する。あれ？ ハードディスクとメモリのサイズ指定やったときのハードコピー作るの忘れてる・・・。
仮想sequoiaと同じで、CPUは４コア、ディスクは150GB、メモリは小さく4GBにしといて移行終わったら8GBにする。
キーボードとマウスは汎用のを選んどく。sequoiaのときと同じ。
仮想tahoeのインストール準備が始まる。ipswのダウンロードしてるんかもな。
別窓開いて仮想ホストがインストールされてく。保管フォルダ見たら「gvis-tahoe.utm」ってフォルダができてて、サイズがだんだん肥えてく。
３０分も待たずに起動画面出てくる。
長いから省略するけど、ログインするOSユーザ作って、icloudとかの設定全部スキップしてデスクトップ画面表示に辿り着く。
デスクトップにベタっとカレンダーとか天気を固定表示しよるの目障りやな。移行アシスタントでユーザごとの設定流れ込むから、そういうのも消えてくれるはず。
OS起動まで行ったときのUTMが使ってる仮想マシンのイメージ置き場は30GB少し下回るサイズやった。けっこう使ってる。
tahoeに魂入れる#
データ転送行ってみよか。
IPアドレスの更新とメモリ利用設定の変更#
ipアドレスが自動割り当てできてて、インターネット見えてることを確認。
ここで移行元の仮想sequoiaを起動して、移行アシスタントを起動しとく。
さっき起動した移行先の仮想tahoeでも移行アシスタント起動。
すると、移行元の仮想sequoiaが見える。
左側が移行元の仮想sequoia、右が移行先の仮想tahoeで、転送するデータを仮想tahoe側で選択して移してく。右側で５つ全部にチェック入れとく。
OSユーザ作ったから「競合あるで」って言われてるけど、「置き換えろや」ってしとく。これでホームフォルダにある隠しファイルが引っ越し対象になってくれて、ログインユーザのアイコンとかzsh/vi/vscode/sshのknown_hostが移る。
こっから３０分ほど放置。朝メシ食いながら待つ。
仮想sequoiaも仮想tahoeもうまくデータ移送できたって表示されてるのを確認。
ここで仮想ホストどっちもOS停止して、メモリの利用サイズをひっくり返す。
仮想tahoeをメモリ8GBにし、仮想sequoiaを4GBに下げといて、困ったときだけ仮想sequoia起動する。
仮想sequoiaはIPアドレスをdhcp利用に変えといて、１ヶ月ぐらいしたらUTMから削除予定。
移行終わって、UTMのディスク利用は66GBぐらいになった。
apple virtualizationで動く仮想tahoeホストの動作確認#
tahoe稼働の確認#
システム設定からレポート表示させると、メモリ8GBとコア数6が割り当てできとる。
IPアドレス・DNS・ゲートウェイを手動設定したら、ルータとインターネットに疎通できることを確認。ソフトウェアアップデートも最新を維持できとる。
インターネットの通信速度が他のlinux/windowsと同じように、900Mbps近くまで出ることを確認。
宅内LANに参加してるんやから、ターミナル画面からそれぞれ接続できることを確認。ついでにgoogle cloudの環境も起動して接続確認。
.terminalのファイルに書いてあるログイン処理と画面色定義がちゃんと使えとる。
ここまでほぼストレートでtahoe利用に移行できた。
ありゃ？ OSのバージョン25.0.1やったけどカーネルは25.0.0なん？ ようわからんけど、そのうちアップデートしてくれるか。
ついでにubuntu24のカーネルバージョンがgoogle cloudとローカルで違ってて、google cloudの方が先に進んどるな。
おいおい調べてくかな。
office365のモジュール更新#
ライセンス認証してから、officeが使えて.xlsxファイルの更新もできることを確認。
kubernetes環境とdocker環境に接続#
armのkubernetesとdockerへのrdp接続はWindowsAppのここから。接続情報も移行できとるはず。
kubernetes環境で
クラスタとpod動いた状態
を作って、まずはssh接続してみる。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
|
root@kubearm:~# onlchk
----- cluster status ------
microk8s is running ⭐️元気にクラスタ動いとる
high-availability: no
datastore master nodes: 127.0.0.1:19001
datastore standby nodes: none
addons:
------ cluster node ------
PRETTY_NAME="Ubuntu 24.04.3 LTS"
Filesystem Size Used Avail Use% Mounted on
efivarfs 256K 37K 220K 15% /sys/firmware/efi/efivars
/dev/mapper/ubuntu--vg-ubuntu--lv 60G 41G 17G 72% /
/dev/vda2 2.0G 67M 1.8G 4% /boot
/dev/vda1 1.1G 6.4M 1.1G 1% /boot/efi
share 461G 415G 46G 91% /microk8s
----- recent cluster ver -----
latest/stable: v1.34.1 2025-10-14 (8496) 160MB classic
installed: v1.34.1 (8497) 160MB classic ⭐️kubernetesクラスタ最新使えとる
1.34/stable: v1.34.1 2025-10-13 (8497) 160MB classic
1.33/stable: v1.33.5 2025-10-13 (8509) 155MB classic
------- images in ctr -------
docker.io/library/save-django:gvis-saved 1.4 GiB
docker.io/library/save-xrdpubu:gvis-saved 6.7 GiB
-------kubectl version -------
clientVersion:
gitVersion: v1.34.1
serverVersion:
gitVersion: v1.34.1
----kubectl po/svc/configmap status ---- ⭐️pod・service・configmap動いとるな
NAME READY STATUS RESTARTS AGE
pod/cl-ubun 1/1 Running 0 2m26s
pod/sv-django 1/1 Running 0 2m3s
pod/sv-https-portal 1/1 Running 0 86s
pod/sv-mariadb 1/1 Running 0 2m27s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/kubernetes ClusterIP 10.152.183.1 <none> 443/TCP 159d
service/sv-django ClusterIP 10.152.183.244 <none> 38080/TCP 159d
service/sv-https-portal ClusterIP 10.152.183.229 <none> 30080/TCP,30443/TCP 159d
service/sv-mariadb ClusterIP 10.152.183.179 <none> 13306/TCP 159d
NAME DATA AGE
configmap/kube-root-ca.crt 1 159d
configmap/sv-mariadb-txt 5 159d
-------kubectl PV -------
NAME CAPACITY ACCESS RECLAIM
gvis-pv-django-sslcerts 1Gi RWO Bound
gvis-pv-django-uwsgi-nginx 1Gi RWO Bound
gvis-pv-mariadb 20Gi RWO Bound
gvis-pv-mariadbconf 5Gi RWO Bound
gvis-pv-ubun 10Gi RWO Bound
pvc-0682501b-65b6-4ee2-9a59-6c32f3ef51fa 30Gi RWX Bound ⭐️イメージ置き場30GBに拡張して使えとる
-------kubectl forward ------- ⭐️サービスをポートフォワードできとる
port-forward --address 0.0.0.0 cl-ubun 33389:3389
port-forward --address 0.0.0.0 sv-django 38080:8080
port-forward --address 0.0.0.0 sv-https-portal 30443:443
port-forward --address 0.0.0.0 sv-mariadb 13306:3306
root@kubearm:~#
|
rdp接続してみる。省くけど、x86のkubernetesで維持してるデータと同じパーセンテージが円グラフで見えとった。
microk8sのkubernetes環境の利用確認終わり。いったんクラスタの仮想マシンshutdownする。
次はrancher desktop起動してdocker環境へrdp接続してみる。
母艦のtahoeでrahcner desktop動かしてコンテナ起動した状態にしとく。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
|
nari@narimac-mini docker % onlchk
------- darwin status --------
Darwin narimac-mini.intra.gavann-it.com 25.0.0 arm64
------- nginx status --------
nginx version: nginx/1.29.2 ⭐️母艦tahoeでnginx動いとる
nginx:master
nginx:worker
------ rancher status --------
rdctl client version: v1.20.0, targeting server version: v1
/Applications/RancherDesktop.app/Contents/Resources/resources/darwin/bin/rdctl
------- docker server --------
27.3.1
------- docker client --------
28.3.3-rd,
------- docker status -------- ⭐️コンテナ動いとる
docker-cl_ubu24gvis-1: gvis-ubu24:24gvis Up 33 seconds
docker-sv_django-1: sv_django:5 Up 15 seconds
docker-sv_https-portal-1: steveltn/https-portal:1 Up 33 seconds (healthy)
docker-sv_mariadb1104-1: docker-sv_mariadb1104 Up 33 seconds
nari@narimac-mini docker %
|
rdp接続してdjangoコンテナに接続し、mariadbのコンテナ読み込んで円グラフ表示できとるな。
musicの利用#
母艦のtahoeでmusicが起動できることも確認。もちろん8410曲全部あった。
大昔に入れた曲と、最近入れたのが見えることを確認。曲送り・戻し・タイトルが窓の上から下へ移動しとる。
仮想tahoeからwindows側にrdp接続し、macosのホームシェアリングがつながるか確認。
同じ曲を違うアーティストやアレンジで聴き比べるプレイリスト開いてみる。
最近お気に入りのTough Boy。世紀末救世主伝説のテーマ曲は、音が割れることもなくちゃんと聞こえる。
TOM★CATが本家やけど、Angelo Bissantiさんという方のが一番ギターアレンジカッコええ。なんとこの方、日本語で歌っておられる。
他にも聖闘士星矢のソルジャー・ドリームなんかめっちゃええアレンジ。
vscode#
vscode使えてるし、gitと連動してgitgraphのプラグインからグラフも見えとる。
hugo - papermod#
hugo稼働させて、ローカルでこのメモ作る仕組みの下地も使えてる。
cyberduckでクラウドのディスク参照#
chromeで表示されたファイル内容と同じものが、cyberduckから見える。
google driveに置いてるのはgoogle cloudのバックアップ。これをローカルにコピーして展開すると、mariadbとファイル類のデータが持ってこれる。
日本語キーボード配列で使う#
さて、ここが難所。
実際はwindowsの日本語キーボード使ってて、母艦tahoeとintel ultra7のwindowsでUSB切り替えて利用。
グラデーションでキートップが光るから、部屋が暗くても文字が見える。
キーボードの右下にあるセミコロンから３つのキーを押したら英字配列になってて、移行アシスタントだけやとうまく使えんかった。
見た目は設定が移せてるように見えるんやけどなぁ。この設定はバックスラッシュとパイプの文字をF4/F5キーで入力するための設定。
システム設定にある入力監視が外れてたからスイッチ入れてみたけどアカン。
どうもドライバ拡張機能がちゃんと動いてへんように見えた。これが原因や。
UTMで「汎用キーボード」って選んどいたのは認識できてるように見える。
JIS配列にもなっとる。
karabinerアンインストールして入れ直し。
前にやった設定
もやりなおしてみる。ログにエラーがないことを確認。さっきの「ログイン項目と機能拡張」が有効になってへんとログにエラー出続けるで。
お、仮想キーボード表示させたら日本語配列になってるっぽい。バックスペースの左側に見える「¥」と右シフトキーの左にある「_」
は入力しても反応せんかった。
実際に文字列入れてみたらちゃんと日本語配列になってて、F4とF5キーに割り当てたバックスラッシュとアンダースコアが入力できるようになってた。
来年からはkarabinerだけ手動で入れ直しってことで。
母艦tahoeと仮想tahoeでファイル共有#
UTMのサイトにあるドキュメント前に読んでたの忘れてた。
ubuntu24にsmb共有あるから、今まで使ってへんかったんやけど、UTMで領域を共有できる。
母艦tahoeから共有を追加して、フォルダ共有してみる。
UTM-shareとか適当な名前のフォルダ用意しといて何かファイル置いてみる。
仮想tahoe側でfinder開いてみると、
unix時間
日付のボリュームが見える。
UTC0:00はJST9:00やからunixエポックね。
開いてみると、さっきのファイルが見える。「読み取り専用」の設定してへんかったら、デスクトップに移動できる。
このメモで使ってる画像はubuntuのsmb共有通さず、UTMの共有機能で仮想tahoeへ持ってきた。
UTMのクリップボードは、親ホストと子ホストの間でファイルコピーはできんけど、共有領域使ったら持って来れる。
文字変換の背景が白くて見づらかったのを修正#
liquid glassのせいなんかもしれんけど、文字変換するときの背景色が白で文字も白で、ハイライトしてる箇所以外がぜんぜん見えんかった。
ダークモードのせいなんかなって思ったけど、色合い調整してみた。マルチカラーってなんやろなって試した。
アプリ終了してから起動しなおしたらなおった。
firefoxの検索入力で試すと、背景が黒、文字が白。見えるやん。
使いながらチョイチョイ調整するかな。
残念なこと#
１つ目は、仮想tahoeはicloudにはログインできるけど、AppStoreにログインできんのはsequoiaのときと同じ。アプリ購入したいのがあっても買えん。
母艦tahoeで買ったら、仮想tahoeにも反映できんのかな。
２つ目は、キーボードの日本語配列で苦労した。
地味に手動で入れ直したら使える。
３つ目は、finderの挙動。
finderのサイドバーにあるlinuxのsmb共有へのホストへのショートカットがきかん。
先に「サーバへ接続」をやっとくと開けはするけど・・・。めんどくさい。
他にも、残念というか白くなって困った。
tahoeは
Liguid glass
っていうGUI環境を使うようになってた。
Aqua
みたいなもんなんやけど、見た目の特徴としてキラキラ感が強いのと、画面のウィンドウの端っこが丸くなってる。
macos26だけやなくios26にも入ってて、壁紙に光るものがあるとアイコンの囲いが白くなってまう。
特に太陽光の下やとiphoneの画面見づらかった。
左のシャリバン隊長のコンバットスーツの光の反射で「メディア」「天気」の枠囲いが白くなってもうて見づらいから、右のギャバン隊長の壁紙に変えた。
そしたら、ダークモードにしてるのに時計とカレンダーのアイコンが白くなってもうた。
iosの設定画面で「liquid」って検索してみたけどなんも出てこん。白くなる特性は変えられへんのか・・・。
