[SOLVED] Letzter Paketupdate

[BigBen]

Hallo,

seit dem letzten Paketupdate von Proxmox 5.1-51 können keine CTs mehr gestartet werden.

Des weiteren ist die Statusanzeige auf der Web-Oberfläche der CT-Systeme nur mit einem "?"-Markiert worden. (siehe Anhang Proxmox LXC Status.jpg)

Kann mir jemand mitteilen, welche Änderungen die Proxmox-Experten diesesmal wieder ausgegerollt haben?

Hier einige Auszüge von den Fehlermeldungen:

lxc-start: 103: confile.c: parse_line: 2340 Unknown configuration key "lxc.tty"
lxc-start: 103: parse.c: lxc_file_for_each_line_mmap: 102 Failed to parse config: lxc.tty = 2
Failed to load config for 103
Failed to create lxc_container

Beim Booten eines Debian-Systems wird neuerdings eine Fehlermeldung mehrfach angezeigt:
Error: either "dev" is duplicate, or "-tentative" is a garbage.
Could not get a link-local address
Failed to bring up eth0.

In der LXC-Configuration ist auch öfters ein gesondertes LXC-Apparmor-Profil angegegeben worden:
lxc.apparmor.profile: lxc-default-cgns-modified
Dieses Profil wird auch nicht mehr gefunden, obwohl die Datei selbst im Pfad ...

/etc/apparmor.d/lxc/

... vorhanden ist.

Bei manchen CTs wird beim Starten eine Vielzehl von Fehlermeldungen ausgegeben:

Beispiel:

lxc-start: 123: cgroups/cgfsng.c: create_path_for_hierarchy: 1752 Path "/sys/fs/cgroup/rdma//lxc/123" already existed.
lxc-start: 123: cgroups/cgfsng.c: cgfsng_create: 1862 Failed to create cgroup "/sys/fs/cgroup/rdma//lxc/123"
lxc-start: 123: cgroups/cgfsng.c: create_path_for_hierarchy: 1752 Path "/sys/fs/cgroup/rdma//lxc/123-1" already existed.
lxc-start: 123: cgroups/cgfsng.c: cgfsng_create: 1862 Failed to create cgroup "/sys/fs/cgroup/rdma//lxc/123-1"
lxc-start: 123: lsm/lsm.c: lsm_process_label_set_at: 167 No such file or directory - Failed to set AppArmor label "lxc-default-cgns-modified"
lxc-start: 123: lsm/apparmor.c: apparmor_process_label_set: 243 No such file or directory - Failed to change apparmor profile to lxc-default-cgns-modified
lxc-start: 123: sync.c: __sync_wait: 57 An error occurred in another process (expected sequence number 5)
lxc-start: 123: start.c: __lxc_start: 1883 Failed to spawn container "123"
The container failed to start.
Additional information can be obtained by setting the --logfile and --logpriority options.

Vor dem letzten Paket-Update traten noch keine Fehler auf. In der Weboberfläche wurde nauch alle Status-Anzeigen fehlerfrei angezeigt. Nur nah dem Paket-Update traten diese Fehler auf.

Was unternommen wurde, nach dem Paket-Update:

Der Service Pve-ProxmoxProxy wurde neu gestartet.
Nachdem das nichts gebracht hatte wurde das ganze Proxmox-System neu gebootet.

Weiß jemand, was zu machen ist, damit das System wieder ordnungsgemäß funktioniert?

 

[tom]

Bitte auch den genauen Versionsstand posten:

> pveversion -v

 

[BigBen]

Hallo,

sorry... hier ist die Version:

proxmox-ve: 5.1-42 (running kernel: 4.13.16-2-pve)
pve-manager: 5.1-51 (running version: 5.1-51/96be5354)
pve-kernel-4.13: 5.1-44
pve-kernel-4.13.16-2-pve: 4.13.16-47
pve-kernel-4.13.16-1-pve: 4.13.16-46
pve-kernel-4.13.13-6-pve: 4.13.13-42
pve-kernel-4.13.13-5-pve: 4.13.13-38
pve-kernel-4.13.13-4-pve: 4.13.13-35
pve-kernel-4.13.13-3-pve: 4.13.13-34
pve-kernel-4.4.98-3-pve: 4.4.98-102
pve-kernel-4.4.83-1-pve: 4.4.83-96
pve-kernel-4.4.76-1-pve: 4.4.76-94
pve-kernel-4.4.67-1-pve: 4.4.67-92
pve-kernel-4.4.62-1-pve: 4.4.62-88
pve-kernel-4.4.59-1-pve: 4.4.59-87
pve-kernel-4.4.49-1-pve: 4.4.49-86
pve-kernel-4.4.44-1-pve: 4.4.44-84
pve-kernel-4.4.40-1-pve: 4.4.40-82
pve-kernel-4.4.35-2-pve: 4.4.35-79
pve-kernel-4.4.35-1-pve: 4.4.35-77
pve-kernel-4.4.24-1-pve: 4.4.24-72
pve-kernel-4.4.21-1-pve: 4.4.21-71
pve-kernel-4.4.19-1-pve: 4.4.19-66
pve-kernel-4.4.16-1-pve: 4.4.16-64
pve-kernel-4.4.13-2-pve: 4.4.13-58
pve-kernel-4.4.13-1-pve: 4.4.13-56
pve-kernel-4.4.10-1-pve: 4.4.10-54
pve-kernel-4.4.8-1-pve: 4.4.8-52
pve-kernel-4.4.6-1-pve: 4.4.6-48
pve-kernel-4.2.8-1-pve: 4.2.8-41
pve-kernel-4.2.6-1-pve: 4.2.6-36
corosync: 2.4.2-pve4
criu: 2.11.1-1~bpo90
glusterfs-client: 3.8.8-1
ksm-control-daemon: 1.2-2
libjs-extjs: 6.0.1-2
libpve-access-control: 5.0-8
libpve-apiclient-perl: 2.0-4
libpve-common-perl: 5.0-30
libpve-guest-common-perl: 2.0-14
libpve-http-server-perl: 2.0-8
libpve-storage-perl: 5.0-18
libqb0: 1.0.1-1
lvm2: 2.02.168-pve6
lxc-pve: 3.0.0-2
lxcfs: 3.0.0-1
novnc-pve: 0.6-4
proxmox-widget-toolkit: 1.0-15
pve-cluster: 5.0-25
pve-container: 2.0-22
pve-docs: 5.1-17
pve-firewall: 3.0-8
pve-firmware: 2.0-4
pve-ha-manager: 2.0-5
pve-i18n: 1.0-4
pve-libspice-server1: 0.12.8-3
pve-qemu-kvm: 2.11.1-5
pve-xtermjs: 1.0-2
qemu-server: 5.0-25
smartmontools: 6.5+svn4324-1
spiceterm: 3.0-5
vncterm: 1.5-3
zfsutils-linux: 0.7.7-pve1~bpo9

 

[BigBen]

Hallo,

beim Monitoring ist folgende Warnung beim Proxmox-System aufgelaufen:

CRIT - 1 CRIT messages (Last worst: "May 11 10:49:28 proxmox kernel: [ 15.584115] softdog: initialized. soft_noboot=0 soft_margin=60 sec soft_panic=0 (nowayout=0)")

Mir sagt die Meldung wenig. Ich poste diese dennoch, da diese vielleicht dennoch wichtig sein könnte.


Nachdem die CT-Systeme zum größten Teil nicht mehr gestartet werden können, wurden diese neu angelegt mit fast identischen Parametern.

Einzig die Angabe "lxc.apparmor.profile" wurde weg gelassen, da das Profil anscheinend nicht mehr kompatibel mit der neuen Version ist.

Die Disk--Image-Dateien wurden ebenfalls kopiert auf die neuen CTs. Beim Starten traten keine Probleme auf.

Offen ist noch der Anzeige-Fehler in der Web-Oberfläche (Screenshoot-siehe mein ersten Posting). Hier hat sich nichts geändert. Die neu angelegten CTs werden ebenfalls mit dem Status "?" gelistet.

 

[fireon]

Ja das kenne ich, hab ich seit beginn Kernel 4.15. Meist laufen die CT's zwar. Aber wenn man diese stoppt oder mal ein Backup zurückspielt... kommt es immer wieder vor das man die CT's nicht mehr starten kann. Dann half am Anfang noch die Prozesse zu beenden. Seit dem letzten Kernelupdate hilft nur mehr ein Reboot des Hosts. Ich habe wieder auf Kernel 4.10 downgegraded.

 

[BigBen]

Zwischenzeitlich wurde die Ursache gefunden:

Der Service pvestatd hat gemeldet dass diverse Pfade nicht mehr vorhanden seien:

Beispiel:
/sys/fs/cgroup/blkio/lxc/101/ns/blkio.throttle.io_service_bytes
/sys/fs/cgroup/blkio/lxc/102/ns/blkio.throttle.io_service_bytes
/sys/fs/cgroup/blkio/lxc/103/ns/blkio.throttle.io_service_bytes

Das SysLog wurde von Meldungen in dieser Art überflutet.

Erst nach dem Entfernen des betreffenden CT-Systems läuft der Service pveStatd wieder fehlerfrei.

Die entfernten CT-Systeme wurden unter neuen Nummern wieder angelegt.

Das Host brauchte während dieser Aktion nicht reBootet werden.

 

[fireon]

Die entfernten CT-Systeme wurden unter neuen Nummern wieder angelegt.

Was meinst du damit? Den Prozess, oder ein Backup?

 

[BigBen]

Hallo,

damit meinte ich, dass die Config-Dateien lediglich umbenannt wurden.

Zusätzlich sind die Festplatten-Images ebenfalls verschoben worden, damit die neue CT-Nummer leichter wieder mit dem neuen CT-System zugeordnet werden können.

 

[TechLineX]

Ich habe dasselbe Problem leider auch. Klar kann man die Container neu booten, ändert aber nichts daran, dass die Container unter der bisherigen PID laufen.