Ubuntu Server 20.04.1 booten nicht mehr

[franz78]

hallo,

nach einem Upgrade lassen sich Ubuntu Server 20.04.1 nicht mehr booten (Power Off/On)

Folgender Fehler tritt bei "VirtIO-SCSI*" auf.

PVE: 6.2-12

Booting from Hard Disk:
error: Disk: lvmid/XyZa... usw not found.
Entering rescue mode...
grub rescue >

Lösung:
downgrade:

apt reinstall pve-qemu-kvm=5.1.0-3 > failed
apt reinstall pve-qemu-kvm=5.1.0-2 > failed
apt reinstall pve-qemu-kvm=5.1.0-1 > failed
apt reinstall pve-qemu-kvm=5.0.0-13 > success!!

nach dem downgrade auf "pve-qemu-kvm vers: 5.0.0-13" funktioniert wieder alles.

LG,

 

[t.lamprecht]

Hi,

Ist in den VM Optionen auch die richtige Disk in der Boot Ordnung eingestellt?


Hier gab es nämlich eine Änderung im virtuellen BIOS.

Ansonsten bitte gesamte VM config posten, etwa mit: qm config VMID

 

[franz78]

hallo,

ja, das hab ich alles durchprobiert. Mit dem SCSI Controler LSI53C.. hat die VM ohne Probleme gebootet.
Hab auch einen neuen Ubuntu Server installiert, das ging alles probelmlos.

Nach dem "reboot" , kam dann sofort der Fehler:

CentOS 7 + 8 Server sind nicht betroffen und booten ganz normal

Hier die Config:

agent: 1
bootdisk: scsi0
cores: 6
cpu: host
ide2: none,media=cdrom
kvm: 1
memory: 8192
name: nextcloud
net0: virtio=6A:77:FD:56:5A:91,bridge=vmbr0,firewall=1
numa: 0
ostype: l26
scsi0: SSD-vmdata-KVM:vm-111-disk-0,discard=on,iothread=1,size=1G,ssd=1
scsi1: SSD-vmdata-KVM:vm-111-disk-1,discard=on,iothread=1,size=40G,ssd=1
scsi2: SSD-vmdata-KVM:vm-111-disk-2,discard=on,iothread=1,size=80G,ssd=1
scsihw: virtio-scsi-single
smbios1: uuid=f28f222a-b495-4007-8a6f-97ea3924270c
sockets: 1
vga: qxl,memory=16
vmgenid: 7b5d7af0-5598-4db0-92b3-acb2e85386de

 

[fireon]

Ich kann hier nur aus vergangener Erfahrung sprechen. Anscheinend hat CentOS wie auch Suse nie alle Treiber im Kernel. Da muss irgendwie was nachinstalliert werden. Ich hab mich da nie mehr darum gekümmert, weil wir sowieso alles auf Ubuntu umgestellt haben, und damit funktioniert dann immer alles.

Jedenfalls bei Neuinstallationen wo SCSI schon als HDD ausgewählt wurde, gabs kein Problem. Eine Änderung hinterher war noch nie möglich. SUSE reagierte da gleich.

 

[franz78]

Hey,

Centos und Suse sind davon nicht betroffen. Die Ubuntu Server sind auch alle gelaufen, bis zu dem Update.
Nach einem Neustart mit Power off/on/reset war der Fehler da. (nur Ubuntu Server bzw. auch bei einer neuen installation mit virtio-scsi*)

Sobald ich das Update "pve-qemu-kvm" 5.1.x wieder einspiele - selber Fehler.

LG,

 

[fireon]

Haben hier nirgends und wir haben jede Menge davon laufen. Event. kann ja jemand anders den Fehler auch reproduzieren. Gut das du einen Workaround hast und das Update nicht einspielst.

Hmm.... wie sind denn deine VM's konfiguriert? Hast du in den VM's event. ein LVM am laufen?

 

[franz78]

hey,

ja, bei mir läuft alles auf LVM.

sda1
- /boot
sdb -
- vg0-lvx
- vg0-lvy

 

[fireon]

Aja, jetzt klingelt es. Ubuntu 20.04 wurde erst letzte Woche für Server freigegeben. Da es massive Probleme mit LVM gab. Sollte mittlerweile gefixt sein. Auf der anderen Seite stellt sich schon die Frage, was für einen Grund es geben könnte in einer VM LVM zu nutzen. Wir taten das ganz am Anfang vor vielen Jahren auch. Sind dann aber gleich dahinter gekommen das LVM aus guten Grund für physikalische Maschinen und nicht für VM's gedacht ist.

Falls ich dir nen Tipp geben sollte wie wir das einfach lösen, lass es mich wissen.

 

[ptitgnu]

Hallo,

Entschuldigung, ich spreche kein Deutsch und übersetze daher mit Google Übersetzer

Ich habe hier das gleiche Problem (GR seit pve-qemu-kvm-5.1.0-x)...
Ich denke, es hängt mit diesem Commit zusammen.

In meiner Konfiguration habe ich eine separate virtuelle Festplatte für GRUB und andere Datenträger für jede Partition (einfacher zu Resize).
Und seit diesem Commit ignoriert SeaBIOS alle virtuellen VirtIO SCSI-Festplatten außer der Bootdisk. GRUB kann also nur (hd0) sehen.

Ich musste meine Konfiguration so ändern, dass alle GRUB-Dateien und Kernel auf derselben virtuellen Festplatte enthalten waren.
Seit dieser Änderung kann es wieder booten .

Sie können die Datei /usr/share/kvm/bios-256k.bin auch durch die ursprüngliche Datei 1.13.0 ersetzen (ohne das letzte Festschreiben) aber es ist keine langfristige Lösung... (nur zum testen).

Ich hoffe, das wird helfen...

 

[franz78]

Hey ptignu,

ich habe meine Layout nach deinen Vorgaben geändert und jetzt booten die VM's auch mit dem neuen "pve-qemu-kvm-5.1.0.x

Danke für deine Hilfe.

@fireon: Dein Tip würde mich schon interessieren. Wobei ich nicht ganz verstehe, warum man LVM nicht auf VM's einsetzen sollte. Bringt ja eigentlich nur Vorteile

LG

 

[fireon]

Dein Tip würde mich schon interessieren. Wobei ich nicht ganz verstehe, warum man LVM nicht auf VM's einsetzen sollte. Bringt ja eigentlich nur Vorteile

Tatsächlich und welche wären deiner Meinung nach?

 

[franz78]

wir schreiben z.b. den LVM header direkt auf die Platte z.b. sdb und daher kann ich jederzeit jede disk/vg/lv sehr leicht vergrößern / verkleiner oder abbauen.

also VM disk erweitern - > blockdev --rereadpt > pvresize > lvresize - fertig

lvm Snapshots finde ich praktisch.
pvmove: kann auch ein Segen sein

 

[fireon]

Ich wusste das du das sagst Ist natürlich auch eine gut Möglichkeit, klar! Wir hier durften lernen das die LVM Methode auf PHY Maschinen sehr gut ist, bei virtualisierten Maschinen jedoch kann das zu ziemlich nervigen Dingen führen. z.b.

• Wenn schon direkt in der VM vergrößert wird, weist du natürlich schon vorher den möglichen gesamten Speicherplatz zu, das führt dazu dass, obwohl noch nicht verbrauchter Speicherplatz für neue Maschinen nicht mehr zugewiesen werden kann
• Somit muss ein LVM zuerst verkleinert werden
• Die Überwachung, und Vorausberechnung für weiteren Speicherplatz oder verbrauchten Speicherplatz wird mit Monitoringtools komplexer und un-transparenter.
• Die Bedienung ist für so manchen Usern, die mit den Dingen noch nichts zu tun hatten, schwerer bis unmöglich
• Das ganze erscheint durch den genannten Punkten nicht so flexibel.

Nun ein anderer Ansatz den wir nun seit Jahren in unserer IT nach LVM pflegen. Gründe dafür waren diese:

• Pro Partition eine virtuelle HDD/SSD
• Somit wird nicht unnötig viel Speicherplatz zugewiesen
• Die Vergrößerung erfolgt mit ein paar Klicks mit der Maus auf Proxmox
• In der VM erfolgt die Vergrößerung (auch bei nicht grafischen Servern) mit Gparted über SSHX mit der Maus online
• Damit ist man flexibler, besetzt nicht gleich den ganzen Speicher, und ja auch Windowsadmins können es bedienen