danke für den hinweis, funktioniert hier auch besser als vorher.. ( vorher war mehr failover als balancer..)

@Meister-Mopper sagte: Ich sehe die Automatismen bei Updates/Upgrades kritisch, weil man nicht mehr Herr des Systems ist. das sehe ich genau so, aber der updater sagt mir nur das ein update zur verfügung ist, nix mit automatisch. ;)

Sorry, kann weg.

Wie gesagt - war gestern nach dem Elterntaxi-Dienst zu müde, mit apt weiterzumachen... Wäre dann nach dem PVE auch die Container durchgegangen ...

@saeft_2003 sagte: hing noch ein alter tplink switch davor. dann raus damit.. wenn unifi im haus dann ÜBERALL durchgehend .. sonst hast du Netzwerkprobleme die du nicht lokalisieren kannst

MartinP sagte: Habe die VM gerade aktualisiert. Das war aufregender, als erwartet ... Nach dem "Aktualisieren" erschien erst eine Recovery Webseite. Dort habe ich das Backup aus dem Update-Prozess eingespielt. Dann war die alte Version wieder aktiv ... Die Releasenotes noch einmal gelesen... https://github.com/openccu/openccu/releases/tag/3.87.6.20260509 To complete the repartitioning in a single update cycle, version 3.87.6.20260313 or newer must already be installed. If you are updating from an older version, you may need to run the update twice for it to be installed properly. Ich hatte eine Version von 202501xy, die auch nach dem Update wieder angezeigt wurde, das deutete nach obigem darauf hin, dass ein zweiter Update-Versuch notwendig ist. Nach einem zweiten Update-Versuch schien die VM zuerst anscheinend geschrottet.. Antwortet noch auf Ping, aber weder per Putty, noch über den Browser kam man drauf ... Wollte aber keine voreiligen Schlüsse ziehen und habe erstmal etwas anderes gemacht ... Nach ca 10 Minuten war dann doch die Web-Oberfläche wieder da, und als Version wurde die aktuelle vom heutigen Tag angezeigt...

@MartinP Er ist doch schon längst weiter und hat Debian13 nativ aufgesetzt ohne Proxmox Unterbau und es läuft.

@MartinP Vielen Dank, das ist somit sehr dringlich und wird von Proxmox auch im Forum empfohlen. Die Updates laufen bei mir bereits.

Das Obige habe ich irgendwann nicht mehr zum Laufen gebracht. Folgendes funktioniert aber ersatzweise: Im PVE feststellen, wie der Coral - Stick sich manifestiert. root@pve:~# lsusb Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 002: ID 1b1f:c020 eQ-3 Entwicklung GmbH HmIP-RFUSB Bus 001 Device 003: ID 0403:6015 Future Technology Devices International, Ltd Bridge(I2C/SPI/UART/FIFO) Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 002 Device 002: ID 2109:711f VIA Labs, Inc. External Bus 002 Device 003: ID 18d1:9302 Google Inc. root@pve:~# Aktuell Bus 002/Device 003, kontrollieren... root@pve:~# ls -l /dev/bus/usb/002 total 0 crw-rw-r-- 1 root root 189, 128 Apr 30 16:02 001 crw-rw-r-- 1 root root 189, 129 Apr 30 16:02 002 crw-rw-r-- 1 root plugdev 189, 130 Apr 30 16:02 003 root@pve:~# Jetzt muss man leider im LXC-Config file basteln In /etc/pve/lxc# cat 107.conf habe ich folgende Zeile angehängt: lxc.mount.entry: /dev/bus/usb/002 dev/bus/usb/002 none bind,optional,create=dir 0,0 Damit wird das komplette obenstehende Verzeichnis in den LXC gemappt ... Das "Bäumchen-Wechsel-Dich" zwischen /dev/bus/usb/002/003 und /dev/bus/usb/002/004 ist damit egal, da frigate den kompletten /dev/bus/usb - Tree nach dem Coral-Stick durchforstet... frigate@ubuntu-frigate-privileged:~$ ls /dev/bus/usb/002 001 002 003 frigate@ubuntu-frigate-privileged:~$ ls /dev/bus/usb 002 frigate@ubuntu-frigate-privileged:~$

@saeft_2003 Die Lösung in der IT heißt immer Redundanz. Ein zweiter NUC, am besten mit einer CPU aus der gleichen Familie / Generation und du könntest die VMs sogar im laufenden Betrieb zwischen den beiden verschieben. Und immer einen Updaten, zurückschieben. So mache ich es bei mir, inklusive Replikation. Es geht auch ohne Smarthome und ioBroker bei uns, wäre dann aber schrecklich unbequem und umständlich.

@BananaJoe sagte in Proxmox Cluster oder HA: Hui, wieviel hast du denn? nur 4 :)

Ein Problem hatte ich noch Iobroker - Backups macht der backup-Adapter nur lokal, da nicht privilegierter LXC Container unter Proxmox... Im Gegensatz zu smb funktioniert aber rsync aus einem nicht privilegierten LXC Nach dem lokalen täglichen Backup gegen 02:00 startet etwas später dann cron gesteuert ein rsync-Job der das lokale Verzeichnis mit einem Verzeichnis auf der USB-Platte des Fileservers synchronisiert ... 5 * * * sshpass -p ".........." rsync -a /opt/iobroker/backups/* martin@192.168.2.84:/mnt/usbdrives/intenso1/backup/Martin/iobroker/ > /dev/null 2>&1 3 5 * * * sshpass -p "........." rsync -a /opt/iobroker/log/*.log.gz martin@192.168.2.84:/mnt/usbdrives/intenso1/backup/Martin/iobroker/Logs/ > /dev/null 2>&1 Heute morgen fehlte dann nach der gestrigen Umstellung das Backup der USB-Platte auf dem neuen Fileserver Nach dem Eingeben von... rsync -a /opt/iobroker/backups/* martin@192.168.2.84:/mnt/usbdrives/intenso1/backup/Martin/iobroker/ .... war klar, dass erstmal der fingerprint des neuen Servers abgenickt werden musste. Danach aber dann diese Fehlermeldung ... rsync: [generator] chgrp "/mnt/usbdrives/intenso1/backup/Martin/iobroker/iobroker_2026_02_17-02_40_10_backupiobroker.tar.gz" failed: Operation not permitted (1) Die neuen Files wurden aber letztendlich kopiert ... -rw-rw-r-- 1 nobody nogroup 89926 Feb 24 01:59 javascripts_2026_02_24-02_59_24_backupiobroker.tar.gz -rw-rw-r-- 1 martin smbusers 89928 Feb 25 01:57 javascripts_2026_02_25-02_57_25_backupiobroker.tar.gz User und Group unterschieden sich ... Bin nicht sicher, ob das auch vorher schon auftrat. Habe das aber jetzt mit zwei "--no-" Optionen geheilt. Keine Fehlermeldungen mehr ... martin@iobroker-test-sicher:~/gitea/iobroker_shellscripte$ rsync -a --no-owner --no-group /opt/iobroker/backups/* martin@192.168.2.84:/mnt/usbdrives/intenso1/backup/Martin/iobroker/ martin@192.168.2.84's password: martin@iobroker-test-sicher:~/gitea/iobroker_shellscripte$

@Negalein Dann sollte es besser ganz getrennt voneinander laufen. Wäre ja doof, wenn bei A alles runter fährt wenn nur bei B die Sicherung fliegt.

Ich war für Deine Frage hier das erste Mal auf diesem Weg in der Konsole der OpenCCU. Normal nehme ich PuTTY am PC oder Terminal am MacBook. Für "Notfälle" Termius am Tablet. Wobei ich bei der OpenCCU noch keinen Notfall hatte. Da sind es eher Updates der anderen VMs von der Couch aus.

War der Meinung, dass ich alle Verweise auf Enterprise getilgt/auskommentiert hätte... vielleicht verguckt...

Aktuell läuft nur auch mein WoMo Projekt parallel, da gibt es jede Menge properitären Blödsinn der in den ioBroker eingebunden werden will ;-) Habe die letzten zwei 'Tage' damit verbracht mit Hilfe von Gemini einen Gasflaschensensor per Bluetooth in IOB einzubinden, war echt zäh aber nun läufts. Ich habe mir zu 'Agent-DVR' aber mal einen leeren Container mit entsprechendem Namen angelegt, dann vergesse ich es nicht ;-)

An der Anleitung von @thomas-braun habe ich mich für alle Debian-VMs langgehangelt. Da gab es keine Probleme.

@peterfido sagte in Irgendwas verursacht 100derte Fail Logins auf meinem PVE: ProxMenuX soll ein Skript von GitHub lachladen und ungeprüft ausführen. Hast Du evtl. Ports ins Internet freigegeben? Nein habe ich getestet, von aussen kommt nix rein. Ich hab aber auch nie was konfiguriert, das irgendetwas raus darf, bzw ich von aussen aufs System. Das lag am Linux Control Adapter, ich hab den Proxmox mal raus, jetzt ist Ruhe, muss mal schauen, da stimmt ja dann wohl der Login nicht.

@Homoran Krass, der Mann hat Recht! Was man so alles rumfummelt über die Jahre. Danke für den Hinweis!

@liv-in-sky sagte in (Erled.)Proxmox - wo kommen die Daten her ?: soll ich mit mir selbst schreiben ? Wenn du selbst die Antwort gefunden hast, wäre es nicht verkehrt diese auch hier zu hinterlassen. Wenn jemand die selbe Frage hat und auf diesen [erledig] Thread stößt, ist er sicher dankbar neben der Frage auch die Antwort zu finden.