PBS kein Boot nach Update auf Kernel 5.15.107-2-pve

Feb 2, 2021
29
0
6
42
Hallo zusammen,

nach einem Update von Kernel 5.15.104-2-pve auf 5.15.107-2-pve auf einem der PBS kann dieser nicht mehr booten, und bleibt mit folgender Meldung stehen:

Loading Linux 5.15.107-2-pve ... error: attempt to read or write outside of disk 'hd0'. Loading initial ramdisk ... error: you need to Ioad the kernel first. Press any key to continue...

Der PBS läuft virtuell auf einem Proxmox Server.

Wenn ich manuell bei der Bootauswahl den alten 5.15.104-2-pve auswähle, kann ich normal booten.

Habt Ihr ne Idee, wo ich anfangen kann zu suchen?

Danke,
Basti

1684867916085.png
 
Hi,
welches storage backend verwendet die VM?

Bitte pveversion -v, cat /etc/pve/storage.cfg und qm config <VMID> für die entsprechende VM posten.
 
Hi Chris,

hier die gewünschten Angaben:

Code:
root@pxh1:~# pveversion -v
proxmox-ve: 7.4-1 (running kernel: 5.15.102-1-pve)
pve-manager: 7.4-3 (running version: 7.4-3/9002ab8a)
pve-kernel-5.15: 7.3-3
pve-kernel-5.4: 6.4-20
pve-kernel-5.15.102-1-pve: 5.15.102-1
pve-kernel-5.15.85-1-pve: 5.15.85-1
pve-kernel-5.4.203-1-pve: 5.4.203-1
ceph-fuse: 14.2.21-1
corosync: 3.1.7-pve1
criu: 3.15-1+pve-1
glusterfs-client: 9.2-1
ifupdown: residual config
ifupdown2: 3.1.0-1+pmx3
libjs-extjs: 7.0.0-1
libknet1: 1.24-pve2
libproxmox-acme-perl: 1.4.4
libproxmox-backup-qemu0: 1.3.1-1
libproxmox-rs-perl: 0.2.1
libpve-access-control: 7.4-2
libpve-apiclient-perl: 3.2-1
libpve-common-perl: 7.3-3
libpve-guest-common-perl: 4.2-4
libpve-http-server-perl: 4.2-1
libpve-rs-perl: 0.7.5
libpve-storage-perl: 7.4-2
libspice-server1: 0.14.3-2.1
lvm2: 2.03.11-2.1
lxc-pve: 5.0.2-2
lxcfs: 5.0.3-pve1
novnc-pve: 1.4.0-1
proxmox-backup-client: 2.3.3-1
proxmox-backup-file-restore: 2.3.3-1
proxmox-kernel-helper: 7.4-1
proxmox-mail-forward: 0.1.1-1
proxmox-mini-journalreader: 1.3-1
proxmox-offline-mirror-helper: 0.5.1-1
proxmox-widget-toolkit: 3.6.3
pve-cluster: 7.3-3
pve-container: 4.4-3
pve-docs: 7.4-2
pve-edk2-firmware: 3.20221111-2
pve-firewall: 4.3-1
pve-firmware: 3.6-4
pve-ha-manager: 3.6.0
pve-i18n: 2.11-1
pve-qemu-kvm: 7.2.0-8
pve-xtermjs: 4.16.0-1
qemu-server: 7.4-2
smartmontools: 7.2-pve3
spiceterm: 3.2-2
swtpm: 0.8.0~bpo11+3
vncterm: 1.7-1
zfsutils-linux: 2.1.9-pve1

Code:
root@pxh1:~# cat /etc/pve/storage.cfg
dir: local
        path /var/lib/vz
        content vztmpl
        prune-backups keep-all=1
        shared 0

dir: backup
        path /backup
        content iso,backup,vztmpl
        maxfiles 3
        shared 0

lvmthin: data_thin
        thinpool data
        vgname pve
        content images,rootdir

Code:
root@pxh1:~# qm config 750
bootdisk: scsi0
cores: 4
ide2: none,media=cdrom
memory: 4096
name: pbs01.wsit.network
net0: virtio=1A:32:ED:86:B7:56,bridge=vmbr0,firewall=1
numa: 0
onboot: 1
ostype: l26
scsi0: data_thin:vm-750-disk-0,cache=writeback,size=3T
scsihw: virtio-scsi-pci
smbios1: uuid=70d18f97-766d-49d7-96e7-e2239218feca
sockets: 1
vmgenid: 916f7864-8e18-4131-a146-5cee86c9c446

Das ganze läuft auf einem Software Raid 10:

Code:
root@pxh1:~# cat /proc/mdstat
Personalities : [raid10] [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4]
md1 : active raid10 sda2[7] sdd2[5] sdb2[4] sdc2[6]
      19531557888 blocks super 1.2 512K chunks 2 near-copies [4/4] [UUUU]
      bitmap: 11/146 pages [44KB], 65536KB chunk

md0 : active raid1 sda1[7] sdd1[5] sdb1[4] sdc1[6]
      523712 blocks super 1.2 [4/4] [UUUU]

unused devices: <none>

Wenn ich noch was vergessen habe, bitte kurz Bescheid sagen.

Danke,
Basti
 
Hi Chris,

hier die gewünschten Angaben:

Code:
root@pxh1:~# pveversion -v
proxmox-ve: 7.4-1 (running kernel: 5.15.102-1-pve)
pve-manager: 7.4-3 (running version: 7.4-3/9002ab8a)
pve-kernel-5.15: 7.3-3
pve-kernel-5.4: 6.4-20
pve-kernel-5.15.102-1-pve: 5.15.102-1
pve-kernel-5.15.85-1-pve: 5.15.85-1
pve-kernel-5.4.203-1-pve: 5.4.203-1
ceph-fuse: 14.2.21-1
corosync: 3.1.7-pve1
criu: 3.15-1+pve-1
glusterfs-client: 9.2-1
ifupdown: residual config
ifupdown2: 3.1.0-1+pmx3
libjs-extjs: 7.0.0-1
libknet1: 1.24-pve2
libproxmox-acme-perl: 1.4.4
libproxmox-backup-qemu0: 1.3.1-1
libproxmox-rs-perl: 0.2.1
libpve-access-control: 7.4-2
libpve-apiclient-perl: 3.2-1
libpve-common-perl: 7.3-3
libpve-guest-common-perl: 4.2-4
libpve-http-server-perl: 4.2-1
libpve-rs-perl: 0.7.5
libpve-storage-perl: 7.4-2
libspice-server1: 0.14.3-2.1
lvm2: 2.03.11-2.1
lxc-pve: 5.0.2-2
lxcfs: 5.0.3-pve1
novnc-pve: 1.4.0-1
proxmox-backup-client: 2.3.3-1
proxmox-backup-file-restore: 2.3.3-1
proxmox-kernel-helper: 7.4-1
proxmox-mail-forward: 0.1.1-1
proxmox-mini-journalreader: 1.3-1
proxmox-offline-mirror-helper: 0.5.1-1
proxmox-widget-toolkit: 3.6.3
pve-cluster: 7.3-3
pve-container: 4.4-3
pve-docs: 7.4-2
pve-edk2-firmware: 3.20221111-2
pve-firewall: 4.3-1
pve-firmware: 3.6-4
pve-ha-manager: 3.6.0
pve-i18n: 2.11-1
pve-qemu-kvm: 7.2.0-8
pve-xtermjs: 4.16.0-1
qemu-server: 7.4-2
smartmontools: 7.2-pve3
spiceterm: 3.2-2
swtpm: 0.8.0~bpo11+3
vncterm: 1.7-1
zfsutils-linux: 2.1.9-pve1

Code:
root@pxh1:~# cat /etc/pve/storage.cfg
dir: local
        path /var/lib/vz
        content vztmpl
        prune-backups keep-all=1
        shared 0

dir: backup
        path /backup
        content iso,backup,vztmpl
        maxfiles 3
        shared 0

lvmthin: data_thin
        thinpool data
        vgname pve
        content images,rootdir

Code:
root@pxh1:~# qm config 750
bootdisk: scsi0
cores: 4
ide2: none,media=cdrom
memory: 4096
name: pbs01.wsit.network
net0: virtio=1A:32:ED:86:B7:56,bridge=vmbr0,firewall=1
numa: 0
onboot: 1
ostype: l26
scsi0: data_thin:vm-750-disk-0,cache=writeback,size=3T
scsihw: virtio-scsi-pci
smbios1: uuid=70d18f97-766d-49d7-96e7-e2239218feca
sockets: 1
vmgenid: 916f7864-8e18-4131-a146-5cee86c9c446

Das ganze läuft auf einem Software Raid 10:

Code:
root@pxh1:~# cat /proc/mdstat
Personalities : [raid10] [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4]
md1 : active raid10 sda2[7] sdd2[5] sdb2[4] sdc2[6]
      19531557888 blocks super 1.2 512K chunks 2 near-copies [4/4] [UUUU]
      bitmap: 11/146 pages [44KB], 65536KB chunk

md0 : active raid1 sda1[7] sdd1[5] sdb1[4] sdc1[6]
      523712 blocks super 1.2 [4/4] [UUUU]

unused devices: <none>

Wenn ich noch was vergessen habe, bitte kurz Bescheid sagen.

Danke,
Basti
Edit: Wir raten prinzipiell von software raid ab.

Okay, bitte versuch mal den jetzigen PVE 6.2 kernel zu installieren und damit zu booten.
Code:
apt install pve-kernel-6.2

Auch von interesse, lsblk -o +FSTYPE von innerhalb der PBS VM.
 
Last edited:
Hi Chris,

hier die Ausgabe von "lsblk":

Code:
root@pbs01:~# lsblk -o +FSTYPE
NAME         MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT FSTYPE
sda            8:0    0    3T  0 disk
├─sda1         8:1    0 1007K  0 part
├─sda2         8:2    0  512M  0 part            vfat
└─sda3         8:3    0    3T  0 part            LVM2_member
  ├─pbs-swap 253:0    0    7G  0 lvm  [SWAP]     swap
  └─pbs-root 253:1    0    3T  0 lvm  /          ext4
sr0           11:0    1 1024M  0 rom

Der 6.2er Kernel bootet ohne Probleme:
root@pbs01:~# uname -a Linux pbs01 6.2.11-2-pve #1 SMP PREEMPT_DYNAMIC PVE 6.2.11-2 (2023-05-10T09:13Z) x86_64 GNU/Linux

Wenn das keine sonstigen Nachteile hat, kann ich das ja so lassen, oder?

Danke,
Basti
 
Hi Chris,

hier die Ausgabe von "lsblk":

Code:
root@pbs01:~# lsblk -o +FSTYPE
NAME         MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT FSTYPE
sda            8:0    0    3T  0 disk
├─sda1         8:1    0 1007K  0 part
├─sda2         8:2    0  512M  0 part            vfat
└─sda3         8:3    0    3T  0 part            LVM2_member
  ├─pbs-swap 253:0    0    7G  0 lvm  [SWAP]     swap
  └─pbs-root 253:1    0    3T  0 lvm  /          ext4
sr0           11:0    1 1024M  0 rom

Der 6.2er Kernel bootet ohne Probleme:
root@pbs01:~# uname -a Linux pbs01 6.2.11-2-pve #1 SMP PREEMPT_DYNAMIC PVE 6.2.11-2 (2023-05-10T09:13Z) x86_64 GNU/Linux

Wenn das keine sonstigen Nachteile hat, kann ich das ja so lassen, oder?

Danke,
Basti
Ja, Kernel 6.2 ist sehr zu empfehlen, ältere machen immer mal wieder Probleme.

Noch eine Anmerkung: Software RAID wird nicht supported, wir empfehlen Hardware raid oder ZFS.
 
Aktuell ist der 5er Kernel ja noch Standard bei Proxmox. Macht es Sinn, Kisten die mit dem 5er Kernel problemlos laufen, auch auf 6.2 zu heben?
Oder soll ich mit den anderen warten, bis der 6er Standard wird?

Danke schonmal für Deine Hilfe!!

Grüße,
Basti
 
Aktuell ist der 5er Kernel ja noch Standard bei Proxmox. Macht es Sinn, Kisten die mit dem 5er Kernel problemlos laufen, auch auf 6.2 zu heben?
Oder soll ich mit den anderen warten, bis der 6er Standard wird?

Danke schonmal für Deine Hilfe!!

Grüße,
Basti
Kernel 6.2 wird der nächste Standard Kernel, also kann man durchaus darauf upgraden, auch mal zum test, man kann dann ja immer noch den alten Kernel als default zum booten verwenden.

Allerdings seh ich keinen zwingenden Grund dies zu tun wenn die Hosts problemlos damit laufen.
 
@Chris gibt es bei euch negative Erfahrungen mit Linux Software Raid? Habe auf meinen Proxmoxen teils ZFS, teils HW Raid, und teils SW Raid (historische Gründe) und mit SW Raid bisher keine Probleme (weniger als mit HW Raid), daher die Frage
 
@Chris gibt es bei euch negative Erfahrungen mit Linux Software Raid? Habe auf meinen Proxmoxen teils ZFS, teils HW Raid, und teils SW Raid (historische Gründe) und mit SW Raid bisher keine Probleme (weniger als mit HW Raid), daher die Frage
Hi, wir supporten dies wegen fehlender Datenintegritätschecks nicht, es bleibt jedem selbst überlassen ob man dennoch so ein Setup verwenden möchte.
Siehe dazu auch https://pve.proxmox.com/wiki/Software_RAID
 
Kernel 6.2 wird der nächste Standard Kernel, also kann man durchaus darauf upgraden, auch mal zum test, man kann dann ja immer noch den alten Kernel als default zum booten verwenden.

Allerdings seh ich keinen zwingenden Grund dies zu tun wenn die Hosts problemlos damit laufen.
Der 6.2 ist als EOL markiert?
 
Hi, wir supporten dies wegen fehlender Datenintegritätschecks nicht, es bleibt jedem selbst überlassen ob man dennoch so ein Setup verwenden möchte.
Siehe dazu auch https://pve.proxmox.com/wiki/Software_RAID
Überall wo ich das bisher verwendet habe führt mdraid regelmäßig Scans des Arrays durch. Die sind erstmal nur lesend, belasten SSDs also nicht sonderlich, können aber triggern, daß die SSD selbst bit rot erkennt und schwache Blöcke auffrischt. Und wo das nicht klappt, wird das vom Array aufgefangen.
Der erwähnte Bug mit O_DIRECT tritt nicht bei RAID5/6 auf, weil es da prinzipbedingt keinen zero-copy direct write gibt. (Außerdem ist er nicht ganz so kritisch vong Datenintegrität her, weil da bei einem RAID1[0] auf beiden Seiten des Mirrors Datenmüll liegt.) Andernfalls würde mich nämlich mal interessieren, was ceph bei O_DIRECT macht.

Wesentlich kritischer ist, daß mdraid die Integrität des RAIDs beim Ausfall zum ungünstigen Zeitpunkt nicht garantieren kann. Die Wahrscheinlichkeit sinkt zwar mit dual supply und USV, aber wenn der Kernel einfriert ist das trotzdem doof. HW-RAID mit FBWC kann fehlende Writes nachholen, auch wenn der Host abgesemmelt ist, so daß die einzelnen RAID-Blöcke immer zueinander passen, und zfs schreibt einfach so viel Extradaten, daß die Konsistenz auch gesichert ist (hat dafür aber auch fiese write amplification).
Nota bene: Daß das RAID konsistent ist, heißt nicht, daß es die Daten auch sind. Auch zfs rettet nicht davor, daß eine Datei erst zur Hälfte rausgeschrieben ist. Insbesondere bei Datenbanken immer wieder spaßig.
 
das urspruengliche problem ist eine einschraenkung von grub wenn nicht UEFI verwendet wird, und dateien von einer grossen platte gelesen werden muessen die zum boot gebraucht werden (z.b. stage2 von grub, kernel, initrd, ..). die loesung dafuer ist entweder eine kleinere platte fuer /boot oder / zu verwenden, oder UEFI. das in dem fall die eine kernel version betroffen war und die andere nicht, war reiner zufall (die eine datei lag "weiter hinten" auf der platte).
 
  • Like
Reactions: Chris
das urspruengliche problem ist eine einschraenkung von grub wenn nicht UEFI verwendet wird, und dateien von einer grossen platte gelesen werden muessen die zum boot gebraucht werden (z.b. stage2 von grub, kernel, initrd, ..). die loesung dafuer ist entweder eine kleinere platte fuer /boot oder / zu verwenden, oder UEFI. das in dem fall die eine kernel version betroffen war und die andere nicht, war reiner zufall (die eine datei lag "weiter hinten" auf der platte).

Jup, das scheint hier wohl wirklich das Problem zu sein, / liegt auf einer großen Partition. Ich werde demnächst einen neuen PBS aufsetzen, und die Backups per Sync umziehen.
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!