折腾 PVE Home Server：从零到一的血泪史

起因

暑假闲着没事，从小黄鱼上淘了一堆洋垃圾装了一台机子，装上了 Proxmox VE 9.2.0，打算搞一个家庭服务器。


         .://:`              `://:.             root@HomeServer
       `hMMMMMMd/          /dMMMMMMh`           ---------------
        `sMMMMMMMd:      :mMMMMMMMs`            OS: Proxmox VE 9.2.2 x86_64
`-/+oo+/:`.yMMMMMMMh-  -hMMMMMMMy.`:/+oo+/-`    Kernel: Linux 7.0.2-6-pve
`:oooooooo/`-hMMMMMMMyyMMMMMMMh-`/oooooooo:`    Uptime: 20 hours, 14 mins
  `/oooooooo:`:mMMMMMMMMMMMMm:`:oooooooo/`      Packages: 782 (dpkg)
    ./ooooooo+- +NMMMMMMMMN+ -+ooooooo/.        Shell: bash 5.2.37
      .+ooooooo+-`oNMMMMNo`-+ooooooo+.          Display (SyncMaster): 1280x1024 @ 60 Hz in 17"
        -+ooooooo/.`sMMs`./ooooooo+-            Terminal: /dev/pts/0
          :oooooooo/`..`/oooooooo:              CPU: Intel(R) Xeon(R) E5-2690 v4 (28) @ 3.50 GHz
          :oooooooo/`..`/oooooooo:              GPU: AMD Radeon HD 5000/6000/7350/8350 Series [Discrete]
        -+ooooooo/.`sMMs`./ooooooo+-            Memory: 7.80 GiB / 15.45 GiB (50%)
      .+ooooooo+-`oNMMMMNo`-+ooooooo+.          Swap: 379.43 MiB / 8.00 GiB (5%)
    ./ooooooo+- +NMMMMMMMMN+ -+ooooooo/.        Disk (/): 12.26 GiB / 93.93 GiB (13%) - ext4
  `/oooooooo:`:mMMMMMMMMMMMMm:`:oooooooo/`      Disk (/mnt/wd1tb): 2.03 MiB / 408.40 GiB (0%) - ext4
`:oooooooo/`-hMMMMMMMyyMMMMMMMh-`/oooooooo:`    Disk (/mnt/wd1tb/NAS): 106.99 GiB / 491.08 GiB (22%) - ext4
`-/+oo+/:`.yMMMMMMMh-  -hMMMMMMMy.`:/+oo+/-`    Local IP (vmbr0): 192.168.31.**/24
        `sMMMMMMMm:      :dMMMMMMMs`            Locale: en_US.UTF-8
       `hMMMMMMd/          /dMMMMMMh`
         `://:`              `://:`

本来以为装个系统、配个网络、建个虚拟机是半小时的事，结果前前后后折腾了快一天——这篇文章就是记录这段经历，顺便帮自己长个记性。

第一步：IPv6 配置

家里的网络是联通宽带，光猫负责分配 IPv6，小米路由器开的 passthrough 模式。PVE 装好之后发现只有 IPv4，没有 IPv6。

查了一下，问题出在 PVE 的桥接接口 vmbr0 上——accept_ra=1 在桥接模式下不生效，必须改成 2。加上 iface vmbr0 inet6 dhcp，重启网络后立刻拿到了联通前缀 2408:8266:401:10af::/64 的公网 IPv6。

这一步没什么波折，算是热身。

第二步：挂载硬盘 + SMB 共享

新插了一块西数 1TB 的 SATA 盘（WD10EADX，5400rpm 的老绿盘），分了两个区：

416GB 挂载到 /mnt/wd1tb，给 PVE 做存储池
500GB 挂载到 /mnt/wd1tb/NAS，做 SMB 共享

Samba 配置很顺利，创建了用户 jay，加了 CIFS 存储到 PVE。从 Windows 资源管理器直接 \\*****\NAS 就能访问，SMB3.11 协议，传输速度大概 25MB/s——受限于那块 5400rpm 的绿盘，算正常。

第三步：直通物理硬盘创建虚拟机（噩梦开始）

我有一块 300GB 的 SATA 盘（HITACHI），上面装好了 Ubuntu 22.04，想直通进 PVE 虚拟机当系统盘。听起来简单对吧？用 qm create 建个 VM，把盘用 by-id 路径挂上去就行。

然后一切就开始崩了。

问题一：启动黑屏

VM 建好后启动，GRUB 菜单能出来，选 Ubuntu 之后直接黑屏。

排查发现是 initramfs 里没有 virtio-scsi 驱动。物理机用的是 AHCI 控制器，备份恢复到虚拟机后，内核找不到 virtio-scsi 的根分区。

解决：从 PVE 宿主机挂载磁盘，chroot 进去跑 update-initramfs -u，把 virtio_scsi、virtio_blk 等模块加入 /etc/initramfs-tools/modules。

问题二：VGA 驱动报错

initramfs 修好后，系统能启动了，但卡在某个地方不动。通过串口控制台（PVE 的 serial0: socket + socat）抓到关键报错：

vmwgfx *ERROR* vmwgfx seems to be running on an unsupported hypervisor

VM 的 VGA 设置的是 vmware，但 vmwgfx 驱动检测到在 KVM 上跑，直接报错卡死。

解决：qm set 100 --vga virtio，换成 virtio-gpu。

问题三：systemd 循环依赖

系统能启动了，但每次都在 emergency mode 卡住。通过串口登录后查 systemctl --failed，发现 ufw、samba 等一堆服务全挂了。

根本原因：Python 3.10 环境损坏。init_fs_encoding 报错，所有依赖 Python 的服务都启动失败。而 grub-initrd-fallback.service 造成了 systemd 的循环依赖，导致系统直接进 emergency mode。

解决过程极其曲折：

mask 掉 grub-initrd-fallback.service、ufw.service、snapd 等
从宿主机 chroot 进去 apt-get install --reinstall python3.10 python3.10-minimal libpython3.10-stdlib libpython3.10-minimal
还要处理 update-manager 和 update-notifier 之间的依赖冲突（apt --fix-broken）

问题四：文件系统损坏

反复 mount/umount 和强制重启后，ext4 文件系统出现了大量块计数错误和 inode 位图差异。系统卡在 journald 的 I/O error 上。

解决：从宿主机 e2fsck -y /dev/sda3，修了一大堆错误。

问题五：EFI 分区 UUID 不匹配

备份恢复后，EFI 分区的 UUID 变了（从 B5F8-CA14 变成 1309-E8C1），但 fstab 里还写的是旧 UUID。系统每次启动都等 90 秒尝试挂载一个不存在的分区。

解决：从 fstab 里删掉 EFI 条目。

问题六：MAC 地址搞混

这是我犯的最蠢的错误。在排查网络问题时，我在 tcpdump 抓到了一个 MAC 地址 58:EA:1F:EA:5C:18，以为是虚拟机的，就把 VM 的网卡 MAC 改成了这个。结果这个 MAC 是我家 mesh 路由器 的，导致 MAC 地址冲突，VM 的所有网络通信全部混乱。

解决：改回 PVE 自动分配的 MAC。

最终状态

经过这些折腾，VM 终于稳定运行：

项目	值
系统	Ubuntu 22.04 (Debian 13 trixie 内核)
CPU/内存	8 核 / 6GB
IPv4	192.168.31.**（静态）
IPv6	2408:8266::::/64（公网）
系统盘	HITACHI 300GB SATA 直通 (by-id)
启动模式	OVMF (UEFI) + virtio-scsi

教训

virtio 驱动必须提前装好。从物理机迁移到虚拟机之前，先在物理机上把 virtio 模块加到 initramfs 里。
善用串口控制台。PVE 的 serial0: socket 配合 socat 是调试 VM 启动问题的利器。VGA 黑屏时，串口能看到所有内核输出。
MAC 地址要确认来源。在共享网络环境中抓包，一定要确认 MAC 属于哪个设备，不要想当然。
文件系统要勤 fsck。反复强制重启后，ext4 会积累错误。及时 e2fsck 比等系统崩溃好。
fstab 里的 UUID 要跟实际对上。备份恢复、分区操作后 UUID 可能变化，一定要检查。
Python 环境坏了会连锁影响一切。Ubuntu 22.04 上 ufw、samba、NetworkManager 等服务都依赖 Python。Python 挂了等于整个系统半瘫痪。
耐心。这种问题排查没有捷径，只能一步步看日志、试方案、排除原因。急了反而会犯更多错（比如改错 MAC）。