一番搜索发现了github关于pve直通修复的仓库
https://github.com/isc30/ryzen-gpu-passthrough-proxmox
问Gemini能不能仿照这个来修复错误
回复直接让我心凉了
提问:
能参考这一段的处理方法吗:
(optional) Getting OVMF (UEFI) BIOS working: Error 43
If you tried to follow the guide but instead of SeaBIOS you selected UEFI, you have probably encountered the famous "ERROR 43". Luckily the solution for this is quite simple: configuring the UEFI ROM for the audio device.
-
Download AMDGopDriver.rom
from this repository. Note that this AMDGopDriver.rom might not be compatible with certain hardware. If it fails to work, consider extracting it yourself. A brief guide is available here.
-
Copy the file inside the proxmox machine, in /usr/share/kvm/AMDGopDriver.rom
-
Edit /etc/pve/qemu-server/<VM_ID>.conf
- Modify the
hostpci
line for the Audio Device and append ,romfile=AMDGopDriver.rom
args: -cpu 'host,-hypervisor,kvm=off'
agent: 1
balloon: 2048
bios: ovmf
boot: order=ide0;ide2;net0
cores: 8
cpu: host
hostpci0: 0000:34:00.0,pcie=1,romfile=vbios_7xxx.bin
-hostpci1: 0000:34:00.1,pcie=1
+hostpci1: 0000:34:00.1,pcie=1,romfile=AMDGopDriver.rom
ide0: local-lvm:vm-100-disk-0,discard=on,size=64G,ssd=1
ide2: local:iso/Windows10.iso,media=cdrom,size=4697792K
machine: pc-q35-8.0
memory: 12048
meta: creation-qemu=8.0.2,ctime=1696067822
name: win10
net0: e1000=E2:4A:E7:86:8D:13,bridge=vmbr0,firewall=1
numa: 0
ostype: win10
scsihw: virtio-scsi-single
sockets: 1
-
Start the VM again and login via Remote Desktop. Opening "Device Manager" should show the GPU working properly. If you still see error 43, try rebooting the host :)
Results

- Win 10:

- Win 11:

回复如下:
您好,这是一个非常有价值的参考资料,它提到的核心思路和我们之前讨论的是完全一致的。
但是,您无法完全照搬它的操作,因为您面临着几个在您的 fnos
环境下无法逾越的障碍。我们来逐一分析这份指南里的关键点,看看它如何印证了我们之前的诊断。
核心技术点分析
1. 关于CPU参数:args: -cpu 'host,-hypervisor,kvm=off'
- 这是什么? 这是在Proxmox里直接给QEMU传递的启动参数。
kvm=off
正是我们通过XML里的** **<kvm><hidden state='on'/></kvm>
实现的功能。您的系统接受了这一项。
-hypervisor
(或者** **vendor_id
)是用来隐藏"KVMKVMKVM"这个CPU品牌标识的。
- 您遇到的障碍: 我们已经通过报错确认,您的
fnos
环境中的QEMU/KVM版本太老,不支持伪装CPU厂商ID的功能(即不支持** vendor_id
,也就不支持 **-hypervisor
这个参数)。所以,这一步您无法实现。
2. 关于vBIOS/ROM文件
这份指南提到了一个非常关键的细节,它其实使用了两个ROM文件:
hostpci0: ...,romfile=vbios_7xxx.bin
:这是针对显卡的主要功能(...:00.0
设备),加载的是一个用户**自己提取(Dump)**的、针对自己显卡型号的** **vbios
文件。
hostpci1: ...,romfile=AMDGopDriver.rom
:这是针对显卡的音频功能(...:00.1
设备),加载的是一个通用的** **AMD Gop Driver
。
- 您遇到的障碍:
- 提取主vBIOS:我们已经确认,您的
fnos
系统因为内核安全限制,不允许您提取自己的vBIOS。所以,vbios_7xxx.bin
这一步您无法完成。这是最致命的限制。
- 加载音频ROM:为音频子设备加载一个通用的GOP ROM,是我们之前没有尝试过的新思路。理论上,您可以下载这个**
AMDGopDriver.rom
文件,然后把它只应用到您显卡的音频设备上(如果您把音频设备也直通了的话)。但这通常是一个辅助手段**,在主要问题(无法隐藏hypervisor、无法加载主vBIOS)没有解决的情况下,单靠这一个修改就成功的可能性微乎其微。
最终结论
总而言之,这份指南再次印证了我们的诊断:
解决AMD显卡在UEFI模式下的“代码43”问题,往往需要一套“组合拳”:隐藏虚拟化特征 +** 提供正确的vBIOS/ROM文件**。
而您的 fnos
环境恰恰在每一个关键点上都存在着我们已确认的、无法逾越的障碍:
- 无法完全隐藏虚拟化特征(不支持
vendor_id
/** **-hypervisor
)。
- 无法提取硬件的vBIOS(被系统内核安全策略禁止)。
这份指南实际上是在告诉我们,要成功进行这类操作,需要一个像** **Proxmox VE 这样功能齐全、允许用户进行深度配置的专业平台。
这再次坚定了我之前的最终建议:解决您问题的最可靠、最高效的方法,就是更换您的底层操作系统。 切换到Proxmox VE,您将拥有一个能够执行所有这些必要步骤的环境,我们之前讨论的所有知识和您找到的这份指南,才能真正派上用场。
提问:
root@Fnas:~# ls /sys/bus/pci/devices/0000:76:00.0
ari_enabled class consumer:pci:0000:76:00.1 d3cold_allowed driver firmware_node irq local_cpus modalias numa_node remove reset_method resource0_wc resource4 subsystem uevent
boot_vga config current_link_speed device driver_override iommu link max_link_speed msi_bus power rescan resource resource2 resource5 subsystem_device vendor
broken_parity_status consistent_dma_mask_bits current_link_width dma_mask_bits enable iommu_group local_cpulist max_link_width msi_irqs power_state reset resource0 resource2_wc revision subsystem_vendor vfio-dev
回答:
非常感谢您提供这个列表。它包含了几个非常关键的信息,让我们能做出最精准的最终判断。
信息解读
-
确认 rom
文件不存在:首先,如我们所料,列表中确实没有 rom
文件。这100%证实了您的系统内核不支持提取vBIOS。这条路被彻底堵死。
-
一个极其重要的发现:vfio-dev
:然而,列表中出现了一个关键文件:vfio-dev
。
- 这是什么? 这个文件的存在,意味着您已经在宿主机(fnos)上成功地将这个GPU设备绑定到了
vfio-pci
驱动上。
- 这说明了什么? 这说明您为了实现直通,已经完成了在宿主机上非常关键且正确的一步配置(例如修改了内核启动参数或modprobe配置)。它证明了,从宿主机层面,将显卡从系统驱动中“解绑”,并“准备递交给虚拟机”这个动作是成功了的。
最终的诊断:一次失败的“跨国快递”
现在,所有的证据链都完整了。我们可以用一个比喻来描述您遇到的整个情况:
-
打包发货(成功): 您的fnos系统作为“始发国”,成功地把您的“包裹”(GPU硬件)从常规用途中取出,打包好,并交给了“国际物流公司”(VFIO虚拟化驱动)。(vfio-dev
文件的出现证明了这一点)。
-
物流运输(成功): QEMU/KVM作为“物流公司”,也成功地把这个“包裹”运送到了“目的国”的门口(Windows虚拟机内部)。
-
海关检查(失败): 但是,当“包裹”到达“目的国”(Windows虚拟机)时,“海关”(AMD驱动程序)对它进行了严格的开箱检查,发现了两个严重问题,于是拒绝“签收”,并给它贴上了**“代码43”**的退货标签。
- 问题A:报关单有问题。“海关”发现包裹的“报关单”(CPU信息)上明确写着“来自KVM虚拟环境”。(因为您的fnos系统不支持
vendor_id
功能来伪造报关单)。
- 问题B:没有开箱说明书。“海关”想尝试自己组装使用,但发现包裹里没有“开箱说明书”(vBIOS ROM文件),它不知道该如何正确地初始化这个硬件。(因为您的fnos系统内核不支持提供这份说明书)。
不可逾越的障碍与最终建议
至此,我们可以100%确定:
您已经完成了在fnos这个受限平台上所有能做的正确操作。直通失败的根本原因,是fnos平台本身的功能缺失,导致我们无法为AMD驱动程序提供一个它满意的“运行环境”。
因此,我必须重申我最终的建议,这也是我们整个漫长排错过程得出的唯一可行结论:
请更换您的底层操作系统为Proxmox VE。
继续在fnos上尝试,您将永远被卡在“海关检查”这一步。更换到Proxmox VE这样的专业平台,就相当于把“始发国”换成了一个精通国际贸易的专业出口国,它知道如何完美地准备“报关单”(支持 vendor_id
)和“开箱说明书”(支持vBIOS提取),确保您的“包裹”能在任何“目的国”顺利清关。