PVE 9.2.4 – Neue Kernel 6.17.13-15 / 7.0.14-4 starten auf Legacy-BIOS-Systemen nicht, UEFI-Host funktioniert

[julianfegert]

Hallo,

nach der Installation der aktuellen Kernel mit dem Fix für CVE-2026-53359 (Januscape) treten bei uns Bootprobleme auf.

Umgebung

- Proxmox VE 9.2.4
- Frische PVE-9-Installationen (kein Upgrade von PVE 8)
- ext4 auf LVM
- Drei Produktivhosts
- no-subscription-Repository

Host 1 (UEFI)

Bootet erfolgreich mit:

- 7.0.14-4-pve

Keine Probleme.

Host 2 (Legacy BIOS / GRUB)

Beim Booten von:

- 6.17.13-15-pve
- 7.0.14-4-pve

bricht GRUB sofort mit folgender Meldung ab:

Loading Linux 7.0.14-4-pve ...
error: attempt to read or write outside of disk 'hd0'.
Loading initial ramdisk ...
error: you need to load the kernel first.

Ältere Kernel booten problemlos:

- 6.17.13-13
- 7.0.6-2

Bereits getestet:

grub-install /dev/sda
update-grub

Beides wurde ohne Fehlermeldungen abgeschlossen.

root@host02:~# pveversion -v
uname -a
lsblk -f

proxmox-ve: 9.2.0 (running kernel: 6.17.13-13-pve)
pve-manager: 9.2.4 (running version: 9.2.4/5e5ae681198514d4)
proxmox-kernel-helper: 9.2.0
proxmox-kernel-7.0.14-4-pve-signed: 7.0.14-4
proxmox-kernel-7.0: 7.0.14-4
proxmox-kernel-7.0.6-2-pve-signed: 7.0.6-2
proxmox-kernel-6.17: 6.17.13-15
proxmox-kernel-6.17.13-15-pve-signed: 6.17.13-15
proxmox-kernel-6.17.13-13-pve-signed: 6.17.13-13
proxmox-kernel-6.17.13-2-pve-signed: 6.17.13-2
proxmox-kernel-6.17.4-2-pve-signed: 6.17.4-2
proxmox-kernel-6.17.2-1-pve-signed: 6.17.2-1
ceph-fuse: 19.2.3-pve2
corosync: 3.1.10-pve2
criu: 4.1.1-1
frr-pythontools: 10.6.1-1+pve2
ifupdown2: 3.3.0-1+pmx12
intel-microcode: 3.20251111.1~deb13u1
ksm-control-daemon: 1.5-1
libjs-extjs: 7.0.0-5
libproxmox-acme-perl: 1.7.1
libproxmox-backup-qemu0: 2.0.2
libproxmox-rs-perl: 0.4.1
libpve-access-control: 9.1.1
libpve-apiclient-perl: 3.4.2
libpve-cluster-api-perl: 9.1.6
libpve-cluster-perl: 9.1.6
libpve-common-perl: 9.1.16
libpve-guest-common-perl: 6.0.4
libpve-http-server-perl: 6.0.5
libpve-network-perl: 1.6.6
libpve-notify-perl: 9.1.6
libpve-rs-perl: 0.15.3
libpve-storage-perl: 9.1.6
libspice-server1: 0.15.2-1+b1
lvm2: 2.03.31-2+pmx1
lxc-pve: 7.0.0-2
lxcfs: 7.0.0-pve1
novnc-pve: 1.7.0-2
proxmox-backup-client: 4.2.2-1
proxmox-backup-file-restore: 4.2.2-1
proxmox-backup-restore-image: 1.0.0
proxmox-firewall: 1.2.3
proxmox-kernel-helper: 9.2.0
proxmox-mail-forward: 1.0.3
proxmox-mini-journalreader: 1.7
proxmox-offline-mirror-helper: 0.7.4
proxmox-widget-toolkit: 5.2.6
pve-cluster: 9.1.6
pve-container: 6.1.10
pve-docs: 9.2.3
pve-edk2-firmware: 4.2025.05-2
pve-esxi-import-tools: 1.0.1
pve-firewall: 6.0.4
pve-firmware: 3.18-4
pve-ha-manager: 5.2.4
pve-i18n: 3.9.0
pve-qemu-kvm: 11.0.2-1
pve-xtermjs: 6.0.0-2
qemu-server: 9.1.18
smartmontools: 7.5-pve2
spiceterm: 3.4.2
swtpm: 0.8.0+pve3
vncterm: 1.9.2
zfsutils-linux: 2.4.3-pve1

Linux pve12 6.17.13-13-pve #1 SMP PREEMPT_DYNAMIC PMX 6.17.13-13 (2026-05-29T10:08Z) x86_64 GNU/Linux

NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
sda
├─sda1
├─sda2 vfat FAT32 AF2B-F2CE
└─sda3 LVM2_member LVM2 001 XB21hb-s7Nc-qUJo-o8pj-xd5s-hZDM-svmbxH
├─pve-swap swap 1 7d352742-0d0d-4664-9d5b-bf11d4cee25f [SWAP]
└─pve-root ext4 1.0 ae3b8b7d-5ae7-4ad0-80ba-86920bb858f3 4.8T 26% /
sdb
└─sdb1 ext4 1.0 c207cb1b-882d-4077-9358-833624e5f417 9T 12% /mnt/pve/Backups

root@host02:~#

Host 3 (Legacy BIOS / GRUB)

Beim Booten von:

- 6.17.13-15-pve
- 7.0.14-4-pve

tritt folgender Fehler auf:

Kernel panic - not syncing:
VFS: Unable to mount root fs on unknown-block(0,0)

Ältere Kernel booten problemlos:

- 7.0.6-2

root@host03:~# pveversion -v
uname -a
lsblk -f

proxmox-ve: 9.2.0 (running kernel: 7.0.6-2-pve)
pve-manager: 9.2.4 (running version: 9.2.4/5e5ae681198514d4)
proxmox-kernel-helper: 9.2.0
proxmox-kernel-7.0.14-4-pve-signed: 7.0.14-4
proxmox-kernel-7.0: 7.0.14-4
proxmox-kernel-7.0.6-2-pve-signed: 7.0.6-2
proxmox-kernel-6.17: 6.17.13-15
proxmox-kernel-6.17.13-15-pve-signed: 6.17.13-15
proxmox-kernel-6.17.13-13-pve-signed: 6.17.13-13
proxmox-kernel-6.17.13-2-pve-signed: 6.17.13-2
proxmox-kernel-6.17.4-2-pve-signed: 6.17.4-2
proxmox-kernel-6.17.2-1-pve-signed: 6.17.2-1
ceph-fuse: 19.2.3-pve2
corosync: 3.1.10-pve2
criu: 4.1.1-1
frr-pythontools: 10.6.1-1+pve2
ifupdown2: 3.3.0-1+pmx12
intel-microcode: 3.20251111.1~deb13u1
ksm-control-daemon: 1.5-1
libjs-extjs: 7.0.0-5
libproxmox-acme-perl: 1.7.1
libproxmox-backup-qemu0: 2.0.2
libproxmox-rs-perl: 0.4.1
libpve-access-control: 9.1.1
libpve-apiclient-perl: 3.4.2
libpve-cluster-api-perl: 9.1.6
libpve-cluster-perl: 9.1.6
libpve-common-perl: 9.1.16
libpve-guest-common-perl: 6.0.4
libpve-http-server-perl: 6.0.5
libpve-network-perl: 1.6.6
libpve-notify-perl: 9.1.6
libpve-rs-perl: 0.15.3
libpve-storage-perl: 9.1.6
libspice-server1: 0.15.2-1+b1
lvm2: 2.03.31-2+pmx1
lxc-pve: 7.0.0-2
lxcfs: 7.0.0-pve1
novnc-pve: 1.7.0-2
proxmox-backup-client: 4.2.2-1
proxmox-backup-file-restore: 4.2.2-1
proxmox-backup-restore-image: 1.0.0
proxmox-firewall: 1.2.3
proxmox-kernel-helper: 9.2.0
proxmox-mail-forward: 1.0.3
proxmox-mini-journalreader: 1.7
proxmox-offline-mirror-helper: 0.7.4
proxmox-widget-toolkit: 5.2.6
pve-cluster: 9.1.6
pve-container: 6.1.10
pve-docs: 9.2.3
pve-edk2-firmware: 4.2025.05-2
pve-esxi-import-tools: 1.0.1
pve-firewall: 6.0.4
pve-firmware: 3.18-4
pve-ha-manager: 5.2.4
pve-i18n: 3.9.0
pve-qemu-kvm: 11.0.2-1
pve-xtermjs: 6.0.0-2
qemu-server: 9.1.18
smartmontools: 7.5-pve2
spiceterm: 3.4.2
swtpm: 0.8.0+pve3
vncterm: 1.9.2
zfsutils-linux: 2.4.3-pve1

Linux pve10 7.0.6-2-pve #1 SMP PREEMPT_DYNAMIC PMX 7.0.6-2 (2026-05-29T11:08Z) x86_64 GNU/Linux

NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
sda
├─sda1
├─sda2 vfat FAT32 AE66-4781
└─sda3 LVM2_member LVM2 001 TCwdvG-wILr-LYYw-EVO7-0jC4-IuoE-hxPrwD
├─pve-swap swap 1 9f1e5b46-575f-4cbe-94ed-29273c9f3ca6 [SWAP]
└─pve-root ext4 1.0 b3532872-6074-41ff-b5c3-88c86062e9ce 4.6T 29% /
sdb
└─sdb1 ext4 1.0 66287a87-7a77-4c91-bd7e-1985b0864fcd 8.9T 12% /mnt/pve/Backups

root@host03:~#

Zusätzliche Informationen

- /boot ist Teil des Root-Dateisystems (kein separates /boot).
- Kernel und initramfs-Dateien sind vorhanden.
- update-initramfs wurde während der Installation erfolgreich ausgeführt.
- Die Systeme verwenden kein ZFS.
- Alle Hosts wurden direkt mit Proxmox VE 9 installiert.
- Ein UEFI-Host funktioniert mit den neuen Kerneln problemlos, während beide Legacy-BIOS-Hosts auf unterschiedliche Weise fehlschlagen.

Hat jemand ähnliche Probleme mit den aktuellen Kerneln auf Legacy-BIOS-Systemen?

 

[ThoSo]

Bisher nicht. was ist das den für Hardware?
BIOS aktuell?

 

[julianfegert]

Sind beides Supermicro CSE-819U, X10DRUi+, 2x Xeon 2680v4/2697v4, je 1 TB DDR4, je Host 3x 3,84 TB SAS SSD an Fujitsu EP420i (Raid 5), + 1x HDD (Raid 0)

Bios 3.5 vom 27.04.2022,

Auf beiden Nodes lief vor dem Update Linux 6.17.4-2-pve (2025-12-19T07:49Z)

- 7.0.6-2 und 6.17.13-13 laufen

Die neuesten 2 Versionen kommt es zu den o.g. Fehlern.

 

[julianfegert]

Oder eher als langfristige Lösung: Backup + auf UEFI Modus umstellen + neu aufsetzen und Restore?

 

[torbho]

Wir hatten ein ähnliches Problem, aber eine etwas andere Fehlermeldung.
Schau mal im BIOS, ob du auch eine Option wie diese hast: "CSM - Compatibility Support Module". Diese mussten wir erst aktivieren, dann ging es.





Bei einem anderen Problem, kam aus Grub heraus eine Eingabeaufforderung. In der haben wir einfach nur "exit" eingegeben, danach hat es normal gebootet.

 

[julianfegert]

Problem gelöst und behoben!

Ursache: Der Legacy-BIOS-Bootpfad (INT13, bei uns hinter LSI 9271-4i bzw. Fujitsu EP420i) kann nur die ersten 2 TiB der Disk lesen. Da /boot auf dem 7-TB-Root-LV liegt, hatte der ext4-Allocator die neuen Kernel/Initrds physisch über die 2-TiB-Grenze gelegt. Lag der Kernel darüber → GRUB-Error. Lag nur das Initrd darüber → Kernel startet ohne Initramfs → Panic. Nachweis per filefrag -e: alle bootenden Dateien unter der Grenze, alle scheiternden darüber — und nach Neuerzeugen des Initrds (landete zufällig tief) bootete derselbe Kernel sofort.

 

[jim_os]

Moin zusammen

Dieser Beitrag hier verunsichert mich gerade ein wenig. Auf meiner Fujitsu Esprimo D957/E90+ Kiste hier für Proxmox nutze ich nämlich auch Legacy BIOS



und auch bei mir stünde jetzt ein Kernel Update von 7.0.6-2 auf 7.0.14-4 an.



OK von dem Problem was in #6 beschrieben ist werde ich vermutlich/hoffentlich nicht betroffen sein



aber #5 schreckt mich jetzt doch erst einmal ein wenig ab. Ich habe zwar im BIOS noch nicht nachgeschaut ob es da diese Option gibt, aber das letzte für die Fujitsu D957/E90+ Kiste verfügbare BIOS ist auch aus 2024 und da wir auch kein neueres BIOS mehr kommen.

Daher: Hatte hier ggf. auch noch andere User beim Kernel Update die hier beschriebenen Probleme, oder halt ähnliche in der Art? Auf eine kompl. Neuinstallation, um die Kiste dann auf UEFI umzustellen, hätte ich nämlich alles andere als die Lust dazu.

VG Jim

 

[ThoSo]

@jim_os - verstehe ich jetzt nicht, warum man da zu schwitzen anfängt oder Panik schiebt.

Deine Optionen:

Du kannst von deinem System vor dem Updaten doch Beispielsweise mit CloneZilla eine Systemsicherung machen.
Du spielst das Update ein und die Kiste bootet normal - fein, fertig, läuft.
Du spielst das Update ein und die Kiste bootet nicht - bootest den alten Kernel, pinnst den an und wartest auf Besserung
Das System bootet nicht, du hast eine Sicherung gemacht - spiel diese doch zurück - evtl. neuer Datenträger für PVE
Das System bootet nicht, umstellen auf UEFI, und erneut probieren, ggf frisch installieren und restore Maschinen aus Backup

Du brauchst etwas zur Beruhigung für die Nerven davor / danach :
- Baldrian Tee
- eine Bottel Monkey Shoulder
- einen Spaziergang an der frischen Luft - nimmt den Hund mit


Also, Augen zu und ab durch die Mitte.
VG Thomas

Update:
ich habe mal meinen Testserver TerraMini Server G4 aktualisiert - läuft

 

[jim_os]

Moin @ThoSo

Danke für Deine Infos und den Test. Das schwitzen liegt eher an dem aktuellen Wetter und nein ich schiebe auch keine Panik. Eigentlich und zum Glück bin ich ziemlich tiefenentspannt.

Thema Clonezilla: Das nutze ich eigentlich schon seit vielen, vielen Jahren, um Images von irgendwelchen Disks zu erstellen. Allerdings nutze ich hier bei Proxmox Thin-LVM und mein letzter Stand ist der das Clonezilla damit weiterhin Probleme hat. Gut mein letzten Test meine Proxmox Install. per Clonezilla zu sichern ist jetzt auch schon wieder ein Jahr (oder so) her, aber so weit ich weiß hat sich seit dem auch nichts geändert. D.h. Clonezilla kann von einer Proxmox Installation, bei der Thin-LVM vorhanden sind, kein fehlerfreies/vollständiges Disk-Image erstellen. Ja damals hatte ich auch irgendwo mitbekommen das man irgendwelche Fehlermeldungen von Clonezilla wohl auch ignorieren könnte, aber ich habe das Thema dann erst einmal nicht weiter verfolgt.

Wobei ich gerade das Posting hier vom März diesen Jahres gelesen habe:

Please give testing Clonezilla live >= 3.3.2-8 or 20260318-* a try:
https://clonezilla.org/downloads.php
We have improved the support for LVM thin provisioning.
Please let us know the results after you try that.

Was ansonsten das Thema try and error betrifft. Ja klar könnte ich so vorgehen, aber hier erst einmal in die Runde fragen was andere User in dem Fall mit dem Kernel Update für Erfahrungen gemacht haben und ob es ggf. noch mehr User gibt die damit - ggf. sogar in Verbindung mit einer alten Fujitsu Esprimo D957/E90+ Kiste - irgendwelche Probleme hatten, kann ja auch nicht schaden.

Das ich irgendwann nicht umher komme das Update zu machen ist klar und das dann das Thema Sicherungen eine Rolle spielt - die ich hier natürlich auch vorliegen habe - ist auch klar, aber die Zeit drängt ja auch nicht - zumindest mich nicht - und daher hier erst noch die Frage in den Runde ob bei anderen Usern ggf. auch noch andere Probleme bei/mit diesem Kernel Update aufgetreten sind und wenn ja wie sie diese gelöst haben. Also solche Infos wie beispielsweise in #5.

VG Jim

 

[CoolTux]

Entscheidend ist doch wie Deine Platte partitioniert ist und ob Du mit Zwischenschichten arbeitest und wen ja wie. Also Software RAID oder LVM. Im Grunde alles was irgendwie den Device Mapper verwendet.
Ich lege /boot eh immer in die erste oder zweite Partition. Kennt man halt noch so aus den Ende der 90er.

Wobei es natürlich Sinn macht Zukunftsorientiert dann doch mal auf UEFI Boot um zu stellen.

 

[jim_os]

root@pve:~# lsblk
NAME                         MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
nvme0n1                      259:0    0 465.8G  0 disk
├─Crucial-Crucial_tmeta      252:0    0   4.7G  0 lvm
│ └─Crucial-Crucial-tpool    252:6    0 456.3G  0 lvm
│   └─Crucial-Crucial        252:7    0 456.3G  1 lvm
└─Crucial-Crucial_tdata      252:1    0 456.3G  0 lvm
  └─Crucial-Crucial-tpool    252:6    0 456.3G  0 lvm
    └─Crucial-Crucial        252:7    0 456.3G  1 lvm
nvme1n1                      259:1    0 931.5G  0 disk
├─nvme1n1p1                  259:2    0  1007K  0 part
├─nvme1n1p2                  259:3    0     1G  0 part
└─nvme1n1p3                  259:4    0 930.5G  0 part
  ├─pve-swap                 252:2    0     8G  0 lvm  [SWAP]
  ├─pve-root                 252:3    0    96G  0 lvm  /
  ├─pve-data_tmeta           252:4    0   8.1G  0 lvm
  │ └─pve-data-tpool         252:8    0 794.3G  0 lvm
  │   ├─pve-data             252:9    0 794.3G  1 lvm
  │   ├─pve-vm--105--disk--0 252:10   0     1G  0 lvm
  │   ├─pve-vm--105--disk--1 252:11   0    64G  0 lvm
  │   ├─pve-vm--104--disk--0 252:12   0     4M  0 lvm
  │   ├─pve-vm--104--disk--1 252:13   0   100G  0 lvm
  │   ├─pve-vm--104--disk--2 252:14   0     4M  0 lvm
  │   ├─pve-vm--108--disk--0 252:15   0     4M  0 lvm
  │   ├─pve-vm--108--disk--1 252:16   0    32G  0 lvm
  │   ├─pve-vm--109--disk--0 252:17   0    64G  0 lvm
  │   ├─pve-vm--100--disk--0 252:18   0     4G  0 lvm
  │   ├─pve-vm--110--disk--0 252:19   0     4G  0 lvm
  │   ├─pve-vm--111--disk--0 252:20   0     2G  0 lvm
  │   ├─pve-vm--112--disk--0 252:21   0    64G  0 lvm
  │   └─pve-vm--112--disk--1 252:22   0     4M  0 lvm
  └─pve-data_tdata           252:5    0 794.3G  0 lvm
    └─pve-data-tpool         252:8    0 794.3G  0 lvm
      ├─pve-data             252:9    0 794.3G  1 lvm
      ├─pve-vm--105--disk--0 252:10   0     1G  0 lvm
      ├─pve-vm--105--disk--1 252:11   0    64G  0 lvm
      ├─pve-vm--104--disk--0 252:12   0     4M  0 lvm
      ├─pve-vm--104--disk--1 252:13   0   100G  0 lvm
      ├─pve-vm--104--disk--2 252:14   0     4M  0 lvm
      ├─pve-vm--108--disk--0 252:15   0     4M  0 lvm
      ├─pve-vm--108--disk--1 252:16   0    32G  0 lvm
      ├─pve-vm--109--disk--0 252:17   0    64G  0 lvm
      ├─pve-vm--100--disk--0 252:18   0     4G  0 lvm
      ├─pve-vm--110--disk--0 252:19   0     4G  0 lvm
      ├─pve-vm--111--disk--0 252:20   0     2G  0 lvm
      ├─pve-vm--112--disk--0 252:21   0    64G  0 lvm
      └─pve-vm--112--disk--1 252:22   0     4M  0 lvm
root@pve:~#

root@pve:~# fdisk -l
Disk /dev/nvme0n1: 465.76 GiB, 500107862016 bytes, 976773168 sectors
Disk model: CT500P1SSD8                           
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/nvme1n1: 931.51 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: KIOXIA-EXCERIA PLUS G3 SSD           
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: E71....

Device           Start        End    Sectors   Size Type
/dev/nvme1n1p1      34       2047       2014  1007K BIOS boot
/dev/nvme1n1p2    2048    2099199    2097152     1G EFI System
/dev/nvme1n1p3 2099200 1953525134 1951425935 930.5G Linux LVM


Disk /dev/mapper/pve-swap: 8 GiB, 8589934592 bytes, 16777216 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/mapper/pve-root: 96 GiB, 103079215104 bytes, 201326592 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Anm.: Die Infos zu den VMs habe ich mal weggelassen.

dann doch mal auf UEFI Boot um zu stellen.

Jepp aber das würde halt auch den größten "Aufwand" bedeuten. Meine Proxmox Kiste hier läuft so halt schon seit vielen Jahren und wenn man wie ich mit DOS und halt Legacy BIOS aufgewachsen ist dann müsste/würde ich mich eben erst auch noch ein wenig informieren wollen was eine Umstellung auf UEFI Boot dann hier für meine Fujitsu Proxmox Kiste genau bedeuten würde oder könnte.

D.h. der für mich bequemste Weg wäre jetzt halt weiterhin bei Legacy BIOS zu bleiben und das Kernel Update hätte am besten keinerlei Auswirkungen auf meinen Proxmox Host.

Erschwerend könnte dann bei einer Umstellung auf UEFI noch hinzukommen das es für meine Fujitsu Kiste hier eben bereits seit 2024 keine BIOS Updates mehr gibt. D.h. auch das Thema Zertifikate - das ich eigentlich schon für mich als erledigt abgehakt hatte (siehe diesen Beitrag) - könnte dann ggf. wieder eine Rolle spielen.

VG Jim

 

[ThoSo]

Erschwerend könnte dann bei einer Umstellung auf UEFI noch hinzukommen das es für meine Fujitsu Kiste hier eben bereits seit 2024 keine BIOS Updates mehr gibt. D.h. auch das Thema Zertifikate - das ich eigentlich schon für mich als erledigt abgehakt hatte (siehe diesen Beitrag) - könnte dann ggf. wieder eine Rolle spielen.

Die Zertifikate sind nur im Zusammenhang mit Secure Boot = on von belang.
Debian hat lt. linuxnews (https://linuxnews.de/debian-13-6-trixie-veroeffentlicht/) bei fwupd da auch aktuell nachgezogen. Bei fujitsu müsste das auch ohne BIOS Update gehen, habe da etwas dunkel im Kopf.
Ich sehe da aber keine Zwangsnotwendigkeit von BIOS auf UEFI umzustellen.

Please give testing Clonezilla live >= 3.3.2-8 or 20260318-* a try:
https://clonezilla.org/downloads.php
We have improved the support for LVM thin provisioning.

Ich habe mit Clone- bzw. RescueZilla (faule nutzen eine GUI) eine ESET Appliance mal damit gesichert - diese nutzt LVM und es gab keine Probleme beim Sicherung und Wiederherstellen. Ein anderes Cloningtool (R-Drive6) hatte die Daten zwar gesichert aber beim Restore versagt.

VG Thomas

 

[jim_os]

diese nutzt LVM und es gab keine Probleme beim Sicherung und Wiederherstellen.

LVM an sich ist auch erst einmal nicht das Problem. Wenn dann aber LVM-Thin ins Spiel kommt kommt es zu Problemen. Was ja auch schon seit Jahren ein bekanntes Problem ist: "Clonezilla does not support LVM thin provisioning at the moment."

Wie gesagt weiß ich nicht wie da jetzt der aktuell Stand der Dinge ist, aber nachdem ich das o.g. Posting vom März diesen Jahres gefunden habe, habe ich mir eben auch mal die aktuelle Clonezilla Version heruntergeladen und werde damit - vielleicht noch heute im Laufe des Tages - mal versuchen von meinem Proxmox Host ein Image zu erstellen. Einfach um auch mal zu wissen wie jetzt der Stand der Dinge bzgl. Clonezilla und LVM-Thin ist.

Clone- bzw. RescueZilla (faule nutzen eine GUI)

Jepp im Laufe der Jahre habe ich dann auch zu Rescuezilla gewechselt und somit gehöre ich auch zu den "Faulen", aber bzgl. dem Thema LVM-Thin konnte ich vorhin auf die Schnelle nichts dazu finden das sich da bei Rescuezilla - so wie bei Clonezilla - irgendetwas getan hat/hätte. Daher werde ich jetzt für den Test mit dem Proxmox Host mal wieder Clonezilla nutzen.


Edit: Und weil man Sonntags ja auch sonst nichts zu tun hat, habe ich jetzt den Clonezilla Test mit meinem Proxmox Host gemacht. Ergebnis: Die Image-Erstellung läuft scheinbar vollkommen normal und problemlos durch, aber bei der Überprüfung von dem Image kommt es dann zu einer Fehlermeldung. So oder so ähnlich hatte ich das auch noch von früheren Versuchen in Erinnerung. Als Fehlermeldung kommt dann: "Defekte oder nicht prüfbare Partitions-Abbilder im Image gefunden. Weiter mit Enter. Drückt man dann Enter kommt halt osc-live-general finished with error! und das war's dann. Dabei kommt dann zwar auch noch der übliche Verweis auf das Log, aber bisher konnte ich bei den div. *.txt-Dateien noch nicht ein oder das Log finden, in dem dann etwas mehr zu diesen "Defekte oder nicht prüfbare Partitions-Abbilder" steht. Somit gilt für mich hier erst einmal weiterhin das ich von meinem Proxmox Host hier wohl kein fehlerfreies Image problemlos erstellen kann. Was auch immer jetzt die genaue Ursache dafür ist.

Als Gegentest habe ich hier auch noch von zwei andere Linux Clients, bei denen halt kein LVM-Thin genutzt wird, ein Image der Disks erstellt. Dabei gab es dann auch keinerlei Probleme.

VG Jim

 

[ThoSo]

Hast du das mit der aktuellen version 3.3.2-31 getestet?

 

[jim_os]

Jepp

VG Jim

 

[jim_os]

D.h. der für mich bequemste Weg wäre jetzt halt weiterhin bei Legacy BIOS zu bleiben und das Kernel Update hätte am besten keinerlei Auswirkungen auf meinen Proxmox Host.

So war bzw. ist es dann auch. Obwohl auf der Kiste sogar noch ein BIOS von 2018 läuft verlief das Kernel-Update von 7.0.6-2 zu 7.0.14-4 mit/trotz Legacy BIOS problemlos.



VG Jim

 

[ThoSo]

@jim_os : Schön das es geklappt hat.
Aber ich habe jetzt auch noch etwas für dich zum Grübeln ...

Ich habe hier auf einen Zotac Mini PC eine mit Default/Standard installiertes PVE 9 System.
Darauf sind im LVM-Thin drei VM Maschinen mit etwa 20GB echten Belegungsdaten und Plattenspeicher insgesamt 80GB zugewiesen.

Das System habe ich mit CloneZilla mit dem Defaulteinstellungen komplett als DISK Image wegesichert, inkl Prüfung keine Fehler.
Das Gesamtvolumen der Sicherung waren knapp 25Gb.

Dann die SSD in der Kiste mit Windows DISKPART mit der Option "clean" behandelt und anschließend das gesicherte CloneZilla Image zurückgespielt - auch ohne Fehler!
System neu gestartet, VMs getestet läuft.

Interessant war das die Disks als RAW (=100%) gesichert wurden. Beim Wiederherstellen wurden dann im LVM-Thin die volle Belegung der gesicherten Platten (in Summe also 80GB) erzeugt. Wer also seinen LVM-Thin Pool über provisioniert hat, der macht dann einen Bauchklatscher. Das kann man mit dem PVE Backup und einem Restore der VM wieder zurückstellen, dann sind die Disks wieder klein.

Nur mal so aus Langeweile - es geht also doch mit CloneZille und LVM-Thin

 

[jim_os]

Moin

Danke für Deinen Test.

@jim_os : Schön das es geklappt hat.
Das System habe ich mit CloneZilla mit dem Defaulteinstellungen komplett als DISK Image wegesichert, inkl Prüfung keine Fehler.

Das war bestimmt nur Zufall.

es geht also doch mit CloneZille und LVM-Thin

Ich weiß ja auch nicht was dann bei mir und anderen Usern das genaue Problem bei der Image-Erstellung ist. Ich weiß nur das es bereits seit Jahren heißt das LVM-Thin wohl für das Problem verantwortlich ist, oder sein soll. Wie gesagt nutzt ich Clonezilla schon seit vielen Jahren für unterschiedliche Client-BS und -Installationen für eine Image-Erstellung und bei mir trat und tritt das Problem eben nur bei meiner Proxmox Installation auf.

In dem von mir in #9 zitierten Posting heißt es ja auch nur "We have improved the support for LVM thin provisioning." und auf das "Please let us know the results after you try that." gibt es dann leider keine Rückmeldung mehr. Ergo kann man nur darüber spekulieren ob die bereits seit Jahren vorhandenen Probleme jetzt wirklich und vollständig gelöst wurden.

Wenn Du jetzt von einer Proxmox Installation ein Image problemlos und ohne Fehler erstellen konntest ist das natürlich gut, aber das ist anderen Usern früher mit älteren Clonezilla Versionen ja auch schon gelungen. Das bedeutet aber nicht automatisch das das dann auch für alle Proxmox Installationen gilt. Und wie bereits gesagt: Ob LVM Thin dann die wirkliche und einzige Ursache für das Problem ist weiß ich nicht. Vielleicht ist für diese Meldung "Defekte oder nicht prüfbare Partitions-Abbilder im Image gefunden. Weiter mit Enter." ja z.B. auch eine unter Proxmox vorhandene VM und ihre Partitionen verantwortlich. Bei mir sind unter Proxmox z.B. einige Linux VM und eine Windows 11 VM installiert. Zu den Linux VM taucht in dem Clonezilla Log dann nichts weiter auf was auf Probleme bei der Erstellung des des jeweiligen Part.-Images hindeutet. Bei der Windows 11 VM taucht dann aber z.B. das hier auf:

Finished saving /dev/pve/vm-104-disk-0 as /home/partimag/2026-07-12-13-img/pve-vm-104-disk-0.dd-ptcl-img.zst
*****************************************************.
Saving /dev/pve/vm-104-disk-1 as filename: pve-vm-104-disk-1. /dev/pve/vm-104-disk-1 info: DOS/MBR boot sector MS-MBR Windows 7 english at offset 0x163 "Invalid partition table" at offset 0x17b "Error loading operating system" at offset 0x19a "Missing operating system"; partition 1
Skip fscking unknown or unsupported file system on /dev/pve/vm-104-disk-1.
Starting saving /dev/pve/vm-104-disk-1 as /home/partimag/2026-07-12-13-img/pve-vm-104-disk-1.XXX...
/dev/pve/vm-104-disk-1 filesystem: Unknown or unsupported.

Aber ob dann das ggf. für diese "Defekte oder nicht prüfbare Partitions-Abbilder im Image gefunden. Weiter mit Enter." Meldung verantwortlich ist: Keine Ahnung.

Es wird halt von zwei NVMe ein Image erstellt:

The selected devices: nvme0n1 nvme1n1
Searching for data/swap/extended partition(s)...
Searching for data/swap/extended partition(s)...
The data partition to be saved: nvme1n1p1 nvme1n1p2 nvme1n1p3 nvme0n1
The selected devices: nvme1n1p1 nvme1n1p2 nvme1n1p3 nvme0n1
Im nächsten Schritt wird die Festplatte oder die Partitionen auf diesem System als Image gesichert:
*****************************************************.
Machine: ESPRIMO D957
nvme0n1 (465.8G|LVM2_member|CT500P1SSD8|pci-0000_01_00_0-nvme-1|block:512|204...)
nvme1n1 (931.5G|KIOXIA-EXCERIA_PLUS_G3_SSD|pci-0000_03_00_0-nvme-1|block:512|3EK...)
nvme1n1p1 (1007K|No_file_system|In_KIOXIA-EXCERIA_PLUS_G3_SSD|No_label|pci-0000_03_00_0-nvme-1|3EK...)
nvme1n1p2 (1G|vfat|In_KIOXIA-EXCERIA_PLUS_G3_SSD|No_label|pci-0000_03_00_0-nvme-1|3EK...)
nvme1n1p3 (930.5G|LVM2_member|In_KIOXIA-EXCERIA_PLUS_G3_SSD|No_label|pci-0000_03_00_0-nvme-1|3EK...)

Am Ende des clonezilla-img. log steht dann nur

Dumping the device mapper table in /home/partimag/2026-07-12-13-img/dmraid.table...
Saving block devices info in /home/partimag/2026-07-12-13-img/blkdev.list...
Saving block devices attributes in /home/partimag/2026-07-12-13-img/blkid.list...
Saving block devices info in json format as /home/partimag/2026-07-12-13-img/blkdev.json...
*****************************************************.
Starting Advanced MDRAID layout backup into: /home/partimag/2026-07-12-13-img
No MDRAID devices found in /proc/mdstat.
Saving block devices output by fdisk as /home/partimag/2026-07-12-13-img/fdisk.list...
Checking the integrity of partition table in the disk /dev/nvme1n1...
Reading the partition table for /dev/nvme1n1...RETVAL=0
*****************************************************.
Saving the primary GPT of nvme1n1 as /home/partimag/2026-07-12-13-img/nvme1n1-gpt-1st by dd...
34+0 records in
34+0 records out
17408 bytes (17 kB, 17 KiB) copied, 0.00179315 s, 9.7 MB/s
*****************************************************.
Saving the secondary GPT of nvme1n1 as /home/partimag/2026-07-12-13-img/nvme1n1-gpt-2nd by dd...
32+0 records in
32+0 records out
16384 bytes (16 kB, 16 KiB) copied, 0.00121669 s, 13.5 MB/s
*****************************************************.
Saving the GPT of nvme1n1 as /home/partimag/2026-07-12-13-img/nvme1n1-gpt.gdisk by gdisk...
The operation has completed successfully.
*****************************************************.
Checking the integrity of partition table in the disk /dev/nvme0n1...
Reading the partition table for /dev/nvme0n1...RETVAL=1
Saving the MBR data for nvme1n1...
1+0 Datensätze ein
1+0 Datensätze aus
512 Bytes kopiert, 7,0606e-05 s, 7,3 MB/s
Saving the MBR data for nvme0n1...
1+0 Datensätze ein
1+0 Datensätze aus
512 Bytes kopiert, 0,000125214 s, 4,1 MB/s
End of saveparts job for image /home/partimag/2026-07-12-13-img.
*****************************************************.
*****************************************************.
End of savedisk job for image 2026-07-12-13-img.
Checking if udevd rules have to be restored...
This program is not started by Clonezilla server, so skip notifying it the job is done.
This program is not started by Clonezilla server, so skip notifying it the job is done.
Finished!
Finished!
*****************************************************.
### End of log ###
### Image created time: 2026-0712-1326

und danach scheint es so als wären beide NVMe problemlos gesichert worden:

Checking the integrity of partition table in the disk /dev/nvme1n1...
Checking the integrity of partition table in the disk /dev/nvme0n1...

Aber trotzdem erscheint am Ende des Prozesses dann

"Defekte oder nicht prüfbare Partitions-Abbilder im Image gefunden. Weiter mit Enter. ..... osc-live-general finished with error!"

und zumindest ich kann bei dem überfliegen der Logs nirgends einen Hinweis darauf finden was genau damit gemeint ist.

Da ich auch nicht das Risiko eingehen will jetzt auch noch zu testen ob sich die Proxmox Installation dann aus dem Clonezilla Image problemlos und fehlerfrei wiederherstellen lässt, muss ich und gehe ich weiter davon aus das das Clonezilla Image meiner Proxmox Installation eben nicht fehlerfrei ist und ich es somit vermutlich auch nicht gebrauchen kann.

Edit: Ja um die Win 11 VM als mögliche Ursache auszuschließen könnte ich diese natürlich auch mal löschen und später aus eine Backup wiederherstellen. Sollte dann ohne die Win 11 VM die Clonezilla Image Erstellung ohne diese Fehlermeldung durchlaufen dürfte eben die Win 11 VM mit ihren Partitionen die Ursache sein. Aber für so einen Test habe ich im Moment nicht die Zeit und auch nicht wirklich die Lust. Das mache ich dann ggf. mal wenn auch bei mir mal wieder viel Langeweile herrschen sollte.

VG Jim

 

[ThoSo]

OK, kleine Anmerkung dazu noch. Die VMs waren Linux Systeme.
Aber die VM Disks wurden als RAW Daten (nicht auf Dateisystembasis!) gesichert - möglicherweise ist das der Knackpunkt,

Starting saving /dev/pve/vm-104-disk-1 as /home/partimag/2026-07-12-13-img/pve-vm-104-disk-1.XXX... /dev/pve/vm-104-disk-1 filesystem: Unknown or unsupported.

Was hast den da für ein Dateisystem drin?
Wobei die Disk bei einer RAW Sicherung ja egal wäre.

Was ein Glück das die IT Welt für alles gut ist !

 

[jim_os]

Was hast den da für ein Dateisystem drin?

Gute Frage - nächste. Das ist m.M.n. eine "stinknormale" Win 11 Installation, so wie man sie unter einer VM halt machen, bzw. machen kann. Ich habe der VM lediglich 100GB unter local-lvm zugewiesen und die Partionierungen und alles andere hat dann halt die Win 11 Installation selber vorgenommen.





Anm.: Die beiden CD/DVD Einbindungen könnten da natürlich raus, aber das spielt in dem Fall ja auch keine Rolle.

Das Dateisystem selber dürfte wohl - ohne das ich jetzt nachschaue - NTFS sein.

Was ein Glück das die IT Welt für alles gut ist !

Jepp - stell Dir vor alles würde einfach so und fehlerfrei funktionieren. Worüber sollte man sich hier dann noch austauschen.

Edit:


Edit 2 und BTW: Ich habe fast schon ein schlechtes Gewissen das es hier jetzt nur noch um Clonezilla geht, auch auch nur "fast". Die hier genannten Probleme mit dem neuen Kernel und Legacy-BIOS waren ja eh schon gelöst und bei mit sind - entgegen meiner Befürchtung - ja erst gar keine aufgetreten.

VG Jim