LXC reboot fehler (Autostart funktioniert)

indiana

Member
Sep 3, 2021
4
0
6
Moin Zusammen,

meine Linux Erfahrung ist eher erweiterter Anfänger, daher schlagt mich bitte nicht, wenn ich etwas falsch ausdrücke oder etwas nicht kenne.

Ich wollte schon einige Zeit lang von Docker Containern auf meiner alten DS412+ weg. Diese sollen als VMs / Container auf einem NUC und der DS als Massenspeicher laufen.
Akut ist dies nun nochmal durch ein maintence release des nextcloud containers angestoßen worden. Dort sollen kernel dependencies fehlen und ein zurück zur alten version nach initiiertem update ist nicht möglich :oops:

HW Zusammengefasst:
  • Synology DS 412+
    Viel Speicher ;)
  • NUC8i5BEK
    • 500 GB SSD
    • 32 GB RAM
Die PVE installation war schonmal easy soweit.
  • ZFS Raid 0
    Erst schienn dies die sinnvollste Wahl, doch nach einigen zufälligen Posts über das einbinden von Storages bin ich nicht mehr so sicher. Doch erstmal wollte ich es nicht mehr ändern.
  • Fixed IP (Gateway, DNS)
  • No subscription repo
  • Aktuell 2 CIFS Storages eingebunden (Backup (Dump) und einer (Image und Container) für die nextcloud installation)
    CIFS aus dem grunde, da ich auch im privaten LAN die sicherheit der Benutzeranmeldung nutzen möchte.
  • Update / Upgrade des Knotens ist durchgeführt
Der LXC für die nextcloud
  • Ubuntu 21.04 template
  • unprivileged true
  • keyctl true
  • nesting true.

Nach Anlage eines Ordner im Container und dem zulassen von SSH Verbindungen, habe ich den Mount Point hinzugefügt. Dieser hat auch ein RAW file auf der DS angelegt. Es saht also soweit alles gut aus.
Nach einen reboot des Containers hat dieser nun scheinbar keinen Zugriff mehr auf das RAW file.
Interessant ist jedoch, starte ich den Knoten neu (Container steht auf start at boot), wird der mount point eingebunden o_O
Sobald ich jedoch, egal ob die WebUI oder Konsole, den container neu starte, tut dieser es nicht.
Wen ich den mount point entferne, kann der Container auch wieder starten. Es liegt also an diesem jedochh warum?
Reboot der DS macht übrigens keinen Unterschied.

Im Syslog (siehe unten) sehe ich leider nicht so viel, was mich weiterbringt. Primär steht dort, dass der startup fehlgeschlagen ist und die Ursache ein Zugriffsfehler ist. Soweit so gut, doch warum?
Ein paar Meldungen RRD / RRDC (siehe Log unten), bei anderen Versuchen, deuten evtl. auf ein NTP bzw. Zeitproblem hin. Doch erscheint mir die Reihenfolge als Fehlerursache zu spät und ich weiß auch nicht genau was ich machen müsste. Der gelöste Post rrdc-update-error hat mich leider nicht weitergebracht oder ich habe etwas übersehen.
Der Knoten und die DS haben übrigens die gleiche Zeit.
Nichts desto trotz habe ich chrony noch meine DS als lokalen und bevorzugten NTP-server hinzugefügt. Nur nebenbei, in dem pve 7 Manual steht noch "systemd".
Im Container ist esallerdings "systemd". In diesem habe ich daher die DS unter
Code:
/etc/systemd/timesyncd.conf
eingetragen und die Zeitzone angepasst
Code:
dpkg-reconfigure tzdata

Hat jemand eine Idee woran das liegen und wie man es lösen kann?
Leider finde ich selber keine Lösung oder suche einfach nach dem falschem.

Her einmal das Log vom letzten start Versuch:
Code:
Sep 16 09:52:18 pve1 pmxcfs[1092]: [status] notice: RRDC update error /var/lib/rrdcached/db/pve2-storage/pve1/Backup: -1
Sep 16 09:52:18 pve1 pmxcfs[1092]: [status] notice: RRDC update error /var/lib/rrdcached/db/pve2-storage/pve1/nextcloud: -1
Sep 16 09:52:18 pve1 pmxcfs[1092]: [status] notice: RRDC update error /var/lib/rrdcached/db/pve2-storage/pve1/local: -1
Sep 16 09:52:18 pve1 pmxcfs[1092]: [status] notice: RRD update error /var/lib/rrdcached/db/pve2-storage/pve1/local: /var/lib/rrdcached/db/pve2-storage/pve1/local: illegal attempt to update using time 1631778737 when last update time is 1631778737 (minimum one second step)
Sep 16 09:52:18 pve1 pmxcfs[1092]: [status] notice: RRDC update error /var/lib/rrdcached/db/pve2-storage/pve1/local-zfs: -1
Sep 16 09:52:18 pve1 pmxcfs[1092]: [status] notice: RRD update error /var/lib/rrdcached/db/pve2-storage/pve1/local-zfs: /var/lib/rrdcached/db/pve2-storage/pve1/local-zfs: illegal attempt to update using time 1631778737 when last update time is 1631778737 (minimum one second step)
Sep 16 09:52:25 pve1 kernel: CIFS: VFS: No writable handle in writepages rc=-9

-----------------------------------------------------------------------------------------------------------------

Sep 16 10:54:44 pve1 systemd[1]: Started PVE LXC Container: 100.
Sep 16 10:54:44 pve1 kernel: loop0: detected capacity change from 0 to 125829120
Sep 16 10:54:44 pve1 kernel: EXT4-fs warning (device loop0): ext4_multi_mount_protect:320: MMP interval 42 higher than expected, please wait.

Sep 16 10:55:00 pve1 systemd[1]: Starting Proxmox VE replication runner...
Sep 16 10:55:00 pve1 systemd[1]: pvesr.service: Succeeded.
Sep 16 10:55:00 pve1 systemd[1]: Finished Proxmox VE replication runner.
Sep 16 10:55:29 pve1 kernel: blk_update_request: I/O error, dev loop0, sector 0 op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 0
Sep 16 10:55:29 pve1 kernel: Buffer I/O error on dev loop0, logical block 0, lost sync page write
Sep 16 10:55:29 pve1 kernel: EXT4-fs (loop0): I/O error while writing superblock
Sep 16 10:55:29 pve1 kernel: EXT4-fs (loop0): mount failed
Sep 16 10:55:29 pve1 pvestatd[1213]: unable to get PID for CT 100 (not running?)
Sep 16 10:55:29 pve1 pvedaemon[1241]: unable to get PID for CT 100 (not running?)
Sep 16 10:55:29 pve1 pvedaemon[30235]: startup for container '100' failed
Sep 16 10:55:29 pve1 pvedaemon[1240]: <root@pam> end task UPID:pve1:0000761B:0007AC13:61430653:vzstart:100:root@pam: startup for container '100' failed
Sep 16 10:55:30 pve1 pvestatd[1213]: status update time (38.363 seconds)
Sep 16 10:55:30 pve1 systemd[1]: pve-container@100.service: Main process exited, code=exited, status=1/FAILURE
Sep 16 10:55:30 pve1 systemd[1]: pve-container@100.service: Failed with result 'exit-code'.
Sep 16 10:55:38 pve1 kernel: CIFS: VFS: No writable handle in writepages rc=-9
Sep 16 10:56:00 pve1 systemd[1]: Starting Proxmox VE replication runner...
Sep 16 10:56:00 pve1 systemd[1]: pvesr.service: Succeeded.
Sep 16 10:56:00 pve1 systemd[1]: Finished Proxmox VE replication runner.
 
Last edited:
Moin Zusammen,

Den Reboot Fehler habe ich nicht beheben können. Allerdings bin ich bei der Suche nach alternativen Möglichkeiten meine DS einzubinden auf die manuell verbindbaren Mount Points gestoßen. D.h. den Pfad über das WebUI hinzugefügt und dann manuell eingreifen.

https://pve.proxmox.com/wiki/Unprivileged_LXC_containers
Die Berechnung der beutzten UID und minus dem Max 65535 geht leider nicht so klar aus dem Wiki hervor, doch scheint logisch.

Einziges Problem welches ich nun noch hatte, und schon fast vermutete, wurde auch durch das Forum schon gelöst.
Die UID des neuen users im LXC muss mit der Ziel UID, also der des Benutzers auf der DS, übereinstimmen.

:)
 

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!