CT startet nach CT-Update nicht mehr

F

fowr0yl

Member
Mar 15, 2022
60
9
13
64
Braunschweig
Hallo,
bin auf die irrwitzige Idee gekommen über Weihnachten meinen Proxmox Server von 7.4.16 auf 8.3.2 heben zu wollen.
Gestartet bin ich mit der Aktualiserung aller VM's und Container. Das ist aber schon beim 2. Container schief gegangen :(
Glücklicherweise hatte ich direkt vor der Aktion von allen CT's und VM's Snapshots erstellt.

Vielleicht muss ich noch erwähnen, das ich einige Container mit Manjaro Linux verwende. Als ich die Container erstellt habe, gab es für einige Dinge keine Debian Pakete, so das ich diese hätte selbst erstellen müssen um eine konsitente Paketverwaltung zu bekommen. Da ich auf dem Deskop durchgängig Manjaro verwende, die Pakete dort vorhanden und funktionsfähig waren, wollte ich dann Manjo CT's. Die gab es aber nicht als Template. Also habe ich ArchLinux genommen und den CT dann kurzerhand auf Manjaro umgebaut. Bislang stellte das auch nie ein Problem dar.

Die Probleme die sich jetzt einstellten sind sowohl auf 7.4.16 (meine "Produktions-Maschine") als auch auf 8.3.2 (Testmaschine) in identischer Weise vorhanden.
Alle weiteren Ausführungen habe ich auf der Testmaschine durchgeführt.

# pveversion -v
Code: 
proxmox-ve: 8.3.0 (running kernel: 6.8.12-2-pve)
pve-manager: 8.3.2 (running version: 8.3.2/3e76eec21c4a14a7)
proxmox-kernel-helper: 8.1.0
pve-kernel-5.15: 7.4-12
proxmox-kernel-6.8: 6.8.12-5
proxmox-kernel-6.8.12-5-pve-signed: 6.8.12-5
proxmox-kernel-6.8.12-2-pve-signed: 6.8.12-2
proxmox-kernel-6.8.4-2-pve-signed: 6.8.4-2
proxmox-kernel-6.5.13-6-pve-signed: 6.5.13-6
proxmox-kernel-6.5: 6.5.13-6
proxmox-kernel-6.5.13-5-pve-signed: 6.5.13-5
pve-kernel-5.15.149-1-pve: 5.15.149-1
ceph-fuse: 16.2.15+ds-0+deb12u1
corosync: 3.1.7-pve3
criu: 3.17.1-2
glusterfs-client: 10.3-5
ifupdown2: 3.2.0-1+pmx11
ksm-control-daemon: 1.5-1
libjs-extjs: 7.0.0-5
libknet1: 1.28-pve1
libproxmox-acme-perl: 1.5.1
libproxmox-backup-qemu0: 1.4.1
libproxmox-rs-perl: 0.3.4
libpve-access-control: 8.2.0
libpve-apiclient-perl: 3.3.2
libpve-cluster-api-perl: 8.0.10
libpve-cluster-perl: 8.0.10
libpve-common-perl: 8.2.9
libpve-guest-common-perl: 5.1.6
libpve-http-server-perl: 5.1.2
libpve-network-perl: 0.10.0
libpve-rs-perl: 0.9.1
libpve-storage-perl: 8.3.3
libspice-server1: 0.15.1-1
lvm2: 2.03.16-2
lxc-pve: 6.0.0-1
lxcfs: 6.0.0-pve2
novnc-pve: 1.5.0-1
proxmox-backup-client: 3.3.2-1
proxmox-backup-file-restore: 3.3.2-2
proxmox-firewall: 0.6.0
proxmox-kernel-helper: 8.1.0
proxmox-mail-forward: 0.3.1
proxmox-mini-journalreader: 1.4.0
proxmox-widget-toolkit: 4.3.3
pve-cluster: 8.0.10
pve-container: 5.2.3
pve-docs: 8.3.1
pve-edk2-firmware: 4.2023.08-4
pve-esxi-import-tools: 0.7.2
pve-firewall: 5.1.0
pve-firmware: 3.14-2
pve-ha-manager: 4.0.6
pve-i18n: 3.3.2
pve-qemu-kvm: 9.0.2-4
pve-xtermjs: 5.3.0-3
qemu-server: 8.3.3
smartmontools: 7.3-pve1
spiceterm: 3.3.0
swtpm: 0.8.0+pve1
vncterm: 1.8.0
zfsutils-linux: 2.2.6-pve

Nach dem Update des Containers lief zunächst noch alles wunderbar. Nachdem ich den CT dann aber gestoppt hatte um ein Backup und einen neuerlichen Snapshot anzufertigen, ließ sich der CT nicht mehr starten. Es kam eine Fehlermeldung:
Code: 
run_buffer: 571 Script exited with status 2
lxc_init: 845 Failed to run lxc.hook.pre-start for container "100"
__lxc_start: 2034 Failed to initialize container "100"

Dann noch mal von der Konsole
# pct start 100 --debug
Code: 
run_buffer: 571 Script exited with status 2
lxc_init: 845 Failed to run lxc.hook.pre-start for container "100"
__lxc_start: 2034 Failed to initialize container "100"
d 0 hostid 100000 range 65536
INFO     lsm - ../src/lxc/lsm/lsm.c:lsm_init_static:38 - Initialized LSM security driver AppArmor
INFO     utils - ../src/lxc/utils.c:run_script_argv:587 - Executing script "/usr/share/lxc/hooks/lxc-pve-prestart-hook" for container "100", config section "lxc"
DEBUG    utils - ../src/lxc/utils.c:run_buffer:560 - Script exec /usr/share/lxc/hooks/lxc-pve-prestart-hook 100 lxc pre-start produced output: unknown ID 'manjaro' in /etc/os-release file, trying fallback detection

DEBUG    utils - ../src/lxc/utils.c:run_buffer:560 - Script exec /usr/share/lxc/hooks/lxc-pve-prestart-hook 100 lxc pre-start produced output: unable to detect OS distribution

ERROR    utils - ../src/lxc/utils.c:run_buffer:571 - Script exited with status 2
ERROR    start - ../src/lxc/start.c:lxc_init:845 - Failed to run lxc.hook.pre-start for container "100"
ERROR    start - ../src/lxc/start.c:__lxc_start:2034 - Failed to initialize container "100"
INFO     utils - ../src/lxc/utils.c:run_script_argv:587 - Executing script "/usr/share/lxcfs/lxc.reboot.hook" for container "100", config section "lxc"
startup for container '100' failed

Also habe ich mir erst mal die config angesehen:
# pct config 100
Code: 
arch: amd64
cores: 2
features: fuse=1,nesting=1
hostname: CUPS
memory: 2048
net0: name=eth0,bridge=vmbr0,gw=192.168.200.1,hwaddr=02:EE:66:09:31:09,ip=192.168.200.217/24,type=veth
onboot: 1
ostype: archlinux
rootfs: local-btrfs:100/vm-100-disk-0.raw,size=8G
swap: 512
unprivileged: 1

Gemäß der Debug-Ausgabe meckert Proxmox ja über den Inhalt von /etc/os-release. Also habe ich mir auch die angesehen:
# cat /etc/os-release
Code: 
NAME="Manjaro Linux"
PRETTY_NAME="Manjaro Linux"
ID=manjaro
ID_LIKE=arch
BUILD_ID=rolling
ANSI_COLOR="32;1;24;144;200"
HOME_URL="https://manjaro.org/"
DOCUMENTATION_URL="https://wiki.manjaro.org/"
SUPPORT_URL="https://forum.manjaro.org/"
BUG_REPORT_URL="https://docs.manjaro.org/reporting-bugs/"
PRIVACY_POLICY_URL="https://manjaro.org/privacy-policy/"
LOGO=manjarolinux

Ok, jetzt einen Rollback auf den letzten Snapshot. Interessanterweise meckert er auch hier eine "unknown" ID an, startet aber problemlos.
# pct start 100 --debug
Code: 
INFO     confile - ../src/lxc/confile.c:set_config_idmaps:2273 - Read uid map: type u nsid 0 hostid 100000 range 65536
INFO     confile - ../src/lxc/confile.c:set_config_idmaps:2273 - Read uid map: type g nsid 0 hostid 100000 range 65536
INFO     lsm - ../src/lxc/lsm/lsm.c:lsm_init_static:38 - Initialized LSM security driver AppArmor
INFO     utils - ../src/lxc/utils.c:run_script_argv:587 - Executing script "/usr/share/lxc/hooks/lxc-pve-prestart-hook" for container "100", config section "lxc"
DEBUG    utils - ../src/lxc/utils.c:run_buffer:560 - Script exec /usr/share/lxc/hooks/lxc-pve-prestart-hook 100 lxc pre-start produced output: unknown ID 'manjaro' in /etc/os-release file, trying fallback detection

INFO     cgfsng - ../src/lxc/cgroups/cgfsng.c:unpriv_systemd_create_scope:1498 - Running privileged, not using a systemd unit
DEBUG    seccomp - ../src/lxc/seccomp.c:parse_config_v2:664 - Host native arch is [3221225534]
INFO     seccomp - ../src/lxc/seccomp.c:parse_config_v2:815 - Processing "reject_force_umount  # comment this to allow umount -f;  not recommended"
INFO     seccomp - ../src/lxc/seccomp.c:do_resolve_add_rule:532 - Set seccomp rule to reject force umounts
...

Dann wieder aktualisiert, und gleiches Fehlerbild wie am Anfang.
Dann habe ich die /etc/os-release manipuliert und bei der ID "manjao" durch "archlinux" ersetzt.
Code: 
NAME="Manjaro Linux"
PRETTY_NAME="Manjaro Linux"
ID=archlinux
ID_LIKE=arch
BUILD_ID=rolling
ANSI_COLOR="32;1;24;144;200"
HOME_URL="https://manjaro.org/"
DOCUMENTATION_URL="https://wiki.manjaro.org/"
SUPPORT_URL="https://forum.manjaro.org/"
BUG_REPORT_URL="https://docs.manjaro.org/reporting-bugs/"
PRIVACY_POLICY_URL="https://manjaro.org/privacy-policy/"
LOGO=manjarolinux

Und siehe da, der CT startet wieder und läuft einwandfrei.

Bleibt meine Frage:
Warum startet der CT vor dem Update mit der Fehlermeldung, nach dem Update aber gar nicht. Und das bei unveränderter Proxmox Umgebung.
Warum muss in der CT config ein Betriebssystem stehen, wenn es doch scheinbar gar nicht relevant ist?

VG
Henning
 
  • Like
Reactions: waltar
Irrwitzige Idee der Developer, weil es ja eh (scheinbar) nicht relevant ist, wenn es nun wieder läuft. Nicht drüber nachdenken, wenn du die Lösung gefunden hast :)
 
Spannend btrfs zu verwenden, obwohl das nicht stable ist.
Ich hatte es auch mal über MDADM als Radi1 mit2x 1TB HDD in Benutzung und es lief wie ein "paar Nüsse".
Heute als ZFS, mit SSD ZFS special device, ZFS ZIL/SLOG und einen ZFS Cache. Damit kann ich leben.
 
Also ich verwende das BTRFS hier seit 2020 als primäres Dateisystem mit 2 NVME Speichern im Raid1 Modus.
Die Entscheidung für BTRFS ist nach ein paar Performance Tests gefallen. BTRFS war um ein mehrfaches schneller als ZFS bei gleichzeitig geringerem Speicherverbrauch. Daher liegt das Betriebssystem und die VM's, die ständig in Benutzung sind auf BTRFS.
War am Anfang etwas fummelig, da das System zunächst nach Ausfall (Ausbau) einer NVME nicht mehr gebootet hat. Aber das isch Schnee von gestern.
BTRFS mit mdadm Raid1 ist aus meiner Sicht unsinnig und war daher nie eine Option für mich.
Da ich mit ZFS schon in anderen Projekte Erfahrung gesammelt hatte, und ich vom Handling nach wie vor begeistert bin, habe ich noch einen ZFS raidz1 Pool mit 3 SSD's in der Maschine. Hier liegt alles was nicht ganz so performance kritisch ist.
Alle ZFS Volumes werden mit zrep.sh auf eine 2. Maschine repliziert.
Nervig ist nur, das man von CT's die auch Verzeichnisse / Volumes im ZFS gemountet haben, keine Snapshots ziehen kann....
 
fowr0yl said:
Nervig ist nur, das man von CT's die auch Verzeichnisse / Volumes im ZFS gemountet haben, keine Snapshots ziehen kann...
Click to expand...
??? Wieso ? Die Images/disks der CT's (=LXC's) sind doch selbst Volumes wo snapshot geht und gemountete Verzeichnisse sind doch Datasets, die auch sleber snapshots machen ... und gemountete Daten in LXC/VM sind doch recht oft - dann würde das ja keiner machen ?!?
 
Wieso frage ich mich auch. Ist aber so.

Immer wenn du in deiner CT config einen Mount-point definierst, also so etwas hier:
Code: 
mp0: /zPool/mma,mp=/zPool/mma,shared=1,replicate=0
Dann kannst du die Snapshot Funktion von Proxmox nicht nutzen. Dabei ist es ganz egal, welche Art von Dateisystem dahinter steht. Finde ich ziemlich doof. Habe mir ein Script gebaut, das den CT herunterfährt, die Config modifiziert dann die Snapshots sowohl com CT, als auch vom gemounteten Device zieht, dann die Config wieder zurückändert und den CT neu startet. Bedeutet aber immer ein paar Sekunden Downtime.
 
Snapshot im filesystem (ohne pve Mechanismus) ziehen und dafür den CT nur übergangsweise dafür die Cpuzeit entziehen und danach wieder freigeben, Sekundensache.
 
You must log in or register to reply here.
Top Bottom