ARM SoC搭載のミニPC MINISFORUM MS-R1でProxmox VEが使える?

ミニPCをいろいろ出しているMINISFORUMからARM SoCを使ったMINISFORUM MS-R1が発売されるとのこと

製品ページを見てみると気になる文面が・・・

「With Proxmox and KVM backed by UEFI boot and the ARM-based CP8180 CPU」

仮想化基盤 Proxmox VEが動く、という意味に読めるのだが、現状公式のProxmox VEはx86_64のサポートのみのはず

どうやったら動くのかな?と調べてみるとServerTheHomeの記事「The Minisforum MS-R1 12-core Arm 10GbE Mini Workstation is」にMINISFORUMがgithubに公開している「MS-R1-Docs」に資料があるよ、とのこと・・・

How to install PVE into MS-R1」というそのものなドキュメントがある。

現状のドキュメントにはちゃんと記載されていないが、梨儿方科技術( Lierfang )社によるPXVIRT というProxmox VEに ARM対応(aarch64) と 龍心対応(loongarch64)を追加するプロジェクトの成果物を使っているようだ。

Proxmox VE自体はもともとDebian OSにProxmox VE用ソフトウェアパッケージ群を追加したものであるため、MS-R1向けProxmox VEも、MS-R1向けDebianをインストールした後に、 PXVIRT(Proxmox VEカスタマイズ)をインストールする、ということになる。

PXVIRT版にNVIDIA vGPUについてのページがあるがコミュニティドライバ(nouveau)は使えず、NVIDIA純正ドライバのみが使えるためx86_64環境でしか使えないようだ。

中国製GPUのMoore Threads GPUについてもページは準備されているが何も記載されていない。こちらについては今後に期待

MS-R1のドキュメントのほうを見ると、「MS-R1 — Run Android in Docker」というDockerコンテナとしてAndrodi OS 14環境を動かす手法が掲載されている。

稼働させたコンテナ上のAndroidはescrcpyというUSB Debugging 機能を利用してリモートから操作する手法を使う模様

MINISFORUM MS-R1、いろいろ面白そうな雰囲気はありますね

GMKtec NucBox G10 miniを買った

先日導入したTRIGKEY MINI PC Key Nに32GBメモリを増設したESXi 8サーバの運用状況がいい感じだったんですが、32GBだとHPE VM Essentialsの3ノードクラスタが立てられない

5月に買ったDDR4 SO-DIMM 32GB 2枚を使えるミニPCはないかなぁ、と探していたところ、GMKtec NucBox G10 miniが候補にあがった。

Ryzen 5 3500Uと、微妙に新しくは無いCPUなので敬遠してたのですが、大きさがいまのTRIGKEY MINIより小さい(まあ、電源内蔵のTRIGKEYと、外付けのG10 miniの違いとも言えますが)

ということで、Amazonで売ってたRAM 16GB+SSD 256GBモデルを 23,998円で購入(セール終わったら28999円になっていました)

ちなみにAliexpressではメモリ/SSDなし、電源はEUタイプで約2万円で売っています

今回の注文については、いろいろな問題がありましたが、なんとか解決し、到着

出してみるとコンパクトですね

上面はネジ止めされていない、蓋がツメでとまっているタイプなので、うまいこと外します

ヒートシンク付きのSSDの下側にWiFi/BluetoothのRTL8822CEがありました

裏面はゴム足を取るとネジが4つあるので、それを外して蓋を開きます

ホコリが詰まりそうなので、時々掃除した方がよさそうですね。

Windows11の初期状態確認

電源を入れて起動してみると、初期インストールの‘Windows11は24H2でしたが、キーボード配列が‘‘英語用になっていました

インストール日が2047年ってw

Windows 11 Proのライセンス区分はOEM_DMで問題なし

256GB SSDの場合の初期ディスクレイアウトはこんな感じでした。

タスクマネージャー上でのCPU/メモリなどの認識状況確認

CPUはAMD Ryzen 5 3500U, CPUコア4個、スレッドは8個

SSDはTWSC TSC18N256-F7T10A …メーカのTWSCにあるPCIe SSD ページみると製品型番っぽいのが無い(各ページにあるサンプル製品の型番っぽいところは 12345678912 という適当表記)

NICはRealtek PCIe 2.5GbE Family Controller…どうやらRTL8125 っぽい

GPU はAMD Radeon(TM) Graphics でGPUメモリは専用3GB/共有6.5GB

デバイスマネージャ上でのネットワーク系のデバイス認識状況を確認

初期でインストールされているプログラム

スタートメニューにはSystemInfoいないんだけど、インストールされてるらしい

インストールされているAMD Settingsを起動すると、AMD Software Adrenalin Edition 23.19.18 となっている。


Windows 11の再インストールとドライバ適用

続いてSSDを交換し、Windows 11 24H2メディアを使って再インストール実施試験

WIndows Update を行ったあとのデバイス認識状況を確認

一見大丈夫そうに見えるがディスプレイアダプタが汎用認識状態

AMDのWebからドライバー amd-software-adrenalin-edition-25.10.2-minimalsetup-251027_web.exeをインストールしてみたら、下記のドライバがインストールされる(注:あとでわかりますがこのドライバは誤りでした)

しかし適用されていないのでよくよく↑の結果を見てみるとグラフィックドライバーが含まれていないため、アンインストール&再起動を実施。

先ほどのやつは大区分からインストールしてたので、次は各製品ページである「AMD Ryzen™ 5 3500U Drivers and Downloads – Latest Version」からをwhql-amd-software-adrenalin-edition-25.8.1-win10-win11-aug-vega-polaris.exeインストールしようとしたところ失敗

最新版の問題を疑って、以前のバージョン「AMD Ryzen™ 5 3500U Drivers and Downloads – Previous Versions」からwhql-amd-software-adrenalin-edition-23.11.1-win10-win11-nov3-vega-polaris.exeをインストールしても失敗。

Windowsイベントログには特に何もなし

まあ、Secure Boot署名の有効期限切れ警告がありますけどね・・・

ログの名前:         System
ソース:           Microsoft-Windows-TPM-WMI
日付:            2025/11/03 10:34:30
イベント ID:       1801
タスクのカテゴリ:      なし
レベル:           エラー
キーワード:         
ユーザー:          SYSTEM
コンピューター:       gmktecg10
説明:
Secure Boot CA/keys need to be updated. This device signature information is included here.
DeviceAttributes: BaseBoardManufacturer:GMKtec;FirmwareManufacturer:American Megatrends Inc.;FirmwareVersion:Nucbox G10 1.04;OEMModelNumber:NucBox_G10;OEMModelBaseBoard:GMKtec;OEMModelSystemFamily:MINI;OEMManufacturerName:GMKtec;OEMModelSKU:G10-001;OSArchitecture:amd64;
BucketId: 55e726482bc0c005c1d679c0126136223bace851c219b806aa8b8594d8d17946
BucketConfidenceLevel: 
UpdateType: 0
HResult: この操作を正しく終了しました。
イベント XML:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-TPM-WMI" Guid="{7d5387b0-cbe0-11da-a94d-0800200c9a66}" />
    <EventID>1801</EventID>
    <Version>0</Version>
    <Level>2</Level>
    <Task>0</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8000000000000000</Keywords>
    <TimeCreated SystemTime="2025-11-03T01:34:30.7530016Z" />
    <EventRecordID>1759</EventRecordID>
    <Correlation />
    <Execution ProcessID="1900" ThreadID="3344" />
    <Channel>System</Channel>
    <Computer>gmktecg10</Computer>
    <Security UserID="S-1-5-18" />
  </System>
  <EventData>
    <Data Name="DeviceAttributes">BaseBoardManufacturer:GMKtec;FirmwareManufacturer:American Megatrends Inc.;FirmwareVersion:Nucbox G10 1.04;OEMModelNumber:NucBox_G10;OEMModelBaseBoard:GMKtec;OEMModelSystemFamily:MINI;OEMManufacturerName:GMKtec;OEMModelSKU:G10-001;OSArchitecture:amd64;</Data>
    <Data Name="BucketId">55e726482bc0c005c1d679c0126136223bace851c219b806aa8b8594d8d17946</Data>
    <Data Name="BucketConfidenceLevel">
    </Data>
    <Data Name="UpdateType">0</Data>
    <Data Name="HResult">0</Data>
  </EventData>
</Event>

プレインストールはver23.19.18のバージョンだったけど、製品一覧にないな、と不思議に思っていたのですが「Radeon™ Vulkan® Drivers Version Table」にて”Adrenalin Release”と”Internal Driver”の数値が異なる、ということが判明

しかし、whql-amd-software-adrenalin-edition-23.11.1-win10-win11-nov3-vega-polaris.exe も whql-amd-software-adrenalin-edition-25.8.1-win10-win11-aug-vega-polaris.exe も本来正しいはずのもの

ちょっと状態がよくわからないのでWindows 11 25H2で再インストール

で、whql-amd-software-adrenalin-edition-25.8.1-win10-win11-aug-vega-polaris.exe をインストールしようとしてもダメ

デバイスマネージャからディスプレイドライバの適用を強行すればGPU認識などをちゃんとすることはできましたが、AMD Settingsアプリのインストールができない状態となるため、いまいちでした。

最終的には、GMKtec公式で配布しているドライバーセットを適用しなければ認識できない、という状態であることが判明

G10_Drivers_Win11_x64_v0.4_20250820.zip を展開し、「Install_AMD_ADB55_3500U_R21C_R22C.bat」を管理者権限で実行することでインストールが完了した。

そして再起動(再起動は要求されないけど)するとRadeonとして認識

インストールされたAMD Setting

先ほどは空欄だったWindows設定画面のグラフィックスカード表記

メモリーを64GBに交換

GPUメモリ割り当てを8GBにした場合のメモリ/GPU認識状況

専用GPUメモリ 8GB、共有GPUメモリ28GBに変化

Intel N95搭載PCでUSB NICをつけてESXi 8.0を使った場合再起動すると通信できなくなる件の対処方法

Intel N95搭載のミニPC TRIGKEY MINI PC Key N に32GBメモリを載せたので、仮想基盤にしてみるかと、VMware ESXi 8.0の無償ライセンス版をインストールしてようと思った。

標準状態ではオンボードNICを認識してくれず、インストール不可。

手持ちのUSB NICをさしたところNICとして認めてくれたようで、ESXiのインストールが出来た。

ただ、動作が少しおかしい

再起動するとネットワーク接続ができなくなる

ESXiのコンソールでみるとIPアドレスはきちんと割り当てられている

しかし[Configure Management Network]-[Network Adapters]を確認すると、アダプタの割り当てが外れている

チェックを入れ直して設定保存するとESXi自体のネットワークが通るようになる

この設定を行うまでは、ESXiサーバから外部へのping/sshはできないし、外部からESXiのWebアクセスもできない

原因調査

Ctrl-Alt-F1でESXi shellを開いて「esxcli network vswitch standard list」で設定を取ると、再起動直後は下記で、UplinkにNICが登録されていない

[root@esxi:~] esxcli network vswitch standard list vSwitch0
   Name: vSwitch0
   Class: cswitch
   Num Ports: 2560
   Used Ports: 2
   Configured Ports: 128
   MTU: 1500
   CDP Status: listen
   Beacon Enabled: false
   Beacon Interval: 1
   Beacon Threshold: 3
   Beacon Required By:
   Uplinks:
   Portgroups: VM Network, Management Network
[root@esxi:~] 

ESXiコンソールから設定修正を行ったあとは以下に変わる

[root@esxi:~] esxcli network vswitch standard list vSwitch0
   Name: vSwitch0
   Class: cswitch
   Num Ports: 2560
   Used Ports: 4
   Configured Ports: 128
   MTU: 1500
   CDP Status: listen
   Beacon Enabled: false
   Beacon Interval: 1
   Beacon Threshold: 3
   Beacon Required By:
   Uplinks: vusb0
   Portgroups: VM Network, Management Network
[root@esxi:~] 

Uplinksが未割り当てとなったことが原因の様に見えるのでESXiコンソールからの操作の代わりに「esxcli network vswitch standard uplink add –vswitch-namevSwitch0 –uplink-name=vusb0」を実行してみたものの ネットワークがつながらず、ESXiコンソール操作を実行しなければならなかった。

ESXiコンソール操作の変更反映画面に「Configure Management Network」とあるのでvSwitchの設定だけではなくポートグループ設定周りも見直す必要があるのでは?と esxcli network vswitch standard のオプション類をいろいろ探していくと、esxcli network vswitch standard portgroup policy failover にて怪しい状況を発見

[root@esxi:~] esxcli network vswitch standard portgroup policy failover get --portgroup-name="Management Network"
   Load Balancing: srcport
   Network Failure Detection: link
   Notify Switches: true
   Failback: true
   Active Adapters:
   Standby Adapters:
   Unused Adapters: vusb0
   Override Vswitch Load Balancing: true
   Override Vswitch Network Failure Detection: true
   Override Vswitch Notify Switches: true
   Override Vswitch Failback: true
   Override Vswitch Uplinks: true
[root@esxi:~] esxcli network vswitch standard portgroup policy failover get --portgroup-name="VM Network"
   Load Balancing: srcport
   Network Failure Detection: link
   Notify Switches: true
   Failback: true
   Active Adapters:
   Standby Adapters:
   Unused Adapters: vusb0
   Override Vswitch Load Balancing: false
   Override Vswitch Network Failure Detection: false
   Override Vswitch Notify Switches: false
   Override Vswitch Failback: false
   Override Vswitch Uplinks: false
[root@esxi:~] 

「Management Network」と「VM Network」のポートグループに割り当てられているはずのvusb0が「Unused Adapters」に割り当てられている

これらを 「Active Adapters」に割り当て直せばいいのか?とCLIで設定変更を行ってみる

[root@esxi:~] esxcli network vswitch standard portgroup policy failover set --portgroup-name="Management Network" --active-uplinks=vusb0
[root@esxi:~] esxcli network vswitch standard portgroup policy failover set --portgroup-name="Management Network"
   Load Balancing: srcport
   Network Failure Detection: link
   Notify Switches: true
   Failback: true
   Active Adapters: vusb0
   Standby Adapters:
   Unused Adapters:
   Override Vswitch Load Balancing: true
   Override Vswitch Network Failure Detection: true
   Override Vswitch Notify Switches: true
   Override Vswitch Failback: true
   Override Vswitch Uplinks: true
[root@esxi:~] 

ポートグループManagement Networkについての設定変更でESXi上から外部ネットワークへ通信が可能となった

この状況では仮想マシンを起動しても、VM NetworkのActive Adaptersが設定されていないため外部ネットワークに接続できない。

続いてVM NetworkのUnsed Adapterについて設定変更を実施

[root@esxi:~] esxcli network vswitch standard portgroup policy failover set --portgroup-name="VM Network" --active-uplinks=vusb0
[root@esxi:~] 
   Load Balancing: srcport
   Network Failure Detection: link
   Notify Switches: true
   Failback: true
   Active Adapters: vusb0
   Standby Adapters:
   Unused Adapters:
   Override Vswitch Load Balancing: false
   Override Vswitch Network Failure Detection: false
   Override Vswitch Notify Switches: false
   Override Vswitch Failback: false
   Override Vswitch Uplinks: true
[root@esxi:~] 

この設定実行後、仮想マシンからの外部への通信も成功した

ESXi再起動後、再設定を行い、再現性があることも確認した。

ESXiのパラメータ設定で対応可能

最初は後述の「起動時にコマンドを自動実行させる方法」を使っていたのだが、unused adapterで調べ直すと usbBusFullScanOnBootEnabled パラメータを設定することで対処できる、という話を発見

ESXi 7.0 Update 2 enhancement for USB NIC only installations」の後半に書かれている

ESXiの起動時、ESXiのvSwitch設定プロセスよりあとにUSB NICの認識が行われていることで登録できない、という状態であるため、最初にUSBデバイスの認識を行う、という順序に変える、というパラメータのようである。

設定の出典を調べると現存しない VMware Flings時代の「USB Network Native Driver for ESXi」の「Persisting USB NIC Bindings」に下記の様に記載されているものだった。

Persisting USB NIC Bindings
Option 1: Run the following ESXCLI command which will enable the driver parameter to perform a full USB bus scan during startup:
esxcli system module parameters set -p “usbBusFullScanOnBootEnabled=1” -m vmkusb_nic_fling

これらの記事は古いので、ESXi 8.0 Update 3eでも該当するモジュール vmkusb_nic_fling とパラメータ usbBusFullScanOnBootEnabled があるのかを確認してみる

[root@esxi:~] esxcli system module list|grep nic
vmkusb_nic_fling                     true        true
[root@esxi:~] esxcli system module list|grep usb
vmkusb_nic_fling                     true        true
[root@esxi:~]

モジュール vmkusb_nic_fling は、ESXi 8.0でも存在している。

モジュールに対して設定できるパラメータを確認。

[root@esxi:~] esxcli system module parameters list -m vmkusb_nic_fling
Name                         Type    Value  Description
---------------------------  ------  -----  -----------
usbBusFullScanOnBootEnabled  int            Enable USB Bus full scan on system boot: 0 No (Default), 1 Yes
usbCdromPassthroughEnabled   int            Enable USB CDROM device for USB passtrough: 0 No (Default), 1 Yes
usbStorageRegisterDelaySecs  int            Delay to register cached USB storage device: Min: 0 second, Max: 600 seconds, Default: 10 seconds
vusb0_mac                    string         Persist vusb0 MAC Address: xx:xx:xx:xx:xx:xx
vusb10_mac                   string         Persist vusb10 MAC Address: xx:xx:xx:xx:xx:xx
vusb11_mac                   string         Persist vusb11 MAC Address: xx:xx:xx:xx:xx:xx
vusb1_mac                    string         Persist vusb1 MAC Address: xx:xx:xx:xx:xx:xx
vusb2_mac                    string         Persist vusb2 MAC Address: xx:xx:xx:xx:xx:xx
vusb3_mac                    string         Persist vusb3 MAC Address: xx:xx:xx:xx:xx:xx
vusb4_mac                    string         Persist vusb4 MAC Address: xx:xx:xx:xx:xx:xx
vusb5_mac                    string         Persist vusb5 MAC Address: xx:xx:xx:xx:xx:xx
vusb6_mac                    string         Persist vusb6 MAC Address: xx:xx:xx:xx:xx:xx
vusb7_mac                    string         Persist vusb7 MAC Address: xx:xx:xx:xx:xx:xx
vusb8_mac                    string         Persist vusb8 MAC Address: xx:xx:xx:xx:xx:xx
vusb9_mac                    string         Persist vusb9 MAC Address: xx:xx:xx:xx:xx:xx
[root@esxi:~]

usbBusFullScanOnBootEnabled が初期値0で存在していることを確認

(“Persisting VMkernel to USB NIC mappings”に記載されている複数のUSB NICがある時に、指す場所を変えてもvusbの番号が変わらないようにするための設定も引き続きある)

現段階のesxcliでの正式オプションに修正して、「esxcli system module parameters set –module=vmkusb_nic_fling –parameter-string=”usbBusFullScanOnBootEnabled=1″」と実行する

[root@esxi:~] esxcli system module parameters set --module=vmkusb_nic_fling --parameter-string="usbBusFullScanOnBootEnabled=1"
[root@esxi:~] esxcli system module parameters list -m vmkusb_nic_fling
Name                         Type    Value  Description
---------------------------  ------  -----  -----------
usbBusFullScanOnBootEnabled  int     1      Enable USB Bus full scan on system boot: 0 No (Default), 1 Yes
usbCdromPassthroughEnabled   int            Enable USB CDROM device for USB passtrough: 0 No (Default), 1 Yes
usbStorageRegisterDelaySecs  int            Delay to register cached USB storage device: Min: 0 second, Max: 600 seconds, Default: 10 seconds
vusb0_mac                    string         Persist vusb0 MAC Address: xx:xx:xx:xx:xx:xx
vusb10_mac                   string         Persist vusb10 MAC Address: xx:xx:xx:xx:xx:xx
vusb11_mac                   string         Persist vusb11 MAC Address: xx:xx:xx:xx:xx:xx
vusb1_mac                    string         Persist vusb1 MAC Address: xx:xx:xx:xx:xx:xx
vusb2_mac                    string         Persist vusb2 MAC Address: xx:xx:xx:xx:xx:xx
vusb3_mac                    string         Persist vusb3 MAC Address: xx:xx:xx:xx:xx:xx
vusb4_mac                    string         Persist vusb4 MAC Address: xx:xx:xx:xx:xx:xx
vusb5_mac                    string         Persist vusb5 MAC Address: xx:xx:xx:xx:xx:xx
vusb6_mac                    string         Persist vusb6 MAC Address: xx:xx:xx:xx:xx:xx
vusb7_mac                    string         Persist vusb7 MAC Address: xx:xx:xx:xx:xx:xx
vusb8_mac                    string         Persist vusb8 MAC Address: xx:xx:xx:xx:xx:xx
vusb9_mac                    string         Persist vusb9 MAC Address: xx:xx:xx:xx:xx:xx
[root@esxi:~]

設定後、ESXiを再起動してもネットワーク接続に問題ないことを確認した。

起動時にコマンドを自動実行させる方法

usbBusFullScanOnBootEnabled パラメータの手法を発見する前は、起動時にこれらの設定を自動的に実行するように設定して対応していた。

ESXi 5.1時代にVMware HA有効時に仮想マシンの自動起動をしたい で使用した rc.local 設定 について調べると 2025年8月更新のKB「Modifying the rc.local or local.sh file in VMware vSphere ESXi to execute commands while booting」にて、vSphere 8でも使用可能とあるため、これを使う

初期状態の /etc/rc.local.d/local.sh の内容を確認

[root@esxi:~] ls -l /etc/rc.local.d
total 32
-r-xr-xr-x    1 root     root           378 Apr  3  2025 009.vsanwitness.sh
drwxr-xr-x    1 root     root           512 Oct  3 00:25 autodeploy
-r-xr-xr-x    1 root     root          2249 Apr  3  2025 backupPrevBootLogs.py
-r-xr-xr-x    1 root     root          2071 Apr  3  2025 cleanupStatefulHost.py
-r-xr-xr-x    1 root     root          2567 Apr  3  2025 kickstart.py
-rwxr-xr-t    1 root     root           506 Apr  3  2025 local.sh
-r-xr-xr-x    1 root     root           397 Apr  3  2025 psaScrub.sh
-r-xr-xr-x    1 root     root          1190 Apr  3  2025 raiseConfigStoreVob.py
[root@esxi:~] cat /etc/rc.local.d/local.sh
#!/bin/sh ++group=host/vim/vmvisor/boot

# local configuration options

# Note: modify at your own risk!  If you do/use anything in this
# script that is not part of a stable API (relying on files to be in
# specific places, specific tools, specific output, etc) there is a
# possibility you will end up with a broken system after patching or
# upgrading.  Changes are not supported unless under direction of
# VMware support.

# Note: This script will not be run when UEFI secure boot is enabled.

exit 0
[root@esxi:~]

今回実行したesxcliのコマンド群を追加

[root@esxi:~] vi /etc/rc.local.d/local.sh
[root@esxi:~] cat /etc/rc.local.d/local.sh
#!/bin/sh ++group=host/vim/vmvisor/boot

# local configuration options

# Note: modify at your own risk!  If you do/use anything in this
# script that is not part of a stable API (relying on files to be in
# specific places, specific tools, specific output, etc) there is a
# possibility you will end up with a broken system after patching or
# upgrading.  Changes are not supported unless under direction of
# VMware support.

# Note: This script will not be run when UEFI secure boot is enabled.

esxcli network vswitch standard uplink add --vswitch-name=vSwitch0 --uplink-name=vusb0
esxcli network vswitch standard portgroup policy failover set --portgroup-name="Management Network" --active-uplinks=vusb0
esxcli network vswitch standard portgroup policy failover set --portgroup-name="VM Network" --active-uplinks=vusb0

exit 0
[root@esxi:~]

以前は auto-backup.sh を手動で実行する必要があったけど、2025/10/03時点のKBには記載がないが、下記で行ったように現時点でもauto-backup.shを実行しないと設定が消えてしまうと思われる。

[root@esxi:~] date
Fri Oct  3 00:57:12 UTC 2025
[root@esxi:~] ls -ltr /bootbank/
total 261895
<略>
-rwx------    1 root     root          1797 Sep 17 16:34 boot.cfg
-rwx------    1 root     root           102 Oct  3 00:25 jumpstrt.gz
-rwx------    1 root     root        266977 Oct  3 00:31 state.tgz
[root@esxi:~]

/bootbank/state.tgz が更新されていない

[root@esxi:~] auto-backup.sh
ConfigStore has been modified since the last backup
Bootbank lock is /var/lock/bootbank/f43b0450-7e4d6762-c6be-52e6552cc1f8
INFO: Successfully claimed lock file for pid 526790
Saving current state in /bootbank
Ssh configuration synced to configstore
Creating ConfigStore Backup
Locking esx.conf
Creating archive
Unlocked esx.conf
Using key ID d27fa69c-5edc-424d-bc0f-61d7966bf4d4 to encrypt
Clock updated.
Time: 00:57:21   Date: 10/03/2025   UTC
[root@esxi:~]

auto-backup.shを実行後を確認

[root@esxi:~] ls -ltr /bootbank/
total 261895
<略>
-rwx------    1 root     root          1797 Sep 17 16:34 boot.cfg
-rwx------    1 root     root           102 Oct  3 00:25 jumpstrt.gz
-rwx------    1 root     root        266974 Oct  3 00:57 state.tgz
[root@esxi:~]

/bootbank/state.tgz が更新された

更新後、ESXiを再起動してみると、ちゃんとネットワークに接続できる状態でESXiが起動することを確認できた


2025/11/03 追記

VMware flingsで配布している「USB Network Native Driver for ESXi」からvmkusb_nic_fling ドライバをインストールすると、使えるUSB NICの種類が増える

[root@esxi:/vmfs/volumes/6908722d-a37ea8a3-525a-4d150daf152f/iso] esxcli software vib install -d /vmfs/volumes/datastore1/iso/ESXi8
03-VMKUSB-NIC-FLING-76444229-component-24179899.zip
Installation Result
   Message: The update completed successfully, but the system needs to be rebooted for the changes to be effective.
   VIBs Installed: VMW_bootbank_vmkusb-nic-fling_1.14-2vmw.803.0.0.76444229
   VIBs Removed:
   VIBs Skipped:
   Reboot Required: true
   DPU Results:
[root@esxi:/vmfs/volumes/6908722d-a37ea8a3-525a-4d150daf152f/iso]

インストール後、再起動は必須

Surface Pro 7を買ったのでWindows 11 をインストールしてみた

秋葉原でSurface Pro 7の黒が14400円だったので買ってきた

ちゃんとした手順を踏むのであれば、”Surface の USB 回復ドライブの作成と使用“を使うのだが、あえて普通のWindows 11 24H2メディアを使ってインストールを試みた。

この場合も、Surface 用のドライバーとファームウェアをダウンロードする から 「Surface Pro 7 Drivers and Firmware」のドライバ/Firmwareセットをダウンロードすれば終わりなのだが、あえてこれを使わない場合の再インストールを行ってみた。

Windows 11 24H2 メディアのみでの再インストール手法

まず、注意点として、標準的なWindows 11 24H2メディアではSurface Pro 7のタッチパネル操作が行えないため、別途マウスを用意する必要がある。

さて、Surface Pro 7を標準的なWindows 11 24H2メディアでインストールした直後は、下記のように認識していないデバイスがある。

ただ、これらについては、下記のようにWindows Updateを実施すればすべて解消する

解消するのだが、再起動が3回必要だった。

よく見たら上記のWindows Updateで適用されているSurface Firmwareのバージョンは2025/09/30付けで単体ダウンロードが可能になってるFirmwareと同じですね

回復メディアを使用しての再インストール手法

次に、Surface Pro 7の回復メディアを作成してWindows 11 24H2のインストールを行った。

この場合は、インストール直後ですべてのデバイスは認識しているものの、Windows Updateでのドライバ更新は同様にあり、2回ぐらい再起動が必要となった。

また、ディスプレイの拡大率が200%で設定されていた。(標準メディアだと150%)

標準でインストールされているアプリが大分違っていた。

Lifebook U938/S に 32GBメモリを載せてみた

富士通 Lifebook U938/Sに32GBのメモリを載せてみたところ、オンボード4GBと合わせて36GBメモリ認識として使用できるようになった。

今回買ったのはWINTENのSO-DIMM DDR4 3200 32GBです

まあ2枚セットで買ったので、ついでにN95搭載のTRIGKEY にも載せてみて、N95の仕様上は最大メモリーサイズ16GBと書かれているのが突破できていることも確認したりした。