Zum Inhalt springen

Ethereum-2.0-Staking auf Raspberry Pi


Cookies statt Coins^^

Empfohlene Beiträge

Am 11.6.2020 um 16:34 schrieb skunk:

Ich habe inzwischen geth, beacon-node und validator auf Konfig Dateien umgestellt um der Problematik mit dem Updates aus dem Weg zu gehen. Zusätzlich habe ich alle 3 Prozesse in einen eigenes Docker Netzwerk geschoben womit auch die Problematik mit der unsicheren gRPC Verbindung erschlagen wäre. Ich kann sehr genau definieren welche Ports von Außen in dieses Netzwerk geleitet werden. Als kleinen Bonus funktioniert jetzt auch Docker Stats. Das zeigt mir an wie viel Ressourcen überhaupt verbrauchen. Mit den Daten werde ich da vielleicht noch das eine oder andere optimieren.

Sehr interessant 👍.
Wie hast du das mit der Konfigurationsdatei gemacht? Ich rufe die Skripte mittlerweile auch zusätzlich mit ein paar Optionen auf (--log-file und --datadir), da wäre es in einer Konfig-Datei übersichtlicher.
Wie viel Bandbreite Upload und Download zeigt dir Docker Stats an?

 

Am 11.6.2020 um 16:34 schrieb skunk:

Das Setup um einen Slasher zu ergänzen steht noch auf meiner ToDo List.

Einen Slasher lasse ich nun  auch mitlaufen. Ist ja nur ein zusätzlicher Aufruf habe ich festgestellt. Bisher hat mein Slasher aber noch keine Unregelmäßigkeiten festgestellt. Wird vermutlich eher selten auftreten.

 

Am 11.6.2020 um 16:34 schrieb skunk:

Richtig es gibt von Seiten der Entwickler keine Pläne aber von Seiten der Community kann einfach jemand einen Pull Request eröffnen und dann wäre das ARM64 Image plötzlich doch vorhanden. Die notwendige Code Änderung sollte in etwa so aussehen: https://github.com/storj/storj/pull/2814/files#diff-b67911656ef5d18c4ae36cb6741b7965R175-R177

Wenn jemand einen Pull Request eröffnet, wird der sicherlich nicht abgelehnt werden. Ich selber bin mit meinem Docker Wissen noch nicht an diesem Punkt angelangt und ich habe auch keine Hardware um das Docker Image am Ende zu testen. Ich bräuchte also zumindest einen Freiwilligen dafür^^

Also für den Test würde ich meinen Raspberry Pi gerne zur Verfügung stellen, aber das mit dem Pull Request ist mir zu viel. So viel Zeit habe ich leider nicht, um mich damit intensiv zu beschäftigen und um das voranzutreiben ohne aktuell selbst viel Ahnung davon zu haben.

 

Am 12.6.2020 um 03:45 schrieb skunk:

Dieses mal habe ich die Deposit Transaktionen selber erstellt um auch die letzten Abhängigkeiten los zu werden. Es ist erstaunlich einfach. [...]

Gut zu wissen 👍. Das muss ich nun auch mal probieren. Aber erst muss ich den Geth Node auf dem Raspberry Pi zum laufen bringen..

 

Am 15.6.2020 um 11:49 schrieb skunk:

Nach dem Neustart des Testnetz läuft mein Setup bisher super. Ich würde aktuell 0,0144 ETH pro Node pro Tag bekommen. Mit zunehmender Anzahl an Nodes dürfte der Reward langsam sinken.

@Cookies statt Coins^^ wie läuft es bei dir? Hast du bereits einen dieser kurzen Aussetzer beobachten können?

Mein Setup läuft nach dem Neustart des Testnets nun auch sehr stabil. Seit dem Start vor zweieinhalb Tagen gab es keinen Absturz. Beacon-Node und Validator (und nun auch Slasher) laufen fehlerfrei und stabil auf dem Raspberry Pi. Vermutlich liegt das auch an der neuesten Version (Version: v1.0.0-alpha.11). Die CPU-Auslastung liegt nun bei ca 10%.
Und auch ohne Docker wird bei jedem Start der Shell-Skripte automatisch geprüft,  ob es eine neuere Version gibt und diese wird dann automatisch heruntergeladen und gestartet.

Das hier ist nun der neue Link zu meinem neuen Validator: https://beaconcha.in/validator/8015
Es geht hier nun kontinuierlich aufwärts. Ähnlich wie deine Validatoren hat mein Validator in den letzten 24 Stunden 0,0146 ETH eingebracht. (In diesen Zeitraum fielen aber auch zwei proposed-Blöcke, die etwas mehr einbringen.) Somit habe ich nun 3x soviel eingenommen als zuletzt am Ende des vorherigen Testzeitraums. Das bestätigt auch eindrucksvoll meine Vermutung, dass zu Beginn des Stakings die Erträge noch am höchsten sind, da es weniger Validatoren gibt auf welche die Erträge verteilt werden. Aktuell sind es ca. 17.400 aktive Validatoren im Testnet. (Mal abwarten, wie viele es am Ende sind und wie dann die Erträge ausfallen.)

Es gibt aber auch vereinzelte Aussetzer (Attestations=Missed), bei denen der Validator vermutlich nicht rechtzeitig den Block bestätigt hatte oder irgendwas anderes schief lief.
Ich habe soeben eine Auswertung meiner Validator-Logdatei gemacht: Aktuell hat mein Validator 60x ein Strafe bekommen aufgrund eines ungültigen Votes. Dem gegenüber stehen 496 Gutschriften aufgrund eines korrekten Votes. Macht eine Fehlerquote von 9%. Hast du eine ähnlich hohe Fehlerquote?

  • Thanks 1
Link zu diesem Kommentar
Auf anderen Seiten teilen

Eigentlich wollte ich nun meinen ersten Beitrag hier in diesem Thread editieren, damit alle wichtigen Infos zentral an einer Stelle zu finden sind. Aber ich habe festgestellt, dass ich diesen Beitrag nun nachträglich nicht mehr bearbeiten kann. Das ist schade, denn jetzt muss man sich die wichtigsten Infos hier aus dem Verlauf sammeln und einige Infos aus dem ersten Beitrag sind schon veraltet. Aber zum Schluss, wenn alles stabil läuft, kann ich evtl. nochmal eine Zusammenfassung posten.

Hier ein Zusammenfassung der Änderungen im Vergleich zum ersten Beitrag vom 6. Juni:

- Neues Testnet:
Das öffentliche ETH2-Testnet wurde neugestartet. Passend dazu gabs ein Softwareupdate (Version: v1.0.0-alpha.11). Diese neue Version bekommt man automatisch, wenn man sich an die ursprüngliche Anleitung haltet: https://prylabs.net/participate
 

- Slasher in Betrieb genommen:
Ich betreibe nun auch zusätzlich zum Validator einen Slasher. (Zur Info: Ein Slasher soll erkennen, wenn z.B. ein anderer Validator unerlaubte Aktionen begeht, vgl: https://docs.prylabs.network/docs/prysm-usage/slasher/; Wenn ein Slasher eine solche unerlaubte Aktion meldet, dann gibt es ein zusätzliches Einkommen; Bisher hat mein Slasher  im Testnet aber noch keine Auffälligkeit gefunden)
 

- Externe Festplatte an Raspberry  Pi angeschlossen:
Ursprünglich wollte ich eine 1TB SSD-Festplatte an den Raspberry Pi anschließen. Aber ich habe noch zuhause ein 500 GB HDD Festplatte gefunden und diese vorübergehend angeschlossen.
Das Anschließend der Festplatte an den Raspberry PI ist in folgender Anleitung ab dem Kapitel "Mount the SSD" ausführlich beschrieben: https://kauri.io/running-an-ethereum-full-node-on-a-raspberrypi-4-m/9695fcca217f46feb355245275835fc0/a (Auf diese Anleitung komme ich später aufgrund eines anderen wichtigen Punkts nochmal zurück 😉 ).
--> D.h. die Festplatte wird gemountet, partitionieren und so eingerichtet, dass sie bei jedem Start automatisch wieder mit eingebunden wird.

Seit Montag habe ich nun die Festplatte angeschlossen und seitdem hat sich auch der tägliche Stromverbrauch des Raspberry Pi von 0,07 kWh auf 0,13 kWh fast verdoppelt. Somit komme ich aktuell auf folgende jährliche Stromkosten: 0,13 kWh * 365 * 0,30 €/kWh = 14€. Das finde ich auch noch günstig.

Diese Festplatte ist aber nur eine Übergangslösung, bis ich mir eine SSD-Festplatte zulege.
 

- ETH-Blockchain-Daten auf Externe Festplatte ausgelagert:
Die Daten der ETH-2.0-Beacon-Blockchain verschiebe ich nun von der Micro-SD-Karte des Raspberry Pi auf die Externe Festplatte..
Danach müssen ab sofort die Skripte (Beacon-Node, Validator, Slasher) zusätzlich immer mit folgendem Übergabeparameter aufgerufen werden, um den Standard-Pfad für die Blockchain-Daten auf die Externe Festplatte umzubiegen:
    --datadir /mnt/ssd/ethereum/.eth2 

Zusätzlich für den Validator braucht man noch folgenden Parameter:
    --keystore-path /mnt/ssd/ethereum/.eth2validators

Falls man die bisherigen Ordner nicht verschiebt, beginnt man praktisch erneut von Null an und der ETH-2.0-Beacon-Node müsste sich zunächst neu synchronisieren und für den Validator müsste dann vermutlich auch nochmal ein neues Schlüsselpaar und dazugehöriges Deposit hinterlegt werden. (Nur eine Vermutung, habe es nicht ausprobiert)
 

- 8 GB Swap-Bereich  auf Externer Festplatte eingerichtet:
Mein Raspberry Pi hat nur 4 GB Arbeitsspeicher, was gerade so die Mindest-Hardware-Anforderungen für den Betrieb eines ETH-2.0-Beacon-Nodes und Validators abdeckt. Da scheinbar standardmäßig in der Ubuntu-Distribution für den Raspberry Pi gar kein Swap-Bereich (für zusätzlichen ausgelagerten Arbeitsspeicher auf der Festplatte) vorgesehen ist, musste ich zunächst nach folgender Anleitung eine 8 GB Swap-Datei auf der Externen Festplatte einrichten: https://www.digitalocean.com/community/tutorials/how-to-add-swap-space-on-ubuntu-18-04
--> D.h. ein 8 GB große Swap-Datei wird auf der Festplatte erzeugt, mit den Befehlen "mkswap" und "swapon" wird dem System nahe gelegt diesen Swap-Bereich zukünftig zu nutzen, durch einen Eintrag in "fstab" wird sichergestellt dass diese Konfiguration nach dem Neustart erhalten bleibt, und zum Schluss werden noch ein paar Parameter verändert damit das System nicht zu oft auf diesen (deutlich langsameren) Speicher zurückgreift.

Zu Beginn wurde der neue Swap-Bereich nur sehr zögerlich angenommen. Aber seit ich nun seit heute auch mittels Geth die ETH-1.0-Blockchain im Testnetz synchronisiere (siehe Aufzählungspunkt ganz unten) war es schon zwingend notwendig, den Speicher im Vorfeld entsprechend zu erweitern, wie folgender Auszug der Systemauslastung zeigt (1,5 GB des Swap-Speichers sind nun bereits  belegt):
top.png.60fbcf35fc05d51edcd601c212bb5665.png
 

- Skripte laufen nun als Prozesse (und nicht mehr in Screen-Session mit Cronjob-Überwachung)
In meinem ersten Beitrag vom 6. Juni hatte ich geschrieben, dass ich die Skripte in einer Screen-Session laufen lasse und ein Cronjob hatte alle 5 Minuten geprüft, ob noch alles läuft. Durch den Hinweis von @skunk habe ich die Skripte so umgestellt, dass diese nun als Prozesse laufen. Dies hat den Vorteil, dass diese beim Systemstart und bei einem Absturz sofort automatisch (nach)gestartet werden.

So sieht nun beispielhaft der Prozess zum Starten der ETH-2.0-Beacon-Node aus:

[Unit]
Description=Prysm Testnet BeaconChain Service 
After=network.target
StartLimitIntervalSec=0

[Service]
Type=simple
Restart=always
RestartSec=1
User=ubuntu
ExecStart=/home/ubuntu/prysm/prysm.sh beacon-chain  --log-file /home/ubuntu/prysm/LogBeaconChain.txt  --datadir /mnt/ssd/ethereum/.eth2

[Install]
WantedBy=multi-user.target

Diese Datei muss dann unter "/etc/systemd/system/" abgelegt werden und mittels "systemctl"-Befehl einmalig initialisiert werden. Details zur Erstellung und Konfiguration eines solchen Services gibt es hier: https://medium.com/@benmorel/creating-a-linux-service-with-systemd-611b5c8b91d6

Insgesamt habe ich so nun fünf Prozesse am erstellt:
- Prozess für ETH-2.0-BeaconChain-Node
- Prozess für Validator
- Prozess für Slasher
- Prozess zum Logging der Systemauslastung
- Prozess zum Logging der CPU-Temperatur (da ich immer noch keine Kühlung habe^^)
 

- Installation von Geth zum Betrieb eines ETH-1.0-Nodes
Dieser hier beschriebene Schritt ist zwar nicht zwingend nötig für das Staken, es fördert aber die Dezentralisierung von Ethereum und evtl. verspreche ich mir dadurch auch einige Verbesserungen (dass z.B. die Validatoren eine höherer Trefferquote beim Attestieren der Blöcke bekommen; aber ohne Garantie, dass das tatsächlich Auswirkungen haben wird).
Ziel ist es hier, mittels Geht einen ETH-1.0-Node zu betreiben, mit dem sich dann mein ETH-2.0-Beacon-Node verbinden soll.

Hintergrund:
In Phase 0 werden die ETH-1.0- und und ETH-2.0-Blockchain parallel betrieben. Man könnte sich für das Staken daher entweder mit einem öffentlichen ETH-1.0-Node verbinden, oder man betreibt seinen eigenen.
Die Kommunikation läuft scheinbar über diesen Weg: Validator <-> ETH-2.0-BeaconNode <-> ETH-1.0-Node
z.B. über den ETH-1.0-Node müssen die Einzahlungen der 32 ETH zum Aktivieren der Validatoren eingehen, da man ja nicht Ethereum direkt von ETH-1.0 nach ETH-2.0 senden kann. (vgl: https://docs.prylabs.network/docs/prysm-usage/setup-eth1).
Aber wie das alles genau im Detail zusammen hängt und funktioniert, habe ich auch noch nicht ganz verstanden.🙈

Nun zur Installation von Geth:
Zu Beginn hatte ich Probleme, die korrekte Installationsdateien für den Raspberry Pi zu finden. Aber auf folgender Seite ist es sehr ausführlich beschrieben, wie man Geth auf einem Raspberry Pi installieren und den ETH-1.0-Node starten kann: https://kauri.io/running-an-ethereum-full-node-on-a-raspberrypi-4-m/9695fcca217f46feb355245275835fc0/a
Zu Beginn wird in dieser Anleitung sehr ausführlich auf den Raspberry Pi eingegangen. Erst im letzten Drittel (ab Kapitel "Install and configure Geth") kommt der hier relevante Teil.
-> d.h. die Installationsdateien von Github herunterladen, mittels "make" die Sourcen von "Geth" auf dem Raspberry Pi selbst kompelieren, und zum Schluss "Geth" starten.
Diese verlinkte Anleitung bezieht sich auf das Mainnet. Da ich Geth jedoch nur im Testnet (ETH-1.0-Testnet = "Goerli") betreiben möchte (und da ich auch die Ausgabe in eine Logdatei umleiten möchte), starte ich Geth auf folgende Weise:
    geth --goerli --datadir="/mnt/ssd/ethereum/.eth1Goerli" 2>> /home/ubuntu/prysm/LogEth1Goerli.txt

Aktuell, während ich diesen Beitrag hier schreibe, läuft gerade die Synchronisation, d.h. Geth lädt gerade die ETH-1.0-Testnet-Blockchain herunter. Das wird noch einige Stunden so gehen, weil ständig die Verbindung zu den Peers abbricht. Aber spätestens morgen Abend sollte es fertig sein, dann kann ich mit dem entsprechenden Parameter meinen ETH-2.0-Beacon-Node mit diesem ETH-1.0-Node verbinden. Vermutlich muss ich dazu den ETH-2.0-Beacon-Node nur zusätzlich mit dem Parameter "--http-web3provider=$HOME/Goerli/geth.ipc" starten, und dann sollte es eigentlich schon funktionieren. Steht zumindest hier in der Anleitung: https://docs.prylabs.network/docs/prysm-usage/setup-eth1

Sollte dies im Testnet dann stabil laufen, dann würde ich auch mal versuchsweise auf meinem Raspberry Pi die echte Ethereum-Blockchain aus dem Mainnet herunterladen. Nur um zu sehen, ob mein Raspberry Pi mit diesen zusätzliche Volumen klar kommt. Aber höchstwahrscheinlich wird das ohne SSD-Festplatte nicht zuverlässig laufen, könnte ich mir vorstellen.. Es bleibt also spannend... 😄

 

  • Thanks 3
Link zu diesem Kommentar
Auf anderen Seiten teilen

  • 2 Wochen später...

Erst einmal ein herzliches Danke für diese tolle Anleitung.

Ich habe es ebenfalls versucht mit einem Raspberry Pi 4 ETH zu staken, laufe aber leider in folgenden Fehler, wenn ich "./prysm.sh beacon-chain" ausführe:

[2020-06-29 15:14:01] INFO initial-sync: Waiting for enough suitable peers before syncing required=3 suitable=0

Hat jemand von euch eine Idee, woran das liegen kann?

Vielen Dank schon mal!

Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 15 Stunden schrieb mlange:

2020-06-29 15:14:01] INFO initial-sync: Waiting for enough suitable peers before syncing required=3 suitable=0

Hi, vor einigen Tagen trat der Fehler bei mir auch durchgängig auf, da musste ich dann das Beacon-Skript neustarten und danach hat es seltsamerweise ohne weitere Änderung plötzlich wieder geklappt. Aber einen Neustart hast du vermutlich schon versucht?
Oder evtl. sind von der Firewall/ Router noch wichtige Ports gesperrt, welche das Skript für die Verbindung mit den Peers benötigt? (Nur relevant, wenn es zuvor noch nie geklappt hat, denn eigentlich musste ich hier nichts besonderes konfigurieren)

Update:
Seite heute morgen um kurz nach 6 Uhr tritt dieser Fehler bei mir auch wieder auf. Aktuell hilft auch kein Neustart. Vermutlich liegt dies am Testnet, welches schon seit einige Tagen nach meinem Gefühl sehr instabil läuft...

Bearbeitet von Cookies statt Coins^^
Link zu diesem Kommentar
Auf anderen Seiten teilen

Hallo,

ich habe schon mehrere Neustarts versucht, ohne Erfolg. Leider weiß ich auch nicht ob ich die Portöffnung korrekt gemacht habe. 13000 und 12000, wie genau das aber aussehen soll habe ich noch nicht ganz herausgefunden. Weiß jemand vielleicht ob es überhaupt mit dsl lite möglich ist ( IPv6 ), oder kann mir jemand ein Screenshot von den Portöffnungen posten? Ich habe eine Connection Box von Unitymedia und finde es da sehr kompliziert aufgebaut. 
 

Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 5 Stunden schrieb mlange:

Leider weiß ich auch nicht ob ich die Portöffnung korrekt gemacht habe. 13000 und 12000, wie genau das aber aussehen soll habe ich noch nicht ganz herausgefunden. Weiß jemand vielleicht ob es überhaupt mit dsl lite möglich ist ( IPv6 ), oder kann mir jemand ein Screenshot von den Portöffnungen posten? Ich habe eine Connection Box von Unitymedia und finde es da sehr kompliziert aufgebaut. 

Ich habe nochmal die Anleitung durchgelesen und hier steht, man soll im Router die Port-Weiterleitung für TCP#13.000 und für UDP#12.000 aktivieren: https://docs.prylabs.network/docs/prysm-usage/p2p-host-ip/#port-forwarding

Das hatte ich bis heute auch falsch konfiguriert, bin erst durch deinen Beitrag darauf gekommen das erneut zu prüfen. So sollte es nun richtig sein:PortForwarding.thumb.png.416ef5e600ba8677b1ff4772a3ae07ff.png

Zur Erklärung:

  • Der erste Eintrag in der Liste (TCP/UDP#30303) ist für dich nicht relevant. Das habe eingetragen weil es in der Anleitung für den Betrieb eines ETH-1.0-Nodes empfohlen wurde, für die Beacon-Chain hier ist das aber erst mal nicht nötig.
  • Der zweite und dritte Eintrag sollte hier bei deinem Router ähnlich aussehen. Nur bei "Computer" musst du eben die private IP-Adresse deines Raspberry Pi eintragen. Und du hattest etwas von "IPv6" geschrieben. Tatsächlich bezieht sich das alles auf IPv4, evtl hast du da einen Fehler. Für IPv6 habe ich nichts konfiguriert.

 

Wenn ich nun einen dieser drei Einträge editiere, dann sieht das so aus (am Beispiel des zweiten Eintrags, d.h. für TCP#13.000):

PortForwarding_TCP13000.thumb.png.e943e710b27187c68fca33b5a59942ba.png

 

Bei der von dir verwendeten Unitymedia  Connection Box sieht es vermutlich so aus: https://wiki.instar.de/Fernzugriff/Port_Weiterleitung/Unitymedia_Connectbox/
Die Konfiguration sollte hier genauso erfolgen.

----------------------------------

Und zusätzlich habe ich auf derselben Seite (https://docs.prylabs.network/docs/prysm-usage/p2p-host-ip/#setting-the---p2p-host-ip-flag) nun gelesen, dass man die Beacon-Chain mit folgendem Parameter aufrufen soll:
prysm.sh beacon-chain --p2p-host-ip=$(curl -s v4.ident.me)

Das hatte ich bisher auch nicht in meinem Skript und habe es vorhin noch hinzugefügt, in der Hoffnung, dass es mit diesen Änderungen etwas stabiler läuft.

 

 

Bearbeitet von Cookies statt Coins^^
Link zu diesem Kommentar
Auf anderen Seiten teilen

  • 2 Wochen später...

Hallo zusammen,

ich habe nun nochmals mehrere Versuche gemacht um Prysm zum laufen zu bringen. Nachdem ich mit den gleichen Router Einstellungen die Beacon Chain auf meinem Macbook zum laufen gebracht hatte war ich doch sehr verwundert, also habe ich noch ein paar Versuche gestartet das ganze auf Ubuntu zum laufen zu bringen, leider ohne Erfolg.

Jetzt bin ich aber auf ein paar sehr interessante Artikel gestoßen und hab diese auch gleich umgesetzt, mit dem Ergebnis, dass die Beacon Chain ohne Probleme läuft:

Zuerst habe ich meinen Raspberry bootbar von einer SSD anhand von dieser Anleitung gemacht https://www.verdrahtet.info/2020/05/22/raspberry-pi-4-von-ssd-booten-ganz-ohne-sd-karte/

Danach habe ich die Raspbian OS Beta 64 Bit installiert : https://www.raspberrypi.org/forums/viewtopic.php?f=117&t=275370

Nachdem der Raspberry nun mit 64 bit läuft, war es auch kein Problem mehr Prysm zu starten.

Das ganze Setup dauert nur 30 min, für mich also die beste und schnellste Lösung einen Validator zu betreiben.

Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 14 Stunden schrieb mlange:

Nachdem der Raspberry nun mit 64 bit läuft, war es auch kein Problem mehr Prysm zu starten.

Sehr gut, dass es bei dir nun auch klappt! 👍
Als ich vor ein paar Monaten mit meinen ersten Versuchen startete, gab es noch keine 64-Bit-Raspbian-OS, daher habe ich nun Ubuntu.. Wenn ich alles neu installieren müsste, dann würde ich nun wohl auch das 64-Bit-Raspbian-OS nehmen 😉

Link zu diesem Kommentar
Auf anderen Seiten teilen

  • 2 Wochen später...

@mlange, @Cookies statt Coins^^ auf was für einem Filesystem ist eure Blockchain gespeichert? FAT32, NTFS, ext4? Wenn ich das Setup mit "Boot from SSD" wähle habe ich eine grosse FAT32-Partition, wenn ich das Raspberry-Image z.B. via Raspberry Pi Imager auf die SSD schreibe. Grundsätzlich hätte ich aber vermutet, dass ext4 unter Linux zu bevorzugen ist, habt ihr da was angepasst?

(statt einer SSD versuche ich es übrigens gerade mit einem USB-3.1-Stick (512 GB), da ich keine grössere SSD rumliegen habe -> wahrscheinlich nicht ideal, aber sollte trotzdem schneller sein als die Micro-SD-Karte)

Noch eine Frage an @mlange: Denkst du, dass dein Problem eher durch das Verschieben auf die SSD oder durch die Verwendung von Raspbian statt Ubuntu gelöst wurde? Mir ist noch etwas unwohl dabei die Firmware auf einen Beta-Stand zu aktualisieren, wenn das nicht unbedingt nötig ist 😉

Bearbeitet von f5b7
Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 45 Minuten schrieb f5b7:

auf was für einem Filesystem ist eure Blockchain gespeichert?

Bei mir ZFS. Bringt aber nur was wenn man viel RAM hat was bei einem Pi wohl eher Mangelware ist.

Ansonsten ext4. Verglichen mit den anderen von dir genannten Kandidaten ist ext4 robuster zum Beispiel nach einem Stromausfall. Dank Journaling kann ext4 einfach weiter machen wo es aufgehört hat.

vor 48 Minuten schrieb f5b7:

Wenn ich das Setup mit "Boot from SSD" wähle habe ich eine grosse FAT32-Partition, wenn ich das Raspberry-Image z.B. via Raspberry Pi Imager auf die SSD schreibe.

Partitioniere die Platte einfach selber. Ich würde 2-3 Partitionen empfehlen. Die Boot Partition sollte so um die 500MB groß sein. Das reicht dann gleich für mehrere Betriebssysteme. Ich weiß nicht mal was das untere Limit ist wenn man nur ein Betriebssystem installieren möchte. Zweite Partition Root mit dem Rest des Platten Platzes. Optional die zweite Partition nur so groß machen wie dein Betriebssystem werden soll und den Rest dann in eine dritte Partition packen und die dann für Home nutzen. Hat den Vorteil, dass du später das Betriebssystem gegen irgendwas anderes austauschen kannst ohne die dritte Partition zu berühren. Damit bleibt dir die Blockchain erhalten.

vor 55 Minuten schrieb f5b7:

(statt einer SSD versuche ich es übrigens gerade mit einem USB-3.1-Stick (512 GB), da ich keine grössere SSD rumliegen habe -> wahrscheinlich nicht ideal, aber sollte trotzdem schneller sein als die Micro-SD-Karte)

Für das Testnet sollte sogar eine HDD funktionieren. Später für das Mainnet wird es dann aber schwierig. Nicht jede SSD ist schnell genug für die ETH Chain. Kannst ja zum Spaß mal das ETH Mainnet Syncen um zu testen wie gut dein System damit klar kommen würde.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Danke für eure Antworten! Habe gerade festgestellt, dass ich bei der Boot-Partition überlesen hatte, dass da MB steht, nicht um GB 🤦‍♂️ Daher alles gut, mit dem Standard-Prozedere erhält man eine kleine Boot-Partition (FAT32) und eine grosse System-Partition (ext4), welche ich wie von @skunk beschrieben noch splitten könnte.

Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 4 Stunden schrieb f5b7:

Noch eine Frage an @mlange: Denkst du, dass dein Problem eher durch das Verschieben auf die SSD oder durch die Verwendung von Raspbian statt Ubuntu gelöst wurde? Mir ist noch etwas unwohl dabei die Firmware auf einen Beta-Stand zu aktualisieren, wenn das nicht unbedingt nötig ist 😉

Inzwischen ist die Firmware für "stable" freigegeben und fast alle anderen Schritte (von der verdrahtet.info-Anleitung) entfallen, zumindest für die 64-bit Beta-Version.

Ab frischem 64-bit-Image braucht es also nur noch folgende Schritte:

sudo apt update && sudo apt full-upgrade
sudo nano /etc/default/rpi-eeprom-update

(von "critical" nach "stable" ändern)

sudo rpi-eeprom-update -d -f /lib/firmware/raspberrypi/bootloader/stable/pieeprom-2020-06-15.bin

(resp. die neueste Version, bei mir war es pieeprom-2020-07-16.bin)

sudo reboot

Quellen:
https://www.raspberrypi.org/documentation/hardware/raspberrypi/bcm2711_bootloader_config.md#usbmassstorageboot
https://www.youtube.com/watch?v=SfxFS2mK6ok

 

Bearbeitet von f5b7
Link zu diesem Kommentar
Auf anderen Seiten teilen

Hat jemand eine Ahnung, ob man die durch ./prysm.sh validator accounts create generierte Deposit Data auch für eine (manuelle) Transaktion in den Medalla Testnet Deposit Contract (0x07b39F4fDE4A38bACe212b546dAc87C58DfE3fDC) verwenden kann, um dann dort zu staken statt im Onyx Testnet (mit Deposit Contract 0x0F0F0fc0530007361933EaB5DB97d09aCDD6C1c8)?

Und warum erhalte ich keine Seed Phrase? Wenn ich das Deposit gemäss Anleitung für Medalla mache (https://medalla.launchpad.ethereum.org/overview), wird mir eine Seed Phrase angezeigt.

Allerdings verstehe ich noch nicht ganz, wie ich das von der dortigen Anleitung dann mit dem Prysm Validator "zusammeführen" würde, resp. ob der durch das deposit.sh-Script generierte Keystore durch den Prysm-Validator überhaupt verwendet werden kann oder ob das ein inkompatibles Format ist (sieht zumindest anders aus).

Link zu diesem Kommentar
Auf anderen Seiten teilen

Habe mich wohl gerade in einem ungünstigen Moment damit beschäftigt. Gestern erschien eine neue Version von Prysm, die sich mit dem Medalla-Testnetz verbindet. Auch der "Become a Validator"-Link von prylabs.net zeigt jetzt neu auf das Medalla-Launchpad (ausser in meinem Browser-Cache immer noch auf die Anleitung für Onyx) 😏

Werde daher nochmal von vorne starten, ist wohl am einfachsten.

Link zu diesem Kommentar
Auf anderen Seiten teilen

  • 2 Wochen später...
Am 27.7.2020 um 21:37 schrieb f5b7:

auf was für einem Filesystem ist eure Blockchain gespeichert? FAT32, NTFS, ext4?

Hi, ich habe bei mir das Filesystem Ext4. Hatte damals nicht viel über das passende Filesystem nachgedacht sondern einfach diese Anleitung hier befolgt, und dort wurde auch Ext4 empfohlen: https://kauri.io/running-an-ethereum-full-node-on-a-raspberrypi-4-m/9695fcca217f46feb355245275835fc0/a.

Auch meine Root-Partition läuft unter Ext4. Das wurde auch automatisch so eingerichtet, als ich das Ubuntu-Image installiert hatte.

 

Am 27.7.2020 um 22:34 schrieb skunk:

Für das Testnet sollte sogar eine HDD funktionieren. Später für das Mainnet wird es dann aber schwierig. Nicht jede SSD ist schnell genug für die ETH Chain. Kannst ja zum Spaß mal das ETH Mainnet Syncen um zu testen wie gut dein System damit klar kommen würde.

Dem kann ich nur zustimmen: Die Testnet-Konfiguration lief auf der HDD zum Schluss sehr gut und stabil. Davor hatte ich drei Wochen lang versucht, die ETH1.0-Mainnet-Chain auf der HDD zu synchronisieren, aber es war erfolglos: Ich war immer eine Minute hinter dem aktuellen Block und habe es mit der HDD nicht geschafft diese synchron zu bekommen. Ich habe es dann aufgegeben und mir nun ein SSD gekauft. Die muss ich nun demnächst mal einbauen und dasselbe erneut versuchen. Nur zur Zeit habe ich aber leider etwas wenig Zeit dafür.
 

Am 1.8.2020 um 12:42 schrieb f5b7:

Gestern erschien eine neue Version von Prysm, die sich mit dem Medalla-Testnetz verbindet.

Habe auch erst  vor ein paar Tagen auf das neue Testnet umgestellt ("Medalla Testnet"). Nachdem mein Validator stabil lief, habe ich das alles nicht mehr so aktiv mitverfolgt.
Das hier ist nun mein neuer Validator im Medalla-Testnet: https://beaconcha.in/validator/32487
Vor zwei Tagen habe ich die 32 Test-ETH einbezahlt, aber nun muss ich noch vier Tage warten, bis der Validator aktiviert wird. D.h es werden nur immer Schritt für Schritt neue Staking-Clients zugelassen..

Was ich mittlerweile mit dem neuen Testnet dazugelernt habe ist, dass es aktuell ja vier unterschiedliche Staking-Clients gibt. Die Anleitung hier in diesem Thread bezog sich bisher auf den Prysm-Client (https://medalla.launchpad.ethereum.org/prysm).
Daneben könnte man für das Staking von ETH auch einen der folgenden Clients verwenden:
- Lighthouse (https://medalla.launchpad.ethereum.org/lighthouse)
- Nimbus (https://medalla.launchpad.ethereum.org/Nimbus)
- Teku (https://medalla.launchpad.ethereum.org/Teku)

Soweit ich das mitbekommen habe, ist das aktuelle Testnet hier nun ein Multiclient-Testnet, in dem alle vier Clients parallel betrieben werden. Die vorherigen Testnets in diesem Thread waren hingegen reine Prysm-Client-Testnets.
Weitere Infos zum aktuellen Testnet und zu den weiteren ETH2.0-Meilensteinen gibt es hier: https://medalla.launchpad.ethereum.org/

  • Thanks 2
Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 26 Minuten schrieb Cookies statt Coins^^:

Was ich mittlerweile mit dem neuen Testnet dazugelernt habe ist, dass es aktuell ja vier unterschiedliche Staking-Clients gibt.

Ich hatte die anderen Clients auch irgendwo gelesen und wollte diese auch mal probieren, konnte dann die Liste aber nicht mehr finden. Danke für die Liste :) 

Link zu diesem Kommentar
Auf anderen Seiten teilen

Am 14.8.2020 um 17:14 schrieb skunk:

Ich hatte die anderen Clients auch irgendwo gelesen und wollte diese auch mal probieren [...]

Ja, das ist wohl eine gute Idee 👍
Denn in den letzten Tagen kam es zu größeren Problemen im Testnet, zunächst aufgrund eines Synchronisierungsfehlers des Prysm-Clients. Daraufhin gab es eine übereilte Korrekturversion, die aber noch mehr Fehler verursacht hatte. Details dazu kann man hier nachlesen: https://medium.com/prysmatic-labs/eth2-medalla-testnet-incident-f7fbc3cc934a

Hier in dem Bericht findet man im letzten Drittel (Kapitel "The risk of client dominance") auch eine Verteilung der aktuellen ETH2.0-Clients:
- 78,6% sind Prysm-Clients
- 8,5% sind Lighthouse Clients
- 12,9% sind andere/ unbekannte Clients

Und in dem Bericht wird auch empfohlen, andere Clients auszuprobieren, um im Fehlerfall schnell wechseln zu können: "However, it is good practice to try other implementations and experiment switching between them as needed".

Ich werde mir daher auch mal als nächstes den Lighthouse-Client ansehen und diesen auf dem Raspberry Pi installieren. Bei Lighthouse gibt es sogar eine Installationsanleitung, die auf den Raspberry  Pi mit Ubuntu zugeschnitten ist: https://lighthouse-book.sigmaprime.io/pi.html

Link zu diesem Kommentar
Auf anderen Seiten teilen

  • 1 Monat später...

Kurzer Zwischenstand von mir zum Raspberry-Pi-Staking-Projekt:
Der Prysm-Client läuft aktuell sehr stabil auf meinem Raspberry Pi.
Alles Weitere habe ich leider nicht zum Laufen gebracht (ETH_1.0-Mainnet-Node, Lighthouse-Client).

Zum ETH_1.0-Node:
Ich wollte zusätzlich zur Beacon-Chain mittels Geth die ETH_1.0-Blockchain synchronisieren, da die ETH_2.0-Beaconchain dorthin eine Anbindung braucht. Das ETH_1.0-Göerli-Testnet hat auf dem Raspberry mit Geth ohne Probleme geklappt zu synchronisieren.  Aber wenn ich versuche, das Mainnet zu synchronisieren, dann schafft es der Raspberry Pi auch nach drei Wochen Laufzeit nicht, die Synchronisation erfolgreich zu beenden.

Der Node bleibt immer 1 bis 2 Minuten hinter dem aktuellen Stand der Blockchain und schafft es nie, diese komplett einzuholen, beispielhafter Auszug aus dem Log

INFO [09-10|17:10:09.130] Imported new block headers               count=2    elapsed=2.093s       number=10834711 hash="5f536b…73ef54" age=1m39s

Diese Einträge könnten wochenlang so weiter gehen, ich habe es nach drei Wochen aufgegeben...
Ich weiß nicht, woran es scheitert. Die einzigste Erklärung wäre, dass die angeschlossene SSD-Festplattte zu langsam wäre. Ein Geschwindigkeitstest zeigt mir aber meiner Meinung nach sehr gute Werte an.
Geschwindigkeitstest:

#write-speed:
dd if=/dev/zero  of=/mnt/ssd/ethereum/deleteme.dat bs=32M count=64 oflag=direct
#read-speed:
dd if=/mnt/ssd/ethereum/deleteme.dat of=/dev/null bs=32M count=64 iflag=direct

Dabei erhalte ich als Ergebnis folgende Werte:
#Write:   9.2875 s, 231 MB/s
#Read:  6.0763 s, 353 MB/s


Zum Test wollte ich daher statt "Geth" dann "Nethermind" auf dem Raspberry installieren, um damit ebenfalls einen ETH_1.0-Node zu betreiben. Auf der Prysm-Seite wird Nethermind neben Geth ebenfalls als ETH_1.0-Node empfohlen: "Eth2 nodes can use any sort of eth1 node http endpoint as long as it supports reading smart contract logs":  Go-Ethereum, Nethermind, Besu, vgl https://docs.prylabs.network/docs/prysm-usage/setup-eth1/
Aber Nethermind konnte ich nicht erfolgreich auf dem Raspberry Pi installieren. Alle Versuche liefen auf einen Fehler.

Aber auf obigen Link wird nun seit Kurzem auch ein "Third-party eth1 provider" vorgeschlagen.
Vor einigien Tagen habe ich mich daher kostenlos bei den vorgeschlagenen infura.io registriert und meinen Beacon-Node mit deren ETH_1.0-Testnet verbunden. Im Testnet läuft es sehr stabil. Ich hoffe mal, dass es dann im Mainnet ebenfalls stabil laufen sollte.
Infura ist für den Privatanwender kostenlos, sofern man nicht mehr als 100.000 Anfragen pro Tag an den ETH_1.0-Node sendet. In den letzten vier Tagen hatte ich jeweils ca 18.000 Anfragen pro Tag. Falls diese Anzahl im Mainnet nicht schlagartig explodieren würde, dann könnte man den Infura-ETH_1.0-Node auch kostenlos im Mainnet zur  Staking-Anbindung nutzen.
Jedoch ist diese Lösung mit einem gewissen Risiko behaftet, so dass ich mit dieser Lösung noch nicht 100%ig zufrieden bin. Am liebsten wäre es mir, wenn ich den ETH_1.0-Mainnet-Node noch bei mir zu Hause zum Laufen bringen würde..

Hat da jemand von euch zufällig Erfahrungen und betreibt auf nem Raspberry Pi einen ETH_1.0-Node im Mainnet?

 

Zum Lighthouse-Client:
Das andere Probleme das ich hatte: Ich wollte den Lighthouse-Staking-Client auf dem Raspberry Pi installieren. Auch hier hatte ich das Problem, dass ich keine passenden Installationsdateien für den ARM-Prozessor des Raspberry Pi bekommen habe. Und das selbst Kompilieren der Sourcen brach mit einer Fehlermeldung ab.

Naja, ich werde es in ein paar Wochen nochmal versuchen in der Hoffnung, dass bis dahin die Software auch auch für den ARM-Prozessor besser zur Verfügung steht...

Bearbeitet von Cookies statt Coins^^
Link zu diesem Kommentar
Auf anderen Seiten teilen

Würde auch eine 400-GB-Micro-SD-Karte am USB-Port funktionieren? Ider sind die Datenraten dann zu gering? Oder die Lebensdauer?

Ich warte noch auf eine neue Raspi-Version mit mehr RAM als 8 GB, dann sollte auch RAM kein Problem mehr sein. Derzeit sind die Speichermodule wohl noch nicht verfügbar.

 

Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 1 Stunde schrieb Jokin:

Würde auch eine 400-GB-Micro-SD-Karte am USB-Port funktionieren? Ider sind die Datenraten dann zu gering? Oder die Lebensdauer?

Ich warte noch auf eine neue Raspi-Version mit mehr RAM als 8 GB, dann sollte auch RAM kein Problem mehr sein. Derzeit sind die Speichermodule wohl noch nicht verfügbar.

 

Eine SD Karte funktioniert derzeit mit dem Testnet, wird aber die Datenraten vom Mainnet nicht verarbeiten können. Die Lebensdauer wird auch stark darunter leiden da eine SD Karte dafür nicht ausgelegt ist.

Warum willst du denn auf eine Version mit noch mehr RAM warten? Prysm läuft sehr stabil mit einem Raspberry 8 GB. Bei mir läuft Pryms derzeit auf zwei Raspberry mit 8 GB und auf einem Raspberry mit 4 GB.

  • Thanks 1
Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 3 Stunden schrieb mlange:

Eine SD Karte funktioniert derzeit mit dem Testnet, wird aber die Datenraten vom Mainnet nicht verarbeiten können.

Dem kann ich nur zustimmen. Eine SD-Karte ist zu langsam. Ich habe verschiedene Geschwindigkeitstest gemacht, mit folgendem Ergebnis:

#SD-Card:
#write: 147.462 s, 14.6 MB/s
#read: 47.2076 s, 45.5 MB/s

#HDD-Festplatte (mit Standard-USB-3-Adapter):
#Write:  73.7619 s, 29.1 MB/s
#Read: 68.2707 s, 31.5 MB/s

# SSD-Festplatte (mit Standard-USB-3-Adapter):
#Write:  13.4834 s, 159 MB/s
#Read: 9.71535 s, 221 MB/s

# Dieselbe SSD-Festplatte (mit USB-3-Adapter, der UASP unterstützt):
#Write:   9.2875 s, 231 MB/s
#Read:  6.0763 s, 353 MB/s

Fazit: Mit einer SD-Karte bist du 15x langsamer als mit einer SSD-Festplatte.

Ich hatte mir auf Amazon extra folgenden USB-Adapter zum Anschluss der SSD-Festplatte gekauft, da dieser genauso wie meine Festplatte das schnell UASP-Übertragungsprotokll unterstützt: https://www.amazon.de/gp/product/B081W2CQ66/

Meiner Meinung nach habe ich schon das Maximum an Geschwindigkeit herausgeholt, aber es klappt trotzdem nicht..

 

Hier nochmal die Infos zum Geschwindigkeitstest, um diesen mal bei sich selbst durchzuführen:

#write-speed:
dd if=/dev/zero  of=/mnt/ssd/ethereum/deleteme.dat bs=32M count=64 oflag=direct
#read-speed:
dd if=/mnt/ssd/ethereum/deleteme.dat of=/dev/null bs=32M count=64 iflag=direct

Man erstellt mit dem dd-Linux-Befehl eine 2 GB große Datei und zählt die Sekunden, wie lange das Schreiben und dann das Lesen dauert. Bei dem hier fett-markierten Pfad ("/mnt/ssd/ethereum/") muss man natürlich den eigenen Pfad zur Festplatte oder zur SD-Karte eintragen. Misst mal eure Geschwindigkeiten auf dem Raspberry Pi und schreibt mir, wie schnell ihr so seid..

 

vor 3 Stunden schrieb mlange:

Bei mir läuft Pryms derzeit auf zwei Raspberry mit 8 GB und auf einem Raspberry mit 4 GB.

Ich habe das nur auf einem 4GB Raspberry Pi am laufen. Merkst du da einen Unterschied zwischen 8 und 4 GB bzw wie sind deine Erfahrungen so im Allgemeinen?
Welchen ETH_1.0-Node hast du jeweils angebunden? Es wird ja beim Starten der Beacon-Node dringend empfohlen, mithilfe des Parameters "--http-web3provider" einen eigenen ETH_1.0-Node anzugeben. Im Testnet verbindet sich der Prysm-Client ohne diesen Parameter automatisch mit den ETH_1.0-Nodes, die von Prysm bereitgestellt werden. Für eine durchgängige Verfügbarkeit wird aber nicht garantiert und die Frage ist auch, wie lange sie diesen Service dann auch im Mainnet anbieten  wollen..

 

vor 5 Stunden schrieb Jokin:

Ich warte noch auf eine neue Raspi-Version mit mehr RAM als 8 GB

Der Raspberry Pi mit 8 GB ist ja erst diesen Sommer neu raus gekommen. Ich denke, das wird dann noch einige Weile dauern, bis es ein noch neueres Modell gibt. Oder hast du dazu neue Infos?
Da ich aktuell auch nur die 4-GB-Version habe, überlege ich mir auch noch, rechtzeitig vor dem Start die neueste Version zu kaufen, dort dann nochmal alles neu  einzurichten, um dann die alte Version im Notfall als Backup verwenden zu können..

Bearbeitet von Cookies statt Coins^^
  • Love it 1
Link zu diesem Kommentar
Auf anderen Seiten teilen

Hmm, also irgendwie muss ich mich da nun doch mal dran machen ...

Verdammt, sind die SSD billig geworden! Mir fallen grad die Augen aus!

Braucht die SSD keine separate Stromversorgung mit dem von Dir empfohlenen Adapter? Das wäre ja dann schon sehr interessant.

Was hältst Du denn von dem Einkaufskorb? Sollte eigentlich passen, oder? Den Lüfter würde ich dann noch PWM-gesteuert laufen lassen, da muss ich dann nochmal bisschen basteln falls die mitgelieferten Lüfter zu laut sind.

2005991618_Bildschirmfoto2020-09-27um17_51_10.thumb.png.6fb46200ad9754e736442761c72eacb6.png

(das wird bei mir immer mehr zur Raspi-Server-Farm ... hab ja noch mehr Raspis als Server im Einsatz :D )

 

Eventuell baue ich dann auch mal ein komplettes Tutorial auf um die ganzen verstreuten Informationen zusammenzuführen. Meinste, wir sollten da vielleicht ein gemeinsam bearbeitbares Google-Doc für aufbauen?

Und die SD-Karte bleibt Backup-Medium, reicht ja dafür auch aus. 

Bearbeitet von Jokin
  • Like 2
Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 6 Stunden schrieb Jokin:

Braucht die SSD keine separate Stromversorgung mit dem von Dir empfohlenen Adapter?

Ja genau, die SSD-Festplatte kann ohne zusätzliche Stromversorgung direkt an den Raspberry Pi angeschlossen werden. Die SSD-Festplatten brauchen nicht so viel Strom wie die alten, großen HDD-Festplatten.

So sieht mein ETH_2.0-Stakingnode aus:
DSC_9420e.thumb.JPG.15ccdf170542ee48f678eece630af388.JPG

Links die SSD-Festplatte, welche nur über den Adapter am USB-3-Anschluss des Raspberry Pi angeschlossen ist.

 

vor 6 Stunden schrieb Jokin:

Was hältst Du denn von dem Einkaufskorb? Sollte eigentlich passen, oder?

Ja genau, dein Warenkorb sieht gut aus. Damit ist alles enthalten, was du benötigst.
Deine ScanDisk-Festplatte hatte ich auch in der engeren Auswahl, hatte mich dann aber doch für die Crucial entschieden. Ich denke, die sind alle gut und von den Werten her sehr ähnlich.

 

vor 6 Stunden schrieb Jokin:

Eventuell baue ich dann auch mal ein komplettes Tutorial auf um die ganzen verstreuten Informationen zusammenzuführen. Meinste, wir sollten da vielleicht ein gemeinsam bearbeitbares Google-Doc für aufbauen?

Ja das stimmt, die Infos sind sehr gestreut und teilweise auch gar nicht mehr aktuell, aber leider kann man hier die eigenen Einträge nach einer gewissen Zeit selbst gar nicht mehr editieren. Eine Wiki-Seite oder auch Google-Docs wäre ganz gut, an der man dann zusammen dran arbeiten kann und die man dann auch im Nachhinein jederzeit wieder aktualisieren kann. 👍

 

 

Bearbeitet von Cookies statt Coins^^
  • Thanks 1
Link zu diesem Kommentar
Auf anderen Seiten teilen

Oh, Du hast nichtmal einen passiven Kühler drauf?

Hast Du mal die Temperatur geprüft? Eventuell läuft der zu heiß.

Ich bestelle in den nächsten Tagen den Kram und dann geht's los.

Gibt es hier stille Mitleser, die auch mitmachen wollen?

Klar, 260 Euro für das Zeug ist nicht wenig, aber auf den Lüfter will ich nicht verzichten.

Bearbeitet von Jokin
  • Up 1
Link zu diesem Kommentar
Auf anderen Seiten teilen

Erstelle ein Benutzerkonto oder melde Dich an, um zu kommentieren

Du musst ein Benutzerkonto haben, um einen Kommentar verfassen zu können

Benutzerkonto erstellen

Neues Benutzerkonto für unsere Community erstellen. Es ist einfach!

Neues Benutzerkonto erstellen

Anmelden

Du hast bereits ein Benutzerkonto? Melde Dich hier an.

Jetzt anmelden
×
×
  • Neu erstellen...

Wichtige Information

Wir haben Cookies auf Deinem Gerät platziert. Das hilft uns diese Webseite zu verbessern. Du kannst die Cookie-Einstellungen anpassen, andernfalls gehen wir davon aus, dass Du damit einverstanden bist, weiterzumachen.