Ubuntu执行vagrant up报VirtualBox故障、无法确定当前runlevel错误

你漏了最关键的环境识别：从DKMS编译输出的It is likely that 5.10.16.3-microsoft-standard-WSL2 belongs to a chroot's host可以明确判断，你当前操作的环境是WSL2（Windows Linux子系统），不是原生安装的Ubuntu。
WSL2是微软提供的轻量化Linux兼容层，默认不支持加载自定义内核模块，你之前反复重装virtualbox-dkms、重编译VirtualBox内核模块的操作全是无效操作——WSL2根本没有权限创建/dev/vboxdrv这个VirtualBox运行必须的字符设备，不管重装多少次包都不可能解决问题。
你看到的invoke-rc.d: could not determine current runlevel报错也是WSL2的特有现象：WSL2默认不使用传统SysVinit的运行级机制，服务管理脚本识别不到运行级是正常情况，和VirtualBox安装包损坏没有关系。

根据你的实际使用场景三选一即可：

• 方案1（适配原有Vagrant+VirtualBox使用习惯，推荐）：不要在WSL内部安装VirtualBox，直接在Windows宿主机上安装和你WSL内Vagrant版本匹配的VirtualBox，配置WSL内的Vagrant调用Windows端的VirtualBox服务即可，原有Vagrantfile配置不需要改动。
• 方案2（全在WSL内操作，不需要装Windows端软件）：更换Vagrant的provider，放弃VirtualBox，改用Docker或者WSL2原生作为Vagrant的运行后端，这两种provider不需要加载内核模块，在WSL2内可以直接运行。
• 方案3（坚持在Ubuntu内用VirtualBox）：放弃WSL环境，在物理机或者全虚拟化平台（VMware、Hyper-V）上安装完整的原生Ubuntu系统，安装完对应内核头文件、virtualbox-dkms包之后，执行sudo modprobe vboxdrv手动加载内核模块，确认/dev/vboxdrv设备存在后，vagrant up就能正常运行。

如果后续在原生Ubuntu上遇到同类问题，重编译DKMS模块之后一定要手动执行modprobe vboxdrv加载驱动，不要等系统自动加载，很多时候模块编译成功但没加载，一样会报找不到设备的错误。

内容的提问来源于stack exchange，提问作者marily