Meine Erfahrungen beim PVE 6 zu 7 Upgrade

[Dunuin]

Moin,

Ich hatte da einige Probleme beim Upgrade von PVE6 auf PVE7 die sich scheinbar lösen ließen, daher dachte ich mir ich teile die mal hier, falls jemand die gleichen Probleme hat:

1.) Grub konnte nicht auf die Systemplatten geschrieben werden
Wichtig wäre hier wohl zu nennen, dass da mein PVE6.4 über ein Debian Buster installiert war mit dem CSM aktiv, dass da mein UEFI das PVE immer über Grub gebootet hat. Proxmox-boot-tool gab es damals auch noch nicht, da mein PVE ursprüglich als PVE6.2 installiert wurde. Auf das Proxmox-boot-tool konnte ich wohl auch nicht vorher wechseln, da ich dort eine freie 512 MB Partition gehabt haben müsste und ich damals nur eine 286 MB Partition für ESP eingeplant hatte. Ein update-grub hatte damals mit PVE6 noch wunderbar funktioniert und ich konnte problemlos den grub Bootloader auf die beiden System-SSDs, sda und sdb, schreiben.
Während des apt dist-upgrade von PVE 6 auf 7 sollte nun aber der neue Bootloader geschrieben werden und dies ist immer mit folgendem Fehler fehlgeschlagen:

grub-install.real: warning: this GPT partition label contains no BIOS Boot Partition; embedding won't be possible.
grub-install.real: error: embedding is not possible, but this is required for RAID and LVM install.

Meine Systempartitionen sahen so aus:

root@Hypervisor:/boot/grub# lsblk
NAME                              MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda                                 8:0    0  93.2G  0 disk
├─sda1                              8:1    0     1M  0 part
├─sda2                              8:2    0   286M  0 part
├─sda3                              8:3    0   488M  0 part
│ └─md0                             9:0    0   487M  0 raid1 /boot
└─sda4                              8:4    0  92.4G  0 part
  └─md1                             9:1    0  92.3G  0 raid1
    └─md1_crypt                   253:0    0  92.3G  0 crypt
      ├─vgpmx-lvroot              253:1    0    21G  0 lvm   /
      └─vgpmx-lvswap              253:2    0    61G  0 lvm   [SWAP]
sdb                                 8:16   0  93.2G  0 disk
├─sdb1                              8:17   0     1M  0 part
├─sdb2                              8:18   0   286M  0 part  /boot/efi
├─sdb3                              8:19   0   488M  0 part
│ └─md0                             9:0    0   487M  0 raid1 /boot
└─sdb4                              8:20   0  92.4G  0 part
  └─md1                             9:1    0  92.3G  0 raid1
    └─md1_crypt                   253:0    0  92.3G  0 crypt
      ├─vgpmx-lvroot              253:1    0    21G  0 lvm   /
      └─vgpmx-lvswap              253:2    0    61G  0 lvm   [SWAP]

Sda1 und sdb1 waren dabei bisher für den Bootloader benutzt und hatte das Boot-Flag gesetzt. Die neue Version von "grub-pc" wollte diese aber nicht mehr als Boot-Partitionen anerkennen. Wichtig ist den Rechner blos nicht zu rebooten, bevor man einen lauffähigen Bootloader installiert hat. Da war ich dann also etwas in Panik...
Lösung war bei den beiden Boot-Partitionen das Boot-Flag zu entfernen und den Partitionstyp auf "bios_grub" zu ändern. Dies geht für die Partition sda1 z.B. über folgende Eingaben:

parted /dev/sda
set 1 boot off
set 1 bios_grub on
q

Danach konnte ich dann mit update-grub korrekt den Bootloader auf die System-SSDs schreiben.

2.) VM mit HDD pseudo-passtrough über "qm set" wollte nicht mehr starten
Hier hat sich wohl irgendwas getan. Vor dem Upgrade liefen meine beiden durchgereichten HDDs (mit ext4 formatiert) immer problemlos. Jetzt wollte das Debian 11 im Gast nicht mehr booten und hat mich immer nur in den Rescue-Mode geschickt, da der Dateisystem-Check von beiden durchgereichten Partitionenfehlgeschlagen ist. Ein fsck.ext4 /dev/sdc1 zeigte dann auch zehntausende von Fehler im Dateisystem von beiden Festplatten. Ich bin nicht mehr sicher was das genau war, aber irgendwas das die Größe der Groups falsch ist oder so.
Mit einem fsck.ext4 -y /dev/sdc1 und fsck.ext4 -y /dev/sdd1 im Gast bei ungemounteten Laufwerken konnte dann das ext4 repariert werden, dass die VM wieder starten konnten, aber ich habe keine Ahnung ob das fsck beim Reparieren irgendwelche Daten kaputtgemacht hat. Ich habe auch keine Backups der Daten, also kann ich da nicht mit Tools Prüfsummen vergleichen, ob die Daten noch identisch sind.

Edit:
Sowas hier meinte fsck z.B.:

Free inodes count wrong for group #8448 (8192, counted=8166).
Fix? yes

Directories count wrong for group #8448 (0, counted=1).
Fix? yes

Free inodes count wrong for group #8672 (8192, counted=8191).
Fix? yes

Directories count wrong for group #8672 (0, counted=1).
Fix? yes

Free inodes count wrong (183148533, counted=183148506).
Fix? yes

Padding at end of inode bitmap is not set. Fix? yes

Block bitmap differences: Group 1 block bitmap does not match checksum.
FIXED.

3.) Graylog im LXC wollte nicht mehr starten
Hier wollte der graylog-server im LXC nicht mehr starten weil die Elasticsearch-DB nicht mehr starten wollte. Elasticsearch wollte wiederum nicht starten, weil es beim Starten immer zum Timeout gekommen ist. Lösung: Habe dem LXC zwei statt nur einem CPU-Kern zugeordnet damit Elasticsearch schnell genug starten kann. Hier müssen die LXCs in PVE7 also langsamer sein als noch mit PVE6.4, denn der gleiche LXC hatte da sonst keine Probleme das was nicht starten will weil die Rechenleistung fehlt.

4.) LXCs brauchen ewig zum Booten
Hier half es mir bei allen unprivilegierten LXCs das Feature "nesting" zu aktivieren, sofern es nicht eh schon aktiv war.