Posts by framp

Bootprobleme mit restorten Backups von raspiBackup gibt es eigentlich nur wenn das Restoremedium defekt ist.

In Deinem Fall ist rpi-clone besser geeignet. raspiBackup ist ein Backuptool und kein Clonetool.

0      temp=38.2'C 10:09:22

Nach geidelter Nacht. Und ja, es geht hier um den originalen active Cooler.

Jetzt sieht es etwas anders aus. Scheint so als wuerde der RPi5 nach einer Weile - auch wenn er nichts zu tun hat - waermer ...

0 	 temp=46.6'C 23:25:45

Ich lasse den mal bis morgen durchlaufen.

Quote from DistroEx

Original-Gehäuse

Meiner ist nackt wie Eben ihn schuf

Komisch. Bei mir ist absolute Ruhe. Der Luefter steht. Ist ein RaspbianOS Desktop ohne jeglichen Load und der Zugriff erfolgt per VNC. Ich habe den Original Cooler drauf. Die Temperatur ist niedriger als bei Dir.

pi@raspberrypi-bookworm64-desktop-cm4:~ $ while cat /sys/devices/platform/cooling_fan/hwmon/*/fan1_input | tr '\n' ' '; echo -e "\t"| tr '\n' ' '; vcgencmd measure_temp | tr '\n' ' '; date +%H:%M:%S; do sleep 10; done
0 	 temp=37.3'C 22:49:54
0 	 temp=37.8'C 22:50:04
0 	 temp=37.3'C 22:50:14
0 	 temp=37.3'C 22:50:24
0 	 temp=37.3'C 22:50:34

Ist jetzt OT aber wie bringst Du den RPi5 zum Schwitzen?

Quote from Outlaw

Nicht Dein Ernst, oder ??

Leider habe ich die Ursache bislang nicht rausgefunden. Das Problem tritt bei mir bei ca 10 Versuchen 1 Mal auf und ist somit extrem aufwaendig zu debuggen.

Das Symptom ist offensichtlich dass der Mount auf /boot/firmware von /dev/mmcblk0p1 waehrend des Clones der Rootpartition ploetzlich verschwindet und somit Nichts in die geclonte Bootpartition kopiert wird. Warum das passiert

Quote from Outlaw

Welchen ??
Den originalen ??

Ja. Danke fuer die Werte - aber ich frage mich auch warum ich da tunen soll. Sind die Defaulteinstellungen so schlecht? Zumal der RPi5 bei den raspiBackup Tests definitiv nicht unter Volllast geraten wird.

Quote from WildTassie

in Pihole nebst FHEM läuft darauf aber immer noch super.

Bei mir laeuft auch PiHole auf einem 1B. Der reicht vollkommen.Auch wenn man aelter ist gehoert man nicht zum alten Eisen

Habe gerade bemerkt dass er Link auf die neuen Features und Enhancements fuer 0.7 im ersten Beitrag dead war da ich die Release auf 0.7 geaendert habe und noch auf 0.6.10 verwiesen wurde Der Link ist jetzt korrigiert sowie auch hier direkt aufrufbar.

Soweit ich weiss kann man auch auf Windows SW installieren die das ext4 Dateisystem der Raspberry erkennt. Ist aber nicht notwendig. Boot einfach auf der Raspi das OS und Du wirst die volle Partitionierung, wie von DistroEx geschrieben wurde, sehen.

Wenn Du (a) nicht hast brauchst auch (b)-(d) nicht

Anyhow: (b) ist ganz gut im c't Artikel beschrieben.

So ... ich bin jetzt auch stolzer Eigentuemer eines RPi5 - allerdings ohne HAT und NVMe SSD. Zum Testen reicht das - jedenfalls fuer rpi-clone und auch fuer raspiBackup.

Auch mit einer guten SD Karte ist die Kleine recht fix. Und sehr praktisch finde ich den winzigen Kopf zum EIn- und Ausschalten.

Wie empfohlen wurde habe ich auch einen Cooler drauf. Der Luefter springt zwar bei meinen Tests nicht an - aber der Kuehlkoerper wird schon merklich warm.

Anyhow - das rpi-clone Problem scheint beim RPi5 wohl durch die hohere Geschwindigkeit des RPi5 oder dem anderen genutzten Kernel verursacht zu werden. Jedenfalls verschwindet beim Clonen intermittierend der mount auf /boot/firmware und somit wird Nichts auf /boot kopiert Da es echt zeitaufwaendig ist das zu reproduzieren und zu debuggen (ca 10 Versuche und 1 Erfolg) habe ich in meinem Fork Code dazugefuegt der den fehlenden Mount nachholt bevor der Clone von /boot/firmware gestartet wird. Ausserdem bessere Debugginginfos wenn die Option -x genutzt wird.

Ist ein interessantes Thema. Nur wer hat so mal eben 3 RPis fuer solche Dinge ungenutzt rumliegen? (3 sind Minimum fuer K8s - einen Master und wenigstens 2 Nodes damit man einen mal abschalten kann). Und dann natuerlich noch die Netzteile oder das eben o.g. Ladegeraet ...

Bevor ein neues raspiBackup Release allgemein verfuegbar gemacht wird nutze ich natuerlich die Beta Version auch auf meinen Raspberries. Gerade habe ich mal testhalber eine RPi4 mit genutzten 16GB aus einem -P Backup mit der Option -00 restored. Das Backup liegt auf einer per 1Gb connected NAS und das Ziel ist eine SD Karte.

--- RBK0340I: Restore time: 00:01:59.

Da die Restoretimemessage erst gerade von mir eingebaut wurde - macht sicherlich Sinn - muss ich jetzt zum Vergleich noch mal den Restore ohne die Option -00 laufen lassen.

Update kommt gleich ...

UPDATE:

--- RBK0340I: Restore time: 00:12:00.

Klar gibt es zwischen dem Restore mit der Option -00 keine grossen Updates und somit ist das die beste Restorezeit die man in meinem Falle erreichen kann. Wenn man aber durch irgendwelche Updates sein Systen unbrauchbar gemacht hat ist das eine sehr schnelle Methode das System wieder brauchbar zu machen

Anyhow moechte ich einen Jeden raspiBackup Nutzer ermuntern die Beta mal (an)zu testen und Feedback zu geben. Ist immer unangenehm wenn nach kurzer Zeit einer neuen Release wie z.B. 0.7.0 relativ schnell eine 0.7.0.1 oder sogar 0.7.0.2 nachgeschoben werden muss

Quote from Urs-1956

Damit werden die Pi4 ausserhalb der Spezifikation betrieben.

Aber sie laufen

Quote from Outlaw

Dein letztes Steckdosenleistenbildnis sieht auch nicht so toll aus

Was findest Du dass ich aendern sollte?

PS: Jetzt steckt da noch ein weiteres Netzteil fuer ein RPi5 drin

Quote from framp

noch mit aufnehmen

Done

Das ist leider die einfachste und schnellste Methode ein Backup zu erstellen. Welche Nachteile das hat schreibt keiner. Ausser ich . Aber ich sehe da muss ich diesen Nachteil noch mit aufnehmen.

Wer dd nutzt ist einfach selber Schuld fuer alle Konsequenzen. Mehr kann ich dazu nicht sagen.

Der Issue ist fuer die naechste Release erstellt. Die Severity ist low und muss warten. Ist kein Hotfix. Wer einen dd Backup bei raspiBackup nutzt muss erst einmal mit den Konsequenzen leben