Nightly Build Snapshots - lange Aktualisierungszeit

[bopxxx007]

Ich habe heute auf dem Raspberry Pi 5 beim Aktualisieren auf die neueste Nightly-Build ebenfalls ein seltsames Verhalten festgestellt.

Zunächst dauerte das Update etwa 15 Minuten (normalerweise nur 3–4 Minuten).
Nach der Installation der Nightly startete das System im Recovery-Modus. Anschließend klickte ich auf „Normaler Neustart“, und nach etwa 5 Minuten startete das System ganz normal, als wäre nichts passiert.

Zuvor war die Version „OpenCCU-3.87.6.20260418-ba97a6-rpi5“ installiert, danach habe ich auf „OpenCCU-3.87.6.20260420-d0e93d-rpi5“ aktualisiert.

Ist jemandem etwas Ähnliches aufgefallen?

nach dem Update:

.
.
.
.
.
.
Und ich habe das während des Updates gesehen:

[bopxxx007]

logs.zip

[jens-maus]

Vermutlich hättest du nur einfach etwas länger warten müssen und dann hätte das RecoverySystem nach dem durchgeführten Update selbstständig in das normale System rebooted. Probier einfach das ganze nochmal und versuchen die 3.87.6.20260420-d0e93d über die bereits installierte 3.87.6.20260420-d0e93d noch einmal drüber zu installieren. Dann sollte das wie gewohnt funktionieren.

[bopxxx007]

Vermutlich hättest du nur einfach etwas länger warten müssen und dann hätte das RecoverySystem nach dem durchgeführten Update selbstständig in das normale System rebooted. Probier einfach das ganze nochmal und versuchen die 3.87.6.20260420-d0e93d über die bereits installierte 3.87.6.20260420-d0e93d noch einmal drüber zu installieren. Dann sollte das wie gewohnt funktionieren.

Werden alle Updates nach letzten beiden Nightly Builds über das Wiederherstellungssystem laufen? Ich habe genau das gemacht, was du oben beschrieben hast. Oh je, jetzt muss ich wohl jeden Morgen 20 Minuten früher aufstehen :-)

[jens-maus]

Updates laufen IMMER über das RecoverySystem ab. Das ist und war schon immer so... denn die Update routinen stecken im recovery system drin das beim anstoßen des updates automatisch gebootet wird, dann finden dort die updates statt und danach rebootet das recovery system danach aber wieder in das normale system...

[Baxxy13]

Ich hab mal grob die Zeit gestoppt beim Update auf den heutigen Nightly.
Pi4B mit USB3-SSD ca. 5Min
Pi3B mit normaler SD-Karte ca. 15Min

Ich kann jetzt nicht sagen ob die Zeiten gut oder schlecht bzw. ungewöhnlich sind.

[bopxxx007]

Offensichtlich ist etwas kaputtgegangen.

Die Rückkehr zur offiziellen März-Version und das Update auf die neuesten Nightly-Versionen sind kinderleicht – alles läuft schnell und problemlos.
Auch das Erstellen neuer Partitionen beim Wechsel von der März- zur April-Version geht superschnell.

Sobald man jedoch eine Version ab April installiert, wird jedes weitere Update von dieser Version zum Albtraum: extrem langsam, und manchmal erscheint sogar der Wiederherstellungsbildschirm.

Ich dachte zunächst, es läge an meiner industriellen SD-Karte, deshalb habe ich gerade drei andere SD-Karten ausprobiert.
Überall wiederholte sich exakt dasselbe Szenario.

Ich glaube, ich habe heute etwa 15 Updates durchgeführt – einige über die Weboberfläche, andere durch direktes Aufspielen des Systemabbilds mit dem Raspberry Pi Imager.

Möglicherweise gibt es ein Problem mit dem neuen Kernel auf dem Raspberry Pi 5 oder mit dem rpi-eeprom.
Und ich habe noch nie so einen Weihnachtsbaum auf meinem CCU3 gesehen – rosa, rot, blau, weiß

[Baxxy13]

Kannst du präziser beschreiben mit welchen Versionen man das ggf. nachvollziehen kann.
März/April - Versionen ist mir nicht eindeutig genug.

Update von Nightly 20260abc auf Nightly 20260xyz z.B.

[bopxxx007]

OpenCCU-3.87.6.20260313-rpi5 - Hier ist alles in Ordnung.

OpenCCU-3.87.6.20260404-rpi5 - Hier beginnen die Probleme langsam.

OpenCCU-3.87.6.20260418-ba97a6-rpi5 - Hier ist der direkte Wechsel von dieser Version zur nächsten Version von dem 20. April ein Albtraum.

OpenCCU-3.87.6.20260420-d0e93d-rpi5 - Hier stellt das Wiederherstellen eines Backups oder das Aktualisieren auf eine ältere Version Ihre Psyche auf eine harte Probe.

wenn Sie die März-Version verwenden OpenCCU-3.87.6.20260313-rpi5 der Übergang zu neueren Versionen verläuft nahtlos. Selbst die Erweiterung der Partition erfolgt blitzschnell. Irgendetwas hat sich im April geändert, und ich weiß nicht, ob es ein neuer Kernel oder eine neue Boot-Datei für den Raspberry Pi 5 ist.

[Baxxy13]

Hmm, ok.
Ich würde die 3.87.6.20260404 frisch flashen und dann z.B. auf den Nightly 3.87.6.20260420-d0e93d updaten.
Dabei müssten dann die Neu-Partitionierung stattfinden.
Danach würde ich nochmal den Nightly 3.87.6.20260420-d0e93d "drüberinstallieren" und müsste das Problem sehen.

Soweit richtig?

[bopxxx007]

Genau so
Und Entschuldigung für mein Deutsch

Ich lebe seit 20 Jahren in der Schweiz und habe nie Deutsch gelernt, obwohl ich die Prüfung hier bestanden habe.
Aber da wohl jedem Deutschen klar ist, dass die Schweizer kein Deutsch sprechen, stimmt das wahrscheinlich :-)

[jens-maus]

Dann kannst du auch gerne einfach englisch schreiben - ist hier ohnehin die präferierte Sprache - wenn dir das hilft!

[Baxxy13]

Und Entschuldigung für mein Deutsch

Nicht nötig, ich verstehe das schon. Wollte nur etwas Klarheit um den Testaufwand zu reduzieren.
Ich versuche mir das morgen mal anzusehen.

[Baxxy13]

Hab das nun doch noch fix durchexerziert.

Frische 3.87.6.20260404 --> Update auf Nightly 3.87.6.20260420-d0e93d --> ca. 7Min
--> erneutes "Update" auf Nightly 3.87.6.20260420-d0e93d --> ca. 5Min

Pi5-8GB / 32GB SanDisk Extreme V30 A1 U3

Bootloader nun:

~# vcgencmd bootloader_version
2026/04/14 22:20:24
version 9cd61c5318429d111699d39e4d232d7303c40cdd (release)
timestamp 1776201624
update-time 1776662322
capabilities 0x0000007f

Ich konnte erstmal soweit keine Auffälligkeiten feststellen.

[bopxxx007]

kernel log (CUxD):

Sind diese drei Neustarts des radio module normal? Vielleicht habe ich ein Hardwareproblem?

<6>[   25.024623] Adding 4338992k swap on /dev/zram1.  Priority:75 extents:1 across:4338992k SS
<6>[   33.055690] i2c_dev: i2c /dev entries driver
<6>[  102.257482] macb 1f00100000.ethernet eth0: PHY [1f00100000.ethernet-ffffffff:01] driver [Broadcom BCM54213PE] (irq=POLL)
<6>[  102.258379] macb 1f00100000.ethernet eth0: configuring for phy/rgmii-id link mode
<6>[  102.261571] macb 1f00100000.ethernet: gem-ptp-timer ptp clock registered.
<6>[  106.367266] macb 1f00100000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
<6>[  108.805612] usbcore: deregistering interface driver brcmfmac
<6>[  131.986507] raw-uart raw-uart: Reset radio module
<6>[  134.157814] raw-uart raw-uart: Reset radio module
<6>[  136.637497] raw-uart raw-uart: Reset radio module
<6>[  217.327737] eq3loop: created slave mmd_hmip
<6>[  217.327861] eq3loop: created slave mmd_bidcos
<6>[  221.336404] eq3loop: eq3loop_open_slave() mmd_bidcos
<6>[  221.336423] eq3loop: eq3loop_close_slave() mmd_bidcos
<6>[  221.337162] eq3loop: eq3loop_open_slave() mmd_hmip
<6>[  221.337177] eq3loop: eq3loop_close_slave() mmd_hmip
<6>[  233.420832] eq3loop: eq3loop_open_slave() mmd_bidcos
<6>[  244.633078] eq3loop: eq3loop_open_slave() mmd_hmip
<6>[  244.633158] eq3loop: eq3loop_close_slave() mmd_hmip
<6>[  244.634150] eq3loop: eq3loop_open_slave() mmd_hmip
<6>[  244.634201] eq3loop: eq3loop_close_slave() mmd_hmip
<6>[  244.634402] eq3loop: eq3loop_open_slave() mmd_hmip
<6>[  244.634480] eq3loop: eq3loop_close_slave() mmd_hmip
<6>[  244.636517] eq3loop: eq3loop_open_slave() mmd_hmip```

[jens-maus]

Vollkommen normal! Ergo kein Grund zur Sorge durch exzessivem Log studieren wenn es keinerlei praktische Einschränkungen oder Probleme gibt... ;-)

[bopxxx007]

Okay, betrachten wir das als ein Problem auf Benutzerseite.
Jmaus und Baxxy haben immer Recht – großen Respekt für eure Arbeit.

Ich werde der Sache nachgehen.

[Baxxy13]

Nein, wir haben nicht immer Recht.
Ich denke aber das das Problem irgendwie bei deiner Installation liegt.
Vielleicht hat das ganze hin und her installieren da irgendwas hinterlassen.
Ich würde jetzt einfach den letzten Nightly frisch flashen und ein Backup einspielen.

wenn es keinerlei praktische Einschränkungen oder Probleme gibt... ;-)

Naja, diese Diskussion dreht sich doch um ein Problem in seinem Setup...

[Baxxy13]

Zunächst dauerte das Update etwa 15 Minuten (normalerweise nur 3–4 Minuten).

Ist das immer noch so?
Und wenn ja kannst du mal bei einem Update die Zeit stoppen wenn du einen Monitor angeschlossen hast?

Ich beobachte das gerade bei einem Pi3B der ohne angeschlossenen Monitor für ein Update und auch normalen Reboot die 2 bis 3 fache Zeit braucht.

Update:
Problem von Jens gefunden und dann ab dem nächsten Nightly gefixt. 😃

[bopxxx007]

Ja. Ich habe am Mittwochabend zwei Updates herausgebracht.
OpenCCU-3.87.6.20260424-2d811b-rpi5 zu OpenCCU-3.87.6.20260429-880521-rpi5 - - - 16 min
OpenCCU-3.87.6.20260429-880521-rpi5 zu OpenCCU-3.87.6.20260429-880521-rpi5 - - - 14 min

Normalerweise dauerte es auf dem Raspberry Pi 5 3-4 Minuten. Ich hätte ein logistisches Problem mit dem Anschluss des Monitors, tut mir leid.

[Baxxy13]

Normalerweise hat man ja auch keinen Monitor dran.
Aber genau das (kein Monitor) verzögerte sowohl das Herunterfahren als auch den Start.

Wenn du auf den heutigen Nightly updatest dann sollte das schon etwas schneller gehen weil nicht mehr der Start sondern nur noch das Herunterfahren verzögert wird.

Danach (wenn Nightly 3.87.6.20260430-8571f8 installiert ist) sollte alles wieder wie gewohnt schnell laufen.

[bopxxx007]

Ok :-) Ich habe heute Abend wieder etwas zu tun :-)

[bopxxx007]

Problem gelöst !!! Bravo, Jungs! ;-)

OpenCCU-3.87.6.20260429-880521-rpi5 zu OpenCCU-3.87.6.20260430-8571f8-rpi5 - - - 11 min
OpenCCU-3.87.6.20260430-8571f8-rpi5 zu OpenCCU-3.87.6.20260430-8571f8-rpi5 - - - 3 min 50 sek

Die Zeit wurde stets vom Klicken auf die Schaltfläche "Update" bis zum Erscheinen des Anmeldebildschirms gemessen

[bopxxx007]

Ich möchte außerdem darauf hinweisen, dass dies für normale Benutzer ein großes Problem darstellen würde. Also nochmals vielen Dank.

Bei einem sehr langen Update kann das System unter Umständen in eine Endlosschleife geraten, wenn die Akteure und Sensoren nicht mit der CPU verbunden sind. Es heißt immer: „unreach“ oder duty cycle Fehler.
Dann ist die einzig schnellste Lösung, alles vom Netzteil zu trennen und den "duty cycle" zurückzusetzen.

Das ist mir gerade passiert, als ich dieses Thema eröffnet habe, weil ich nicht nur ein Update durchgeführt, sondern auch ein Backup wiederhergestellt habe.

Aber jetzt ist alles in Ordnung :-))))