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