Upgrade PVE 9 — lessons learned (SP)

Upgrade PVE 8→9: Lessons Learned — Cluster SP (2026-04-13/14)

Resumo

Upgrade de 3 nodes SP (pve-ippri-31, 32, 33) de Proxmox VE 8.4 (Debian 12 Bookworm) para PVE 9.1.7 (Debian 13 Trixie, kernel 6.17.13-2-pve).

ippri-33: upgrade limpo, sem problemas graves. ippri-31: transicao t64 quebrou dezenas de pacotes desktop, resolvido iterativamente. ippri-32: o mais problemático — rede caiu pos-reboot, QEMU quebrado, ifupdown2 quebrado, libs Ceph duplicadas. Detalhamento completo abaixo.

ippri-33 — Upgrade limpo

Sequencia padrao funcionou:

cleanup-boot.sh
sed bookworm→trixie nos repos
apt full-upgrade (demorou ~35min com ~2369 pacotes)
Reboot
Validacao: PVE 9.1.7, kernel 6.17, NVIDIA 580.126, CUDA 13.0

Unico problema: pos-reboot ficou ~2min sem pingar (boot lento, nao interface renomeada). Voltou sozinho.

ippri-31 — Transicao t64 problemática

Problema principal

O apt full-upgrade completou o download mas falhou na fase de configure. A transicao t64 do Debian 13 (renomeacao de libs como libglib2.0-0 → libglib2.0-0t64) criou cadeia circular de dependencias com pacotes desktop (GNOME, LibreOffice, VLC, Qt5, Samba, Python).

Sequencia de resolucao

apt full-upgrade — falhou com dependencias t64
Purgamos LibreOffice (dpkg --purge --force-depends libreoffice*) — removeu maior bloqueador
Iteramos purgando pacotes que bloqueavam: VLC, wireshark, uim, rhythmbox, rygel, tracker, samba, shotwell, seahorse, xscreensaver, python3-numpy, python3-lib2to3, python3-pyside2, ubertooth
dpkg -i /var/cache/apt/archives/*.deb (abordagem nuclear) — instalou ~2900 pacotes de uma vez
Multiplas passadas de dpkg --configure -a --force-all
Kernel 6.17 instalado manualmente: dpkg --force-all -i proxmox-kernel-6.17*.deb
Reboot

Estado pos-reboot

PVE 9.1.7, kernel 6.17 ✓
Servicos pveproxy/pvedaemon/pvestatd falharam (rate limit de restart) — resolvido com systemctl reset-failed && systemctl restart
~2900 pacotes com “falta ficheiro de lista” no dpkg audit (cosmético, funcional)
4 pacotes com postinst pendente (openssh-server, samba-common, grub-efi-amd64, gdm3) — exit code 10 (debconf), funcional

ippri-32 — Detalhamento completo (o mais problemático)

Cronologia

Fase 1: Preparacao (funcional)

Limpeza /boot: 48% → OK
Purga preventiva do LibreOffice: dpkg --purge --force-depends $(dpkg -l "libreoffice*") — removeu antes do upgrade pra evitar transicao t64
Purga residuos: gnome, liblibreofficekitgtk, mythes-pl, python3-uno, gir1.2-lokdocview-0.1
Repos atualizados bookworm→trixie, apt update OK (2559 pacotes)

Fase 2: apt full-upgrade — falhou

O primeiro apt full-upgrade falhou porque residuos do LibreOffice (metapacote gnome depende de libreoffice-writer). Apos purgar residuos, o upgrade iniciou mas foi cortado por timeout na conexao SSH.

Fase 3: Recuperacao via dpkg -i *.deb

Com o apt travado em dependencias, usamos a abordagem nuclear:

cd /var/cache/apt/archives
dpkg --force-depends --force-overwrite --force-confold -i *.deb

Instalou ~2500 pacotes de uma vez. Muitos falharam no configure (esperado).

Fase 4: python3-numpy symlink

Problema: python3-numpy nao instalava porque /usr/lib/python3/dist-packages/numpy/f2py/src era diretório mas o pacote novo queria converter pra symlink. Solucao:

rm -rf /usr/lib/python3/dist-packages/numpy/f2py/src

Mesmo fix necessário para /usr/share/doc/cpp.

Fase 5: Kernel 6.17 instalado manualmente

O kernel PVE 9 nao foi instalado pelo apt (dependencias bloquearam). Instalacao manual:

dpkg --force-all -i /var/cache/apt/archives/proxmox-kernel-6.17.13-2-pve-signed_6.17.13-2_amd64.deb

GRUB atualizado automaticamente.

Fase 6: Reboot — rede caiu

Apos reboot, o node bootou (kernel 6.17.13-2-pve confirmado no console local) mas todas as interfaces de rede estavam DOWN. Nenhum bridge (vmbr) foi criado.

Causa raiz: ifupdown2 dependia de python3-systemd que nao estava configurado. O systemctl restart networking falhou silenciosamente.

Diagnostico no console:

ip -br link          # tudo DOWN exceto lo
ip -br addr          # nenhum IP
systemctl status networking   # falhou

Resolucao manual da rede (no console local):

# Encontrar interface com cabo conectado
for i in enp8s0 enp9s0 enp6s0f0 enp5s0f0 enp5s0f1 enp6s0f1; do
  ip link set $i up 2>/dev/null
done
sleep 2
for i in enp8s0 enp9s0 enp6s0f0 enp5s0f0 enp5s0f1 enp6s0f1; do
  echo "$i: $(cat /sys/class/net/$i/carrier 2>/dev/null)"
done
# enp9s0: 1  ← cabo conectado aqui

# Criar bridge e VLAN manualmente
ip link add vmbr1 type bridge
ip link set enp9s0 master vmbr1
ip link set enp9s0 up
ip link set vmbr1 up
ip link add link vmbr1 name vmbr1.192 type vlan id 192
ip link set vmbr1.192 up
ip addr add 192.168.10.32/23 dev vmbr1.192
ip route add default via 192.168.10.5

Nota: tentamos bridge vlan add dev enp9s0 vid 192 mas falhou com “Operation not supported” porque o bridge foi criado sem vlan_filtering. A solucao foi criar a sub-interface VLAN diretamente no bridge.

Fase 7: QEMU quebrado — symbol lookup error

Ao tentar iniciar a VM pfsense-bkp (5002), o QEMU falhava:

/usr/bin/kvm: symbol lookup error: /usr/bin/kvm: undefined symbol: rbd_encryption_load2
TASK ERROR: Detected old QEMU binary (unknown, at least 6.0 is required)

Diagnostico:

dpkg -l pve-qemu-kvm mostrava versao 8.1.5 (PVE 8) — o dpkg -i *.deb instalou a versao antiga do cache
Atualizamos para 10.1.2 copiando .deb do ippri-33: scp root@192.168.10.33:/root/pve-qemu-kvm_10.1.2-7_amd64.deb /tmp/ && dpkg --force-all -i /tmp/pve-qemu-kvm*.deb
Mesmo com QEMU 10.1.2, o erro persistiu

Causa raiz: libs Ceph (librbd) duplicadas em caminhos diferentes:

/lib/librbd.so.1           → librbd.so.1.19.0  (nova, com rbd_encryption_load2)
/lib/x86_64-linux-gnu/librbd.so.1 → librbd.so.1.16.0  (antiga, sem o simbolo)

O linker carregava a antiga (/lib/x86_64-linux-gnu/ tem precedencia no ldconfig padrao).

Prova: LD_LIBRARY_PATH=/lib /usr/bin/kvm --version funcionou.

Solucao:

rm -f /lib/x86_64-linux-gnu/librbd.so*
rm -f /lib/x86_64-linux-gnu/librados.so*
rm -f /lib/x86_64-linux-gnu/libcephfs.so*
ldconfig
/usr/bin/kvm --version  # QEMU 10.1.2 ✓

Fase 8: ifupdown2 quebrado (python modules)

Com internet restaurada, corrigimos o ifupdown2:

apt install -y python3-systemd        # modulo systemd para ifupdown2
apt install -y --reinstall python3-setuptools  # setuptools faltava
apt install -y python3-packaging       # dependencia do setuptools
apt install -y --reinstall python3-jaraco.text python3-jaraco.functools python3-jaraco.context
ifreload -a                            # agora funciona

Fase 9: Restaurar /etc/network/interfaces

O arquivo original foi renomeado para .bak durante debug. Restaurado:

cp /etc/network/interfaces.bak /etc/network/interfaces

Fase 10: v4l2loopback-dkms removido

O modulo v4l2loopback (webcam virtual) nao compila no kernel 6.17 e bloqueava apt install -f. Removido:

apt purge -y v4l2loopback-dkms

Nao critico — modulo de webcam virtual nao usado em servidor.

Estado final ippri-32

PVE 9.1.7 ✅
Kernel 6.17.13-2-pve ✅
QEMU 10.1.2 ✅
Rede: vmbr1.192 com 192.168.10.32/23 ✅
GDM/GNOME: active ✅
Servicos PVE: todos active ✅
VM pfsense-bkp (5002): migrada para ippri-33, rodando ✅
Audit: ~4168 pacotes sem .list (cosmético, funcional)

Problemas recorrentes e solucoes

1. Transicao t64 (Debian 12→13)

O que e: Debian 13 renomeia libs com time_t de 32→64 bits (ex: libglib2.0-0 → libglib2.0-0t64). Pacotes que dependem das versoes antigas ficam quebrados.

Solucao: Purgar pacotes desktop que bloqueiam ANTES do upgrade (LibreOffice, VLC, uim). Reinstalar depois.

2. python3-numpy symlink

O que e: numpy novo quer converter diretório f2py/src em symlink, mas o diretório existe.

Solucao: rm -rf /usr/lib/python3/dist-packages/numpy/f2py/src

3. Libs duplicadas em /lib/ vs /lib/x86_64-linux-gnu/

O que e: PVE 9 instala libs em /lib/, Debian 12 usava /lib/x86_64-linux-gnu/. Se ambas existem, o linker pode carregar a antiga.

Diagnostico: ldd /usr/bin/kvm | grep librbd — comparar caminhos entre node funcional e quebrado.

Solucao: Remover as libs antigas em /lib/x86_64-linux-gnu/ e rodar ldconfig.

4. ifupdown2 dependencias Python

O que e: ifupdown2 depende de python3-systemd, python3-setuptools, python3-packaging, python3-jaraco.*. Se qualquer um estiver quebrado, ifreload -a falha e a rede nao sobe no boot.

Solucao: Reinstalar toda a cadeia:

apt install -y --reinstall python3-systemd python3-setuptools python3-packaging \
  python3-jaraco.text python3-jaraco.functools python3-jaraco.context

5. Servicos PVE falham no boot

O que e: pveproxy, pvedaemon, pvestatd falham no primeiro boot pos-upgrade e atingem o rate limit de restart do systemd.

Solucao:

systemctl reset-failed pveproxy pvedaemon pvestatd
systemctl restart pveproxy pvedaemon pvestatd

6. Gateway circular (pfsense na mesma maquina)

O que e: Se o gateway da rede e uma VM no proprio node, apos reboot a VM esta desligada e o node nao tem internet pra resolver pacotes.

Prevencao: Migrar a VM gateway para outro node ANTES do upgrade. Ou garantir que a rede sobe sem internet (configs locais).

ippri-32 — Problemas pos-reboot (detalhamento extra)

Rede: bridges nao sobem no boot

Sintoma: Apos reboot, todas as interfaces DOWN, nenhum bridge (vmbr) criado, sem IP.

Causa: ifupdown2 depende de modulos Python (python3-systemd, python3-setuptools, python3-packaging, python3-jaraco.*) que ficaram quebrados apos o dpkg -i *.deb em massa. O systemctl restart networking falhava silenciosamente.

Diagnostico:

ip -br link              # tudo DOWN
ifreload -a              # ModuleNotFoundError: No module named 'systemd'

Resolucao manual da rede (quando ifupdown2 nao funciona):

# 1. Encontrar interface com cabo
for i in enp8s0 enp9s0 enp6s0f0 enp5s0f0 enp5s0f1 enp6s0f1; do
  ip link set $i up 2>/dev/null
done
sleep 2
for i in enp8s0 enp9s0 enp6s0f0 enp5s0f0 enp5s0f1 enp6s0f1; do
  echo "$i: $(cat /sys/class/net/$i/carrier 2>/dev/null)"
done

# 2. Criar bridge + VLAN manualmente (exemplo VLAN 192)
ip link add vmbr1 type bridge
ip link set enp9s0 master vmbr1
ip link set enp9s0 up
ip link set vmbr1 up
ip link add link vmbr1 name vmbr1.192 type vlan id 192
ip link set vmbr1.192 up
ip addr add 192.168.10.32/23 dev vmbr1.192
ip route add default via 192.168.10.5

Nota: bridge vlan add falha com “Operation not supported” se o bridge nao foi criado com vlan_filtering. A alternativa e criar sub-interface VLAN diretamente no bridge.

Resolucao definitiva (com internet restaurada):

apt install -y --reinstall python3-systemd python3-setuptools python3-packaging \
  python3-jaraco.text python3-jaraco.functools python3-jaraco.context
ifreload -a    # agora funciona

Gateway circular: pfsense na mesma maquina

Sintoma: Node sem internet apos reboot porque o gateway (192.168.10.5) e uma VM que roda nesse mesmo node.

Solucao: Migrar a VM gateway para outro node ANTES do upgrade. Neste caso, a VM pfsense-bkp (5002) foi migrada para ippri-33 antes do reboot e a rede SP ficou operacional.

QEMU: symbol lookup error (libs Ceph duplicadas)

Sintoma:

/usr/bin/kvm: symbol lookup error: undefined symbol: rbd_encryption_load2
TASK ERROR: Detected old QEMU binary (unknown, at least 6.0 is required)

Causa: O dpkg -i *.deb instalou libs novas em /lib/ mas deixou as antigas em /lib/x86_64-linux-gnu/. O linker dinamico carrega a antiga primeiro.

Diagnostico:

# Comparar paths entre node funcional e quebrado
ldd /usr/bin/kvm | grep librbd
# Quebrado:  /lib/x86_64-linux-gnu/librbd.so.1

# Confirmar com LD_LIBRARY_PATH
LD_LIBRARY_PATH=/lib /usr/bin/kvm --version   # funciona!

Solucao:

rm -f /lib/x86_64-linux-gnu/librbd.so*
rm -f /lib/x86_64-linux-gnu/librados.so*
rm -f /lib/x86_64-linux-gnu/libcephfs.so*
ldconfig

GPU: GTX 750 Ti — driver correto e 580.xx

Contexto: O ippri-32 tem uma GTX 750 Ti (GM107, Maxwell) — GPU antiga usada apenas para video/monitor, nao para IA.

Drivers testados:

Driver	Resultado
595.58.03 (latest)	“GPU supported through NVIDIA 580.xx Legacy drivers” — ignora a GPU
535.247.01 (legacy)	Nao compila no kernel 6.17 (API incompativel)
580.126.09 (legacy correto)	Funciona ✅
nouveau (open source)	Carrega mas Xorg nao detecta monitor (“no screens found”)

O Xorg log indica o driver correto:

NVIDIA(0): The NVIDIA GeForce GTX 750 Ti GPU installed in this system
            is supported through the NVIDIA 580.xx Legacy drivers.

Instalacao:

systemctl stop gdm3
wget https://download.nvidia.com/XFree86/Linux-x86_64/580.126.09/NVIDIA-Linux-x86_64-580.126.09.run
chmod +x NVIDIA-Linux-x86_64-580.126.09.run
./NVIDIA-Linux-x86_64-580.126.09.run --silent --dkms --disable-nouveau --no-questions --install-libglvnd --no-x-check
systemctl start gdm3

GNOME Shell crash: “Oh nao! Alguma coisa esta errada”

Sintoma: Tela mostra mensagem de erro do GNOME apos login. Driver funciona (tela aparece), mas sessao desktop crasha.

Causa: Schema gsettings-desktop-schemas desatualizado. O GNOME 48 precisa de chaves novas (accent-color) que o schema antigo nao tem.

Diagnostico (no journal):

gnome-shell: Settings schema 'org.gnome.desktop.interface' does not contain a key named 'accent-color'

Solucao:

apt install -y --reinstall gsettings-desktop-schemas gnome-settings-daemon
glib-compile-schemas /usr/share/glib-2.0/schemas/
systemctl restart gdm3

Recomendacoes para proximos upgrades

Purgar LibreOffice ANTES do apt full-upgrade — maior causador de problemas t64
Remover v4l2loopback-dkms antes — bloqueia dpkg no kernel 6.17
Migrar VMs gateway para outro node antes do reboot
Ter acesso console (IPMI/fisico) — SSH pode cair apos reboot
Verificar libs duplicadas apos upgrade: find /lib/x86_64-linux-gnu/ -name "*.so.*" | head
Reinstalar cadeia ifupdown2 apos upgrade: python3-systemd, setuptools, packaging, jaraco.*
Usar dpkg -i *.deb como fallback quando apt trava em dependencias circulares
Nao confiar no ifreload apos upgrade sem verificar modulos Python