Virtualbox 从7.2.20降级到7.2.18 @FreeBSD系统

最近Virtualbox win10虚拟机一直崩,不得已把它从7.2.20降级到7.2.18

让AI查找一直崩的问题

先纠正一个事实：这份日志记录的是 7.2.20 r175154 （编译于 Oct 17），并非 7.1.x；它开头第一行就写着 VirtualBox VM 7.2.20 r175154。因此配置版本并没有回退，仍是之前那个有设备层回归的版本。

逐段检查这份日志，发现启动阶段是健康的，但核心问题依旧存在：

内存余量恢复正常 ：Host RAM: ... 42638MB (41.6GB) available；之前几次启动只剩 19~21 GB，说明内存压力已经缓解。
客机正常起了系统：BIOS → 硬盘引导 → HyperV GIC 初始化 → Guest Additions 7.2.20 加载 → VBoxService 启动，时间线连贯，没有异常掉线。
两条固定告警照旧出现 ：VBoxVBVAEnable failed! 和一批 resolution xxx not accepted by the frontend。这两条就是设备模拟层一直在降级路径上运行的表现，和上次崩溃栈落在 VBoxDD 完全对应。
VERR_HGCM_SERVICE_NOT_FOUND 是非致命噪声：它只是宿主在 guest 还没启动 Guest Additions 前查询属性失败，每次启动都有，可以直接忽略。
Firmware type: failed - VERR_NOT_SUPPORTED 和 HID LEDs sync is not supported：FreeBSD 宿主下的常见提示，与崩溃无关。

另外，还有一处值得注意：日志显示 AVX2 = 0、SMEP = 0、Guest = 0 (Host = 1)；这是 VirtualBox 按 IvyBridge CPU 型号主动屏蔽。再加上 EnableLargePages、EnableNestedPaging 和 6 个 vCPU 全部开启，EPT 页表开销集中在 12 个逻辑核上；设备层一旦走到降级路径，就更容易被拖崩。

关于降级，我在 7.1.18 上实测受阻，需要先告诉你：

从 pkg 缓存解出 7.1.18 二进制，用法基本可用，VBoxManage --version 返回 7.1.18r173720
但 7.1.18 的 binaries 里，settings 版本最高只认到 1.20；当前全局配置 VirtualBox.xml 已是 1.21-freebsd（7.2.20 写的），会直接报 Cannot handle settings version；win10.vbox 本身是 1.19，那一层没问题

也就是说，走 7.1.18 必须先手工把全局配置降格式，代价是会丢 7.2 新增的全局设置。这是我在实际测试中发现的真实阻碍，所以之前"仓库还有包，装上就能用"的判断要修正。

现在给你三个可操作的选择，请你定一个：

A. 仍然走 7.1.18（你要的方向，但需多一步）

备份全局配置后，把 version="1.21-freebsd" 改成 1.20-freebsd 并删掉 7.2 特有字段
停止 3 台虚拟机 → pkg install virtualbox-ose-71-7.1.18_1 + virtualbox-ose-kmod-71-7.1.18.1501000 → 卸载 7.2.20 → 重载 vboxdrv
风险：7.1 分支上游已 EOL（2026-04-21），死胡同；且全局设置会退化

B. 回 7.2.12（上次判定的主因修复点）

userspace 直接用缓存包，kmod 从 ports 就地编译（源码树和运行内核都是 15.1-RELEASE-p1，匹配）
约 10~20 分钟，版本自洽，不损失全局设置

C. 先不降级

保留现在的 7.2.20，只做内存、vCPU、ARC、音频的调优，观察是否复发

我的建议是 B。你如果坚持 A，我也可以按 A 做，但请知道要多改全局配置，而且这条路 12 月底后包会消失。

另外提醒：之前你说自己停虚拟机，现在日志显示 win10 在 09:12 又起来了。降级必须三台全停（win10、ubuntu、FreeBSD），否则 vboxdrv 卸不掉。

备份我已做好在 /root/vbox-downgrade-backup/（VM 目录 237G + 配置 54M），随时可回滚。

准备去做降级到7.2.18

你提出的这个顾虑确实成立，它改变了整个操作方案。先说明一点：我通过 SSH 连接 192.168.0.88 执行命令，这条通道本身不依赖 Guest 网络。

停机后哪些步骤会中断

要让 kldunload vboxdrv 成功执行，必须所有 VM 全部停止。而 win10 一旦停止，它就同时承担着两个角色：

它是被操作对象，必须先停止；
它又是承载你桌面会话的机器，你在这个会话里执行命令。

关键在于 kldunload 是内核操作，必须在 FreeBSD 宿主机上直接执行，不能提前放进 VM 里做。

可行的做法：用 SSH 会话在宿主机上执行

如果 win10 里承载的是"这台机器的控制入口"，并不等于"这条远程会话的宿主"，那么有办法：我已经可以通过 workbuddy@192.168.0.88 用 SSH 登录宿主机并执行 root 命令。这个 SSH 会话运行在 FreeBSD 上，不经过 win10。

但这里有一个真实风险需要说清楚：当前这条会话是否由 win10 承载。如果我在桌面里运行，win10 停止后桌面本身就会消失。所以我需要先确认 SSHD 和网络路径完全不依赖 win10。

更稳妥的方案：全程无交互脚本

最佳做法是把整个流程写成一个脚本，用 nohup 或 at 在宿主机后台运行，这样即使会话断开，操作也会继续：

复制代码

#!/bin/sh
# 后台执行：停 VM → 换包 → 重载模块 → 重启 win10
set -e

# 1. 停所有 VM
for vm in $(VBoxManage list runningvms | awk -F'"' '{print $2}'); do
    VBoxManage controlvm "$vm" savestate
done

# 2. 换包
pkg install -y virtualbox-ose-71-7.1.18_1
pkg install -y virtualbox-ose-kmod-71-7.1.18.1501000

# 3. 按依赖逆序卸模块
kldunload vboxnetadp || true
kldunload vboxnetflt || true
kldunload vboxguest || true
kldunload vboxdrv || true

# 4. 加载新模块
kldload vboxdrv
kldload vboxnetflt
kldload vboxnetadp

# 5. 用新版本启动 win10
su - skywalk -c "VBoxManage startvm win10"

用 at now + 1 minute 调度这个脚本，这样 VM 停止后脚本仍会继续运行，不受桌面消失影响。

但先别急着做，有两件事必须先确认

第一，上午 7.1.18 的失败还没有结论。 10:18 和 10:26 那两次 signal 6（SIGABRT）说明 7.1.18 在你这台机器上启动后就直接 abort 了。SIGABRT 通常表示断言失败或配置不兼容。如果这个问题不解决，重装后还会照样崩溃，而这次你会因为 VM 停掉而无法及时排查。

所以我建议：安装完成后立即验证脚本能否正常启动，不要在无人值守的情况下把 VM 完全停掉。

第二，你现在跑的仍是 7.2.20。 如果目标版本是 7.1.18，配置格式问题必须先解决；如果目标版本是 7.2.12（我更推荐），则需要先在 ports 里编译 kmod。

我的建议

考虑到 win10 停机会让你失去观察窗口，最安全的顺序是：

先编译好 7.2.12 的 kmod ：这步不需要停 VM，在 ports 里 make 即可，耗时 10 到 20 分钟。
写好并测试脚本语法：不启动，只做 shell 语法检查。
用 at 调度一次性执行 ：中途若失败，脚本会把日志写到 /root/vbox-switch.log。
你自己留一个外部观察方式：比如手机 SSH 客户端，或者宿主机旁有个能用的终端。

这样即使 VM 停止 2 分钟，你也能知道结果，不用等我。

请确认两件事，我再动手：

目标版本：7.2.12 （推荐，已证明崩溃最少）还是 7.1.18（上午失败过）？
你手上是否有不经过 win10 的宿主机访问方式 ？如果有，整个流程可以让我全程执行；如果没有，就需要用 at 定时调度，并且你必须接受执行期间 VM 不可用。

检查全部通过，有一个好消息：全局配置现在已经是 1.20-freebsd，说明上午 7.1.18 那次安装把它降过格式了，7.2.12 读取完全没有障碍。

已完成的部分（未碰 win10）

内核模块已编译好。7.2.12 的 kmod 在宿主机上从源码编译完成，三个模块全部产出：

复制代码

vboxdrv.ko      550912 字节
vboxnetflt.ko    34536 字节
vboxnetadp.ko    16288 字节

打包为 virtualbox-ose-kmod-72-7.2.12.1501000.pkg，位于：

/root/vbox-712-build/virtualbox-ose-kmod-72/work/pkg/

编译过程中有一个真实的坑，值得记下来：ports 树里当前的补丁是基于 7.2.14 写的，直接拿去编译 7.2.12 会失败。具体是 VBoxNetAdp-freebsd.c 的补丁上下文对不上，7.2.14 里那个位置是 vboxNetAdpStrncpy(...)，而 7.2.12 是 strncpy(...)。我改了这一行上下文后 8 个 hunk 全部干净应用。

用户态包已就位，直接用 pkg 缓存里的：

/var/cache/pkg/virtualbox-ose-72-7.2.12~2859643b81.pkg

这个包是 FreeBSD:15:amd64，和你系统匹配，不需要再编译。

切换脚本已写好并通过语法检查 ，位于 /root/vbox-712-build/switch-712.sh。

按你的要求，我没有做最后一步

脚本里虽然包含停 VM 的逻辑，但我没有执行。因为 win10 就是我们自己，执行那一刻画面就没了。

脚本现在的设计是：用 savestate 而不是 poweroff 停 win10，这样恢复时是接着跑，不用重新开机，可以减少你失去画面的时间。

你要怎么触发

在 FreeBSD 的本地控制台（按 Ctrl+Alt+F2 之类的 TTY 切换，或者用另一台设备 SSH）上执行：

复制代码

sudo sh /root/vbox-712-build/switch-712.sh --check   # 先看一眼，只读
sudo sh /root/vbox-712-build/switch-712.sh           # 真正执行

脚本会全程写日志到 /root/vbox-712-build/switch-712.log，包括每一步的成败。关键设计是每步失败都会明确记录并中止，不会带着半成品状态继续往下走。

两个必须说清的风险

第一，执行期间你会失去画面。 停 win10 到它被重新启动，中间有几秒到几十秒的黑屏或等待。如果启动失败，你就只能靠 TTY 或另一台机器来救。脚本里已经处理了"启动失败要手动执行什么命令"的提示。

第二，7.2.12 不是"零风险"方案。 我前面查过日志，7.2.12 时期只崩过 1 次，而且是 GUI 进程，不是 VM 进程。但那是 7 月的数据，样本量只有一个月。这次切换是把它当成"已知最稳的版本"来用，不是保证一定不崩。

如果切换后还想再降一档，下一个候选是 7.1.x，但那需要先处理配置格式问题，而且上午已经试过两次 SIGABRT。

现在你要么自己挑时间在 TTY 上执行，要么告诉我你准备什么时候切，我可以在旁边守着日志帮你判断每步结果。

实践操作

碰到问题

删除了很多快照备份,现在win10虚拟机显示"删除当前运行状态的备份",其它虚拟机都是显示"已关闭"

复制代码

VBoxManage showvminfo win10 --machinereadable | grep '^VMState='

执行报错

skywalk@fb98:~ $ VBoxManage showvminfo win10 --machinereadable | grep '^VMState='

VBoxManage: error: Failed to assign the machine to the session (E_ACCESSDENIED)

VBoxManage: error: Details: code VBOX_E_VM_ERROR (0x80bb0003), component MachineWrap, interface IMachine, callee nsISupports

VBoxManage: error: Context: "LockMachine(a->session, LockType_Shared)" at line 3328 of file VBoxManageInfo.cpp

最可能的原因：VBoxSVC 残留进程

VBoxSVC 是 VirtualBox 的后台服务进程。即使你关掉了图形界面，它也可能在后台继续运行，并持有对虚拟机的锁。这是导致 LockMachine 失败最常见的原因。

解决步骤：先清理残留的 VBoxSVC 进程

请以 skywalk 身份（不要加 sudo）在终端中执行：

复制代码

# 查看是否有残留的 VBoxSVC 进程
pgrep -a VBoxSVC

# 如果有，强制结束它
pkill -9 VBoxSVC

可以执行安装了,但是执行报错vboxdrv 卸载失败

2026-10-21 20:37:48 安装 7.2.12 kmod

2026-10-21 20:38:05 安装 7.2.12 userspace

2026-10-21 20:38:40 卸载内核模块（逆依赖顺序）

2026-10-21 20:38:40 vboxdrv 卸载失败，1 次重试

2026-10-21 20:38:43 vboxdrv 卸载失败，2 次重试

2026-10-21 20:38:46 vboxdrv 卸载失败，3 次重试

2026-10-21 20:38:49 ERROR: vboxdrv 卸载失败

2026-10-21 20:38:49 脚本中止。系统可能处于中间状态，请查看 /root/vbox-712-build/switch-712.log 并按需手动回滚。

这次中止发生在用户态包已替换、但内核模块仍为旧版 的阶段，系统处于典型的"中间状态"。核心原因是 7.2.12 的用户态包安装后，仍有进程（很可能是残留的 VBoxSVC 或 VBoxXPCOMIPCD）持有 /dev/vboxdrv 的设备句柄，导致内核拒绝卸载模块。

🎯 当前系统状态

组件	当前版本	状态
用户态 (`virtualbox-ose-72`)	7.2.12	已替换
内核模块 (`vboxdrv.ko`)	7.2.20（仍在内存中）	未能卸载
虚拟机状态	`poweroff`	正常

此时 VBoxManage 和内核模块版本不匹配，虚拟机无法正常启动。需要手动完成"卸载旧模块 → 加载新模块"这最后一步。

🛠️ 诊断与修复步骤

请以 root 身份在 TTY 中执行以下操作。

第一步：找出谁在占用 `/dev/vboxdrv`

复制代码

fstat /dev/vboxdrv

fstat 会列出所有打开该设备文件的进程。输出中 CMD 列会显示进程名，常见的是 VBoxSVC 或 VBoxXPCOMIPCD。

如果 fstat 没有输出，再用 ps 确认：

复制代码

ps aux | grep -E 'VBoxSVC|VBoxXPCOM|VirtualBox'

第二步：清理残留进程

确认进程名后，以 skywalk 用户身份结束它们（不要用 root ，因为这些进程属于 skywalk）：

复制代码

# 切换到 skywalk 身份清理
su - skywalk -c "pkill -9 VBoxSVC; pkill -9 VBoxXPCOMIPCD; pkill -9 VirtualBox"

清理后，再次确认设备句柄已释放：

复制代码

fstat /dev/vboxdrv
# 应该没有任何输出

第三步：手动卸载旧模块并加载新模块

复制代码

# 按逆依赖顺序卸载（如果某些模块未加载，报错可忽略）
kldunload vboxnetadp
kldunload vboxnetflt
kldunload vboxdrv

# 确认 vboxdrv 已从内核中消失
kldstat | grep vboxdrv   # 应无输出

# 加载刚安装的 7.2.12 新模块
kldload vboxdrv
kldload vboxnetflt
kldload vboxnetadp

# 确认新模块已加载
kldstat | grep vbox

第四步：验证版本对齐

复制代码

su - skywalk -c "VBoxManage --version"
# 应显示 7.2.12

如果显示 7.2.12，说明用户态与内核模块版本已对齐，降级实质上已完成。

📋 后续：锁定版本与启动虚拟机

降级完成后，务必锁定包版本 ，防止下次 pkg upgrade 时被自动升回 7.2.20：

复制代码

pkg lock virtualbox-ose-72 virtualbox-ose-kmod-72

然后以 skywalk 身份启动 win10：

复制代码

su - skywalk -c "DISPLAY=:0 VBoxManage startvm win10"

如果 GUI 启动失败，可以尝试 headless 模式，或登录桌面后手动启动。

🔄 如果上述步骤无效：回滚选项

如果清理进程后 kldunload vboxdrv 仍然报 Device busy ，说明有更深层的占用（例如某个守护进程或内核线程）。此时可以考虑直接重启系统 ------重启会强制清空所有内核模块和残留进程，开机后系统会自动加载 /boot/loader.conf 中指定的 vboxdrv 模块（此时加载的将是 7.2.12 版本，因为磁盘上的 vboxdrv.ko 已被新包替换）。

重启后，直接验证 VBoxManage --version 和 kldstat | grep vbox，确认版本一致后再启动虚拟机。

当前状态是已知的、可恢复的，用户态已就位，只差最后一步内核模块的切换。按上述诊断清理后，通常能顺利完成。

命令启动报错

skywalk@fb98:~ $ fstat /dev/vboxdrv

USER CMD PID FD MOUNT INUM MODE SZ|DV R/W NAME

skywalk@fb98:~ $ ps aux | grep -E 'VBoxSVC|VBoxXPCOM|VirtualBox'

skywalk@fb98:~ $ # 切换到 skywalk 身份清理

skywalk@fb98:~ $ su - skywalk -c "pkill -9 VBoxSVC; pkill -9 VBoxXPCOMIPCD; pkill -9 VirtualBox"

After you compiled and installed a new version of FreeBSD, use etcupdate(8) to merge

configuration updates.

Run "etcupdate extract" once when your sources match your running system, then run

"etcupdate" after every upgrade and "etcupdate resolve" to resolve any conflicts.

-- Lars Engels <lme@FreeBSD.org>

skywalk@fb98:~ $

不过后来还是搞定了

但是命令行启动没起来:skywalk@fb98:~ $ su - skywalk -c "DISPLAY=:0 VBoxManage startvm win10"

To see the last 10 lines of a long file, use "tail filename". To see the

first 10 lines, use "head filename". To see new lines as they're appended

to a file, use "tail -f filename".

-- Dru <genesis@istar.ca>

Waiting for VM "win10" to power on...

VBoxManage: error: The virtual machine 'win10' has terminated unexpectedly during startup with exit code 1 (0x1)

VBoxManage: error: Details: code NS_ERROR_FAILURE (0x80004005), component MachineWrap, interface IMachine

skywalk@fb98:~ $

使用gui启动解决!

为什么启动之后是灰色的呢?

不明白....

启动很慢的问题

第一次启动耗时这么久，确实不太正常。考虑到你刚从 7.2.20 降级到 7.2.12，这很可能不是单纯的"首次启动慢"，而是版本降级后的兼容性磨合 与客户机内部启动阻塞共同导致的。可以从下面几个方面排查：

🖥️ 客户机层面：Windows 内部的"启动阻塞"

这是最常见的"黑屏很久"的原因，尤其对于从快照恢复或版本切换后的 Windows。

Hyper-V 启动失败重试 ：Windows 10 可能每次开机都尝试启动 Hyper-V，但如果 VirtualBox 没有向客户机暴露必要的虚拟化指令（嵌套虚拟化未开启），这个过程会反复失败重试，阻塞系统初始化 20-40 秒甚至更久，期间系统几乎无响应。
- 解决方案 ：在 Win10 客户机内，以管理员身份打开 PowerShell，执行以下命令禁用 Hyper-V 并关闭 hypervisor 启动，然后重启客户机：
  复制代码
```
dism /online /disable-feature /featurename:Microsoft-Hyper-V-All /norestart
bcdedit /set hypervisorlaunchtype off
```
SysMain（超级预取）的 I/O 风暴：这个服务在虚拟机环境中不仅无法有效预取，反而会因为大量不必要的磁盘读写，加剧虚拟磁盘的 I/O 压力，拖慢启动。
- 解决方案 ：在 Win10 客户机内，以管理员身份打开 PowerShell，执行以下命令禁用该服务：
  复制代码
```
Set-Service SysMain -StartupType Disabled
Stop-Service SysMain
```

💾 宿主机与存储层面：I/O 瓶颈与兼容性

快照合并的"后遗症"：你保留了 2 层快照。VirtualBox 在读取数据时，可能需要依次查询多个差异磁盘文件，这会产生额外的 I/O 开销。如果你在删除旧快照时进行了合并操作，这个过程本身也可能很耗时，并可能暂时增加磁盘占用。
- 建议：首次启动完成后，可以在虚拟机关闭状态下，考虑将剩余的 2 层快照也合并掉，以简化磁盘链、提升后续性能。操作前务必备份虚拟机目录。
ZFS ARC 缓存与磁盘空间：虽然你已将 ARC 上限设为 8G，但 ZFS 仍可能利用空闲内存进行缓存，与虚拟机争抢资源。此外，快照合并或虚拟机运行都会占用磁盘空间，如果宿主机磁盘空间紧张，I/O 性能会显著下降。
- 建议：在宿主机终端执行 df -h 检查剩余空间；同时观察 top 或 zpool iostat，看启动时是否有异常的磁盘读写压力。

⚙️ VirtualBox 配置检查

硬件虚拟化与嵌套分页 ：确保虚拟机的"系统"设置中，"启用 VT-x/AMD-V" 和 "启用嵌套分页" 已勾选，这对性能至关重要。
内存与显存 ：你的 18.5GB 内存很充足，但显存（VRAM）建议至少设置为 128MB ，并可以尝试暂时关闭 3D 加速，以排除图形驱动的兼容性问题。

💎 如果仍然极慢：一个终极的验证方案

如果上述调整后启动依然需要 10 分钟以上，问题可能更深层。可以考虑新建一个纯净的 Windows 10 测试虚拟机（不导入任何快照和现有配置）。

如果新建的纯净 VM 启动很快 ，说明问题出在你现有 win10 的快照链或配置文件上，届时可以评估是否重建虚拟机。
如果新建的纯净 VM 也极慢 ，则说明问题可能源于 7.2.12 版本与你的 FreeBSD 系统环境存在更深层的兼容性问题，届时可能需要考虑回滚到 7.2.20 或尝试其他版本。

实践操作

按它说的,禁用hypervisor 启动

复制代码

dism /online /disable-feature /featurename:Microsoft-Hyper-V-All /norestart
bcdedit /set hypervisorlaunchtype off

关闭SysMain

复制代码

Set-Service SysMain -StartupType Disabled
Stop-Service SysMain

Virtualbox 从7.2.20降级到7.2.18 @FreeBSD系统

让AI查找一直崩的问题

准备去做降级到7.2.18

停机后哪些步骤会中断

可行的做法：用 SSH 会话在宿主机上执行

更稳妥的方案：全程无交互脚本

但先别急着做，有两件事必须先确认

我的建议

已完成的部分（未碰 win10）

按你的要求，我没有做最后一步

你要怎么触发

两个必须说清的风险

实践操作

碰到问题

执行报错

最可能的原因：VBoxSVC 残留进程

可以执行安装了,但是执行报错vboxdrv 卸载失败

🎯 当前系统状态

🛠️ 诊断与修复步骤

第一步：找出谁在占用 /dev/vboxdrv

第二步：清理残留进程

第三步：手动卸载旧模块并加载新模块

第四步：验证版本对齐

📋 后续：锁定版本与启动虚拟机

🔄 如果上述步骤无效：回滚选项

命令启动报错

为什么启动之后是灰色的呢?

启动很慢的问题

🖥️ 客户机层面：Windows 内部的"启动阻塞"

💾 宿主机与存储层面：I/O 瓶颈与兼容性

⚙️ VirtualBox 配置检查

💎 如果仍然极慢：一个终极的验证方案

实践操作

第一步：找出谁在占用 `/dev/vboxdrv`