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
HW Zusammengefasst:
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
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
eingetragen und die Zeitzone angepasst
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:
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
HW Zusammengefasst:
- Synology DS 412+
Viel Speicher
- NUC8i5BEK
- 500 GB SSD
- 32 GB RAM
- 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
- 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
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
Code:
dpkg-reconfigure tzdataHat 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:
