RaspberryMatic 3.59.6.20210703 – Neue Version

[Matten Matten]

Hallo ich habe seit dem update folgende Meldungen im Log auflaufen:

Code: Alles auswählen

Jul  9 10:58:06 ccu3-webui user.notice rfkill: unblock set for id 0
Jul  9 10:58:06 ccu3-webui user.err kernel: [  785.115254] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save enabled
Jul  9 10:58:06 ccu3-webui user.err kernel: [  785.237552] pl2303 1-1.2.3:1.0: pl2303_vendor_write - failed to write [0007]: -32
Jul  9 10:58:06 ccu3-webui user.err kernel: [  785.239617] pl2303 1-1.2.3:1.0: pl2303_vendor_read - failed to read [000a]: -32
Jul  9 10:58:07 ccu3-webui user.err kernel: [  785.521943] pl2303 1-1.2.3:1.0: pl2303_vendor_write - failed to write [0007]: -32
Jul  9 10:58:07 ccu3-webui user.err kernel: [  785.524050] pl2303 1-1.2.3:1.0: pl2303_vendor_read - failed to read [000a]: -32
Jul  9 10:58:09 ccu3-webui user.notice rfkill: block set for id 0
Jul  9 10:58:18 ccu3-webui user.err kernel: [  797.032061] pl2303 1-1.2.3:1.0: pl2303_vendor_write - failed to write [0007]: -32
Jul  9 10:58:18 ccu3-webui user.err kernel: [  797.034118] pl2303 1-1.2.3:1.0: pl2303_vendor_read - failed to read [000a]: -32
Jul  9 10:58:18 ccu3-webui user.err kernel: [  797.330546] pl2303 1-1.2.3:1.0: pl2303_vendor_write - failed to write [0007]: -32
Jul  9 10:58:18 ccu3-webui user.err kernel: [  797.332572] pl2303 1-1.2.3:1.0: pl2303_vendor_read - failed to read [000a]: -32
Jul  9 10:58:30 ccu3-webui user.err kernel: [  808.826564] pl2303 1-1.2.3:1.0: pl2303_vendor_write - failed to write [0007]: -32
Jul  9 10:58:30 ccu3-webui user.err kernel: [  808.830666] pl2303 1-1.2.3:1.0: pl2303_vendor_read - failed to read [000a]: -32
Jul  9 10:58:39 ccu3-webui local0.err ReGaHss: ERROR: send() failed (nsize=16958, errno=32, m_sock=10) [Send():iseSysLx.cpp:1576]
Jul  9 10:58:41 ccu3-webui user.err kernel: [  820.314554] pl2303 1-1.2.3:1.0: pl2303_vendor_write - failed to write [0007]: -32
Jul  9 10:58:41 ccu3-webui user.err kernel: [  820.316646] pl2303 1-1.2.3:1.0: pl2303_vendor_read - failed to read [000a]: -32
Jul  9 10:58:53 ccu3-webui user.err kernel: [  831.810667] pl2303 1-1.2.3:1.0: pl2303_vendor_write - failed to write [0007]: -32
Jul  9 10:58:53 ccu3-webui user.err kernel: [  831.814738] pl2303 1-1.2.3:1.0: pl2303_vendor_read - failed to read [000a]: -32
Jul  9 10:58:53 ccu3-webui user.err kernel: [  832.114923] pl2303 1-1.2.3:1.0: pl2303_vendor_write - failed to write [0007]: -32
Jul  9 10:58:53 ccu3-webui user.err kernel: [  832.119121] pl2303 1-1.2.3:1.0: pl2303_vendor_read - failed to read [000a]: -32

leider habe ich keine Ahnung ob das was aus macht oder nicht.

Gruß
Matten Matten

[deimos]

Hi,

pl2303 klingt nach irgendeinem USB Gerät und den Fehlermeldungen nach wirst du mit diesem Probleme haben.

Viele Grüße
Alex

[Matten Matten]

Hi,

pl2303 klingt nach irgendeinem USB Gerät und den Fehlermeldungen nach wirst du mit diesem Probleme haben.

Viele Grüße
Alex

Hallo Alex, danke für dein schnellen support. Ich hab die CCU darauf hin rebootet, jetzt tauchen die Fehler nicht mehr auf.
Ich habe auch alle USB Teilnehmer auf ihre Funktion gecheckt. (USV-eaton3s, CC2531-Zigbee Stick, CulV3 433mHz Stick, GSM TC35 Serial GSM Modul, Sandisk Speicher Stick)
Alle funktionieren.

Trotzdem Vielen Dank.

EDIT:

Code: Alles auswählen

 USB 1-1.2.3

war vermutlich das GSM Modul.

Gruß Matten Matten

[srunschke]

Ehrlich gesagt ergibt das keinerlei Sinn, ausser du hast an der Firewall selbst rumgespielt oder nutzt irgendein zusätzliche CCU Firewall-Addon was an den Firewall-Einstellungen rumgedreht hat. Denn, eine Verbinung zu 127.0.0.1:8183 muss eigentlich IMMER funktionieren. die IP 127.0.0.1 verweisst ja auf localhost und localhost verbindugen sind generell von den Firewallregeln eigentlich ausgeschlossen. Wenn dies also reproduzierbar bei dir auftritt würde ich darum bitten die Ausgaben des Kommandos "iptables -L -n -v" hier mal abzuliefern, dann könnte man schauen was da ggf. komisch/ursächlich ist.

Das ist genau genommen falsch. Niemand hält dich davon ab eine Firewallregel für das Interface "lo" zu bauen.
Ganz genau genommen hat die RM sogar für localhost einen Firewall Eintrag. Hier mal ein der Output meiner RM:

Code: Alles auswählen

root@hm:~# iptables -L -v
Chain INPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
4405K  706M ACCEPT     all  --  lo     any     anywhere             anywhere          
[Rest abgeschnitten]

Man beachte das "in" Interface: lo.
Das ist sogar zwingend notwendig, weil die Default Policy auf DROP gestellt wurde - sonst würde es nämlich gar nicht funktionieren.

Ergo würde das aber bedeuten, dass irgendwas an den Firewall Regeln gebastelt wurde. In einer normalen RM Installation funktioniert es aufgrund der accept any/any für lo.

@schneider.obw:
Kannst du mal deinen Output von "iptables -L -v" posten?

[jmaus]

Ehrlich gesagt ergibt das keinerlei Sinn, ausser du hast an der Firewall selbst rumgespielt oder nutzt irgendein zusätzliche CCU Firewall-Addon was an den Firewall-Einstellungen rumgedreht hat. Denn, eine Verbinung zu 127.0.0.1:8183 muss eigentlich IMMER funktionieren. die IP 127.0.0.1 verweisst ja auf localhost und localhost verbindugen sind generell von den Firewallregeln eigentlich ausgeschlossen. Wenn dies also reproduzierbar bei dir auftritt würde ich darum bitten die Ausgaben des Kommandos "iptables -L -n -v" hier mal abzuliefern, dann könnte man schauen was da ggf. komisch/ursächlich ist.

Das ist genau genommen falsch. Niemand hält dich davon ab eine Firewallregel für das Interface "lo" zu bauen.
Ganz genau genommen hat die RM sogar für localhost einen Firewall Eintrag.

Da hast du natürlich prinzipiell Recht und machen kann man viel. Trotzdem ist es total sinnbefreit irgendwelche Firewall-Regeln für das lo-interface aufzuerlegen. Ich wüsste nicht welchen Sinn es ergeben sollte das man auf dem 127.0.0.1 lo-Interface irgendetwas beschränken sollte? Genau deshalb wird da ja die von dir zitierte lo-Regel standardmäßig hinzugefügt, eben damit uneingeschränkt auf dem lo-Interface eine Kommunikation stattfinden kann.

[Hackertomm]

Hi,

pl2303 klingt nach irgendeinem USB Gerät und den Fehlermeldungen nach wirst du mit diesem Probleme haben.

Viele Grüße
Alex

Ja, PL2303 ist ein Serial to USB Wandler bzw. der Treiber dafür.
Ich habe einige USB Geräte, wo solche Chips verbaut sind, u.a. eines wo so ein Chip verbaut ist.
Auch im Schnittstellenkabel meines alten Blutzucker Messgerät ist da so ein Chip verbaut.
Wenn ich richtig zähle, habe ich auf meinem PC unter Windows 10 drei od. vier verschiedene Treiber für diverse USB to Serial Chips Installiert.
Wobei es gar nicht so einfach war, dafür passende oder überhaupt noch laufende Treiber zu bekommen.

[Auweia]

@Baxxy:
SSD + Sabrent: Bisher konnte ich keine Ungereimtheiten bzw. Probleme mit dem Adapter feststellen, auch das booten geht/ging immer. Im 2. System läuft es gut.
Das Problem konnte ich inzwischen etwas einkreisen:
Im Produktiv-System habe ich einen RPI4B mit 8 GB , im Testsystem RPI4B mit 4 GB. Nach dem erfolgreichen Update des Testsystems (!) habe ich das produktive System updated mit bekanntem Resultat, dass immer in den Recovery Modus rebooted wird.
Deshalb habe ich einen Restore mit aktuellen Backup auf das Testsystem gemacht, der zwar mit der Fehlermeldung Coprozessor nicht da... endete, aber nach Reboot erfolgreich war.
Dass das Update auf dem 2. RPI4 mit 8GB nicht erfolgreich durchläuft, liegt nicht an der SSD sondern beim Booten wird das /userfs nicht erweitert. Auch mit 2 neuen Micro-SD habe ich es versucht: das Booten geht nur in den Recovery Modus.
" df -h" liefert immer nur:
/dev/mmcblk0p3 1.9M 14.0K /userfs
/dev/sda3 1.9M 14.0K /userfs
Leider wird der Kernel mit Parameter quiet gestartet und ich sehe keine Fehlermeldung.
Was macht hier der Unterschied der Rpi4B?
Was kann ich noch tun?
Gruß
Albert

[Baxxy]

Was kann ich noch tun?

Hmm, ich bin etwas ratlos. Habe auch keinen 8GB Pi4B zum testen hier.

sondern beim Booten wird das /userfs nicht erweitert

Soweit ich weiß passiert das nur beim Erststart eines frisch aufgesetzten Systems oder nach einem Werksreset. Beim reinen Upgrade wird die Größe von /userfs nicht angefasst.

" df -h" liefert immer nur:

Das sieht echt komisch aus. Wovon ist die Ausgabe genau? SSD-Boot oder SD-Boot mit zusätzlich angeschlossener SSD?

Wenn's tatsächlich ein 8GB Pi4B Problem sein sollte dann mach doch mal nen Kreuztausch. Also die SSD vom Hauptsystem ans Testsystem und dort versuchen zu updaten.

Grüße
Baxxy

[Auweia]

Ich habe immer ein frisch per BalenaEtcher frisch aufgesetztes System - sowohl SD als auch SSD - zum Booten genutzt. Beim erstmaligen Booten sieht man auf der SSD ein Blinken, das aber nach kurzer Zeit erlischt.
Beim Rpi4B mit 4 GB geht das booten und ich kann den Restore per GUI machen..

[Baxxy]

Beim erstmaligen Booten sieht man auf der SSD ein Blinken, das aber nach kurzer Zeit erlischt.

Kannst du nicht mal Monitor und Tastatur dranhängen und beobachten was genau passiert?

Nicht das jmaus aus Versehen den Support für die 8GB Version ausgeknipst hat.
Zumindest über eine frische SD-Karte sollte der definitiv booten. Oder hast du vielleicht was am Bootloader verstellt?

Grüße
Baxxy

Edit:
Habe schnell mal nen 2GB und 4GB getestet. Beide booten sauber von frischen SD-Karten oder SSD's die 3.59.6.20210703.
Scheint also wirklich irgendwas mit der 8GB Version zu sein.