[SOLVED] Container starten nach Proxmox Neustart nicht mehr

[furia666]

Hallo,

ich habe ein mittleres Problem und habe keine so richtige Ahnung, woran es liegt. Habe vor kurzem einen neuen Rechner mit Proxmox aufgesetzt. Das System liegt auf einer kleinen SSD mit ext4 Dateisystem, für die VMs und Container habe ich einen zfs-Mirror mit 2x1TB SSDs aufgesetzt. Proxmox laeuft mit der aktuellen Version 6.2-6. Habe ein paar Container und VMs per Restore von meinem alten Proxmox System importiert und auch ein paar neu erstellt. Laeuft soweit alles. Nun habe ich ein paar Mal neu gestartet (der Server laeuft aktuell noch nicht 24/7) und nach Neustart starten saemtliche Container nicht mehr. VMs gehen problemlos.

Ein beispielhaftes cat /tmp/lxc-101.log | grep ERROR ergibt folgenden Output, aus dem ich leider nicht ganz schlau werde:

lxc-start ID 20200623200816.407 ERROR    lxc_start - tools/lxc_start.c:main:268 - No container config specified
lxc-start 101 20200623200827.565 ERROR    conf - conf.c:mount_autodev:1074 - Permission denied - Failed to create "/dev" directory
lxc-start 101 20200623200827.566 ERROR    conf - conf.c:lxc_setup:3311 - Failed to mount "/dev"
lxc-start 101 20200623200827.566 ERROR    start - start.c:do_start:1231 - Failed to setup container "101"
lxc-start 101 20200623200827.566 ERROR    sync - sync.c:__sync_wait:41 - An error occurred in another process (expected sequence number 5)
lxc-start 101 20200623200827.566 ERROR    start - start.c:__lxc_start:1957 - Failed to spawn container "101"
lxc-start 101 20200623200828.950 ERROR    lxc_start - tools/lxc_start.c:main:308 - The container failed to start
lxc-start 101 20200623200828.950 ERROR    lxc_start - tools/lxc_start.c:main:314 - Additional information can be obtained by setting the --logfile and --logpriority options

Vielleicht weiß ja hier jemand, warum die Container nicht laufen?

 

[Stoiko Ivanov]

Wenn möglich bitte das gesamte log anhängen (speziell bei LXC debug output steht die relevante info warum ein Fehler auftritt oft 3-4 Zeilen über dem ersten ERROR).

lassen sich die container manuell starten? (i.e. container auf onboot no stellen, rebooten, dann manuell mit pct start starten)?

 

[furia666]

OK, Komplettes Logfile habe ich angehangen. Die Container lassen sich überhaupt nicht mehr starten weder über die WEB-GUI noch per Konsole manuell. Verwunderlich ist für mich halt, dass die erst liefen, ich alles eingerichtet habe und dann kann man nix mehr machen...

EDIT: Habe mir gerade mal diesen Thread durchgelesen, dort schien ein aehnliches Problem aufgetaucht zu sein. Dabei gab es beim mount -a Befehl einen Fehler, den ich auch habe:

root@Proxmox:~# zfs mount -a cannot mount '/vmpool': directory is not empty

Leider scheitere ich an der im Thread angesprochenen Lösung, da ich keine Ahnung habe, was für Dateien ich löschen soll, findmnt gibt mir nur folgendes aus:

TARGET SOURCE FSTYPE OPTIONS / /dev/mapper/pve-root │ ext4 rw,relatime,errors=remount-ro ├─/sys sysfs sysfs rw,nosuid,nodev,noexec,relatime │ ├─/sys/kernel/security securityfs securityfs rw,nosuid,nodev,noexec,relatime │ ├─/sys/fs/cgroup tmpfs tmpfs ro,nosuid,nodev,noexec,mode=755 │ │ ├─/sys/fs/cgroup/unified cgroup2 cgroup2 rw,nosuid,nodev,noexec,relatime │ │ ├─/sys/fs/cgroup/systemd cgroup cgroup rw,nosuid,nodev,noexec,relatime,xattr,name=systemd │ │ ├─/sys/fs/cgroup/cpuset cgroup cgroup rw,nosuid,nodev,noexec,relatime,cpuset │ │ ├─/sys/fs/cgroup/net_cls,net_prio cgroup cgroup rw,nosuid,nodev,noexec,relatime,net_cls,net_prio │ │ ├─/sys/fs/cgroup/hugetlb cgroup cgroup rw,nosuid,nodev,noexec,relatime,hugetlb │ │ ├─/sys/fs/cgroup/devices cgroup cgroup rw,nosuid,nodev,noexec,relatime,devices │ │ ├─/sys/fs/cgroup/perf_event cgroup cgroup rw,nosuid,nodev,noexec,relatime,perf_event │ │ ├─/sys/fs/cgroup/pids cgroup cgroup rw,nosuid,nodev,noexec,relatime,pids │ │ ├─/sys/fs/cgroup/cpu,cpuacct cgroup cgroup rw,nosuid,nodev,noexec,relatime,cpu,cpuacct │ │ ├─/sys/fs/cgroup/memory cgroup cgroup rw,nosuid,nodev,noexec,relatime,memory │ │ ├─/sys/fs/cgroup/rdma cgroup cgroup rw,nosuid,nodev,noexec,relatime,rdma │ │ ├─/sys/fs/cgroup/freezer cgroup cgroup rw,nosuid,nodev,noexec,relatime,freezer │ │ └─/sys/fs/cgroup/blkio cgroup cgroup rw,nosuid,nodev,noexec,relatime,blkio │ ├─/sys/fs/pstore pstore pstore rw,nosuid,nodev,noexec,relatime │ ├─/sys/firmware/efi/efivars efivarfs efivarfs rw,nosuid,nodev,noexec,relatime │ ├─/sys/fs/bpf none bpf rw,nosuid,nodev,noexec,relatime,mode=700 │ ├─/sys/kernel/debug debugfs debugfs rw,relatime │ ├─/sys/kernel/config configfs configfs rw,relatime │ └─/sys/fs/fuse/connections fusectl fusectl rw,relatime ├─/proc proc proc rw,relatime │ └─/proc/sys/fs/binfmt_misc systemd-1 autofs rw,relatime,fd=50,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=26320 ├─/dev udev devtmpfs rw,nosuid,relatime,size=32874464k,nr_inodes=8218616,mode=755 │ ├─/dev/pts devpts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 │ ├─/dev/shm tmpfs tmpfs rw,nosuid,nodev │ ├─/dev/mqueue mqueue mqueue rw,relatime │ └─/dev/hugepages hugetlbfs hugetlbfs rw,relatime,pagesize=2M ├─/run tmpfs tmpfs rw,nosuid,noexec,relatime,size=6586440k,mode=755 │ ├─/run/lock tmpfs tmpfs rw,nosuid,nodev,noexec,relatime,size=5120k │ ├─/run/rpc_pipefs sunrpc rpc_pipefs rw,relatime │ └─/run/user/0 tmpfs tmpfs rw,nosuid,nodev,relatime,size=6586436k,mode=700 ├─/etc/pve /dev/fuse fuse rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other ├─/mnt/pve/NAS4Free-Proxmox //192.168.178.10/Proxmox-SMB │ cifs rw,relatime,vers=3.0,cache=strict,username=colgrim,uid=0,noforceuid,gid=0,noforcegid,addr=192.168.178.10,file_mode=0755,dir_mode=0 └─/var/lib/lxcfs lxcfs fuse.lxcfs rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other

 

[Stoiko Ivanov]

cannot mount '/vmpool': directory is not empty

seems like an issue we had a couple of times here already - an initial patch for discussion is on the pve-devel mailing list:
https://pve.proxmox.com/pipermail/pve-devel/2020-June/043985.html

check https://forum.proxmox.com/threads/update-broke-lxc.59776/post-277303
for a mitigation in the meanwhile
(keep in mind that you might need to remove the 'dev'folders and empty subvolume folders that might be around on your pool's mountpoint

I hope this helps!

 

[furia666]

Worked like a charm.

 

[Stoiko Ivanov]

Glad that helped! thanks for setting the thread to 'SOLVED'

 

[His.Dudeness]

Glad that helped! thanks for setting the thread to 'SOLVED'

Good Morning!

I've got a similar issue for my lxc container after a reboot of the pve host.
(mount_autodev: 1074 Permission denied - Failed to create "/dev" directory)

The "regular" KVM VMs on the same zfs pool are starting fine, only the lxc won't.

I think the reason might not be, that the zfs cache is corrupted, but that the zfs pool is encrypted and needs to be unlocked via zfs load-key after a reboot.
Could that cause the same issue with this volume activation thing ?

what can I do to make the lxc start again after a reboot of the host?

cheers
Michael

 

[Stoiko Ivanov]

what can I do to make the lxc start again after a reboot of the host?

please create a new thread instead of replying to one already marked as solved (if the suggested solution does not work in your case)

in the new thread please provide:
* the container config (`pct config $VMID`)
* the storage configuration (`cat /etc/pve/storage.cfg`)
* other relevant information (zfs get of the parent dataset in your case)
* the debug logs when trying to start the container: https://pve.proxmox.com/pve-docs/chapter-pct.html#_obtaining_debugging_logs

Thanks