Beiträge von ClaudiaF

@Raybuntu und @TheMexx

ich denke ich weiß was bei mir das Problem auslöste - DHCP. Mit dem Warten auf das Netzwerk funktionierten 50 Reboots 49 mal
und einmal nicht. Nach Umstellung auf feste IP funktionierten alle 50 Reboots.
Ich weiß, dass ist nicht wirklick aussagekräftig, was mich aber dennoch vermuten lässt, dass dies der Grund ist, ist die Tatsache
dass das booten nun viel schneller von sich geht, so schnell, dass ich nicht mal die ersten Bootmessages wie ethtool ... sehe.

Ich werde das noch analysieren, denke aber nicht dass ich das diese Woche noch schaffe - interessiert mich aber schon sehr, mal sehen.

Gruß
Claudia

@Raybuntu
Ja, systemd scheint ein guter Kandidat dafür zu sein. Mal sehen ob ich den Grund bei mir finden kann
und ( @TheMexx ) ich werde mal den Timeout auf 20 erhöhen und testen.

Gruß
Claudia

@infinity
leider konnte ich mein Kabel nicht finden. Ich befürchte sogar dass ich das weggeschmießen habe.
Solltest Du deines noch irgendwie finden und testen können, wäre ich natürlich sehr am Ergebnis interessiert.

@Raybuntu, @TheMexx
nachdem ich nochmal alles platt gemacht und neu installiert habe kann ich ethtool ohne segfault aufrufen,
also gehe ich davon aus, dass meine alte Installation korrumpiert war. Aber, da ich gestern und heute
sicherlich über 20x neu installiert und sicherlich 40-50 neu gebootet habe ist mir aufgefallen, dass es vereinzelt
passierte das der ethtool.service nicht gestartet war, weil der 10 Sekunden timeout zuschlug.
Ein systemctl start ethtool.service hat das gelöst, aber wenn man nicht explizit danach schaut, bemerkt man es nicht.
Im Log war ausser der Info das die Konfiguration für eth0 fehlschlug nichts zu sehen.
Ich schaue ob ich da noch näheres dazu herausfinde aber ehrlich gesagt bin ich nicht sehr optimistisch.

Vielleicht könnt Ihr das bei Euch nochmal nachstellen, nicht das ich doch noch irgendwo eine Leiche in der Installation habe,

Ich bin wie folgt vorgegangen:
Am Monitor wird die Info in rot ausgegeben dass der ethtool service nicht geladen wurde. (ziemlich am Anfang des Bootmessages)
Wenn Kodi Hauptmenü verfügbar war habe ich mich per ssh eingeloggt und

systemctl status ethtool.service

aufgerufen. War im Fehlerfall immer zu sehen dass der Service nicht geladen ist.
Dann per

ethtool --show-offload eth0 | grep summing

anzeigen lassen ob tx off-ist. War im Fehlerfall nie.

Wenn keine rote Fehlermeldung zu sehen war, habe ich einfach wieder reboot in der Kodi-GUI gedrückt.

Wie gesagt, vereinzelt aufgetreten - bei ca. 10 mal booten 1 mal Fehler.

Gruß
Claudia

Zitat von infinity

@ClaudiaF
Bzgl. des eMMC boots. Da hab ich grade noch eine offizielle Anleitung mit einer USB-A to USB-A Methode gefunden: http://files.pine64.org/doc/rock64/gui…oid_To_eMMC.pdf
Weiß allerdings nicht, ob das mit LibreELEC auch hinhauen würde. Rein Prinzipiell: Würde ein erster Boot von einer eMMC auch die zweite Partition automatisch expanden, oder ist das nicht analog von dem Verhalten einer MicroSD auf die eMMC übertragbar?

Ich habe mir eben einen Wolf gesucht nach meinem USB-A zu USB-A Kabel... werde es die Tage weitersuchen müssen... ich habs jedenfalls für meinen FireTV irgendwo liegen. Dann kann ich das selbst mal testen.

Hi infinity,

super, danke. Den Guide kannte ich noch nicht.
Solch ein Kabel müsste ich auch noch rumliegen haben - aber gleiches Problem - wo ist es??
Werde heute Abend mal schauen und probieren ob man darüber auch das LibreElec oder ein Linux Image Image installieren kann.
Geb wieder Bescheid.

Cheers
Claudia

Zitat von Raybuntu

Gerne alles hier posten oder als issue auf Github dann vergesse ich das auch nicht.
Du scheinst ja sehr fit mit Linux Sachen allgemein zu sein von daher schlage ich vor das du solche Sachen in meinem LE issue tracker postest. Von mir aus auch auf Deutsch. Gilt allgemein für alle hier die meinen einen Fehler gefunden zu haben.
Ich warte noch auf den rebase von kwiboo für LE9 und im Moment bin ich etwas eingespannt mit anderen Projekten.

Du meinst diesen "https://github.com/Raybuntu/LibreELEC.tv/issues" Issue tracker, korrekt?
Mach ich gerne und wenn es Dir nichts ausmacht auch gerne in Englisch.

Cheers
Claudia

Hier die versprochenen iperf3 Werte.

Testumgebung: Linux Laptop und Rock64 direkt mit Fritzbox-Switch verkabelt.

4 Tests gemacht, der Rock64 immer einmal als client und einmal als server
- 1 und 2 mit 100Mbit Konfiguration und bei 2 mit tx checksumming off
- 3 und 4 mit 1Gbit Konifuration und bei 4 mit tx checksumming off

Bei der 100Mbit Konfiguration sieht eigentlich alles ganz gut aus,
bei der 1Gbit ist es ok wenn tx checksumming disabled ist, nichtsdestotrotz
sind die hohen retransmit Werte, die ich nur sehe wenn der Rock64 als client arbeitet (nicht beim Linux Laptop als client), bedenklich.
Ich vermute der Treiber ist noch ausbaufähig, hoffe da liefert Rockchip noch etwas nach.
Das ich nur ~600 Mbit erreiche, liegt wohl eher an meinem alten Laptop und der Frizbox.

1. Test

eth0 = 100Mb full duplex
ethtool --show-offload eth0 | grep summing
rx-checksumming: on
tx-checksumming: on

rock64 als iperf3 client
Connecting to host linuslap, port 5201
[ 4] local rock64 port 37146 connected to linuslap port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 11.5 MBytes 96.5 Mbits/sec 0 127 KBytes
[ 4] 1.00-2.00 sec 11.2 MBytes 93.8 Mbits/sec 0 133 KBytes
[ 4] 2.00-3.00 sec 11.0 MBytes 92.3 Mbits/sec 0 133 KBytes
[ 4] 3.00-4.00 sec 11.4 MBytes 95.4 Mbits/sec 0 140 KBytes
[ 4] 4.00-5.00 sec 11.2 MBytes 93.8 Mbits/sec 0 140 KBytes
[ 4] 5.00-6.00 sec 11.2 MBytes 93.8 Mbits/sec 0 140 KBytes
[ 4] 6.00-7.00 sec 11.2 MBytes 94.4 Mbits/sec 0 150 KBytes
[ 4] 7.00-8.00 sec 11.2 MBytes 94.4 Mbits/sec 0 150 KBytes
[ 4] 8.00-9.00 sec 11.4 MBytes 95.4 Mbits/sec 0 209 KBytes
[ 4] 9.00-10.00 sec 11.2 MBytes 93.8 Mbits/sec 0 209 KBytes

rock64 als iperf3 server
Accepted connection from linuslap, port 54326
[ 5] local rock64 port 5201 connected to linuslap port 54327
[ ID] Interval Transfer Bandwidth
[ 5] 0.00-1.00 sec 10.9 MBytes 91.6 Mbits/sec
[ 5] 1.00-2.00 sec 11.2 MBytes 94.2 Mbits/sec
[ 5] 2.00-3.00 sec 11.2 MBytes 94.1 Mbits/sec
[ 5] 3.00-4.00 sec 11.2 MBytes 94.2 Mbits/sec
[ 5] 4.00-5.00 sec 11.2 MBytes 94.0 Mbits/sec
[ 5] 5.00-6.00 sec 11.2 MBytes 94.2 Mbits/sec
[ 5] 6.00-7.00 sec 11.2 MBytes 94.1 Mbits/sec
[ 5] 7.00-8.00 sec 11.2 MBytes 94.1 Mbits/sec
[ 5] 8.00-9.00 sec 11.2 MBytes 94.2 Mbits/sec
[ 5] 9.00-10.00 sec 11.2 MBytes 94.2 Mbits/sec
[ 5] 10.00-10.03 sec 373 KBytes 92.2 Mbits/sec

2. Test
eth0 = 100Mb full duplex
ethtool -K eth0 tx off
ethtool --show-offload eth0 | grep summing
rx-checksumming: on
tx-checksumming: off

rock64 als iperf3 client
Connecting to host linuslap, port 5201
[ 4] local rock64 port 37150 connected to linuslap port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 11.4 MBytes 95.8 Mbits/sec 0 116 KBytes
[ 4] 1.00-2.00 sec 11.1 MBytes 93.3 Mbits/sec 0 120 KBytes
[ 4] 2.00-3.00 sec 11.2 MBytes 94.4 Mbits/sec 0 124 KBytes
[ 4] 3.00-4.00 sec 11.2 MBytes 93.8 Mbits/sec 0 124 KBytes
[ 4] 4.00-5.00 sec 11.2 MBytes 93.8 Mbits/sec 0 132 KBytes
[ 4] 5.00-6.00 sec 11.2 MBytes 93.8 Mbits/sec 0 132 KBytes
[ 4] 6.00-7.00 sec 11.2 MBytes 93.8 Mbits/sec 0 148 KBytes
[ 4] 7.00-8.00 sec 11.3 MBytes 94.9 Mbits/sec 0 205 KBytes
[ 4] 8.00-9.00 sec 11.2 MBytes 93.8 Mbits/sec 0 205 KBytes
[ 4] 9.00-10.00 sec 11.2 MBytes 93.8 Mbits/sec 0 205 KBytes

rock64 als iperf3 server
Accepted connection from linuslap, port 54333
[ 5] local rock64 port 5201 connected to linuslap port 54334
[ ID] Interval Transfer Bandwidth
[ 5] 0.00-1.00 sec 10.9 MBytes 91.5 Mbits/sec
[ 5] 1.00-2.00 sec 11.2 MBytes 93.9 Mbits/sec
[ 5] 2.00-3.00 sec 11.1 MBytes 93.5 Mbits/sec
[ 5] 3.00-4.00 sec 11.2 MBytes 94.1 Mbits/sec
[ 5] 4.00-5.00 sec 11.2 MBytes 93.9 Mbits/sec
[ 5] 5.00-6.00 sec 11.2 MBytes 94.1 Mbits/sec
[ 5] 6.00-7.00 sec 11.2 MBytes 94.0 Mbits/sec
[ 5] 7.00-8.00 sec 11.2 MBytes 94.3 Mbits/sec
[ 5] 8.00-9.00 sec 11.2 MBytes 94.0 Mbits/sec
[ 5] 9.00-10.00 sec 11.2 MBytes 93.9 Mbits/sec
[ 5] 10.00-10.03 sec 348 KBytes 93.7 Mbits/sec

3. Test
eth0 = 1Gb full duplex
ethtool --show-offload eth0 | grep summing
rx-checksumming: on
tx-checksumming: on

rock64 als iperf3 client
Connecting to host linuslap, port 5201
[ 4] local rock64 port 37158 connected to linuslap port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 105 KBytes 856 Kbits/sec 6 1.41 KBytes
[ 4] 1.00-2.00 sec 0.00 Bytes 0.00 bits/sec 10 1.41 KBytes
[ 4] 2.00-3.00 sec 0.00 Bytes 0.00 bits/sec 2 1.41 KBytes
[ 4] 3.00-4.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
[ 4] 4.00-5.00 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes
[ 4] 5.00-6.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
[ 4] 6.00-7.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
[ 4] 7.00-8.00 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes
[ 4] 8.00-9.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
[ 4] 9.00-10.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes

rock64 als iperf3 server
Accepted connection from linuslap, port 54336
[ 5] local rock64 port 5201 connected to linuslap port 54337
[ ID] Interval Transfer Bandwidth
[ 5] 0.00-1.00 sec 67.4 MBytes 565 Mbits/sec
[ 5] 1.00-2.00 sec 72.4 MBytes 608 Mbits/sec
[ 5] 2.00-3.00 sec 72.4 MBytes 607 Mbits/sec
[ 5] 3.00-4.00 sec 72.5 MBytes 608 Mbits/sec
[ 5] 4.00-5.00 sec 72.4 MBytes 607 Mbits/sec
[ 5] 5.00-6.00 sec 72.6 MBytes 609 Mbits/sec
[ 5] 6.00-7.00 sec 72.9 MBytes 611 Mbits/sec
[ 5] 7.00-8.00 sec 72.9 MBytes 612 Mbits/sec
[ 5] 8.00-9.00 sec 72.8 MBytes 611 Mbits/sec
[ 5] 9.00-10.00 sec 72.8 MBytes 611 Mbits/sec
[ 5] 10.00-10.04 sec 3.14 MBytes 603 Mbits/sec

4. Test
eth0 = 1Gb full duplex
ethtool -K eth0 tx off
ethtool --show-offload eth0 | grep summing
rx-checksumming: on
tx-checksumming: off
rock64 als iperf3 client
Connecting to host linuslap, port 5201
[ 4] local rock64 port 37162 connected to linuslap port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 74.2 MBytes 622 Mbits/sec 970 96.2 KBytes
[ 4] 1.00-2.00 sec 75.3 MBytes 631 Mbits/sec 634 74.9 KBytes
[ 4] 2.00-3.00 sec 74.0 MBytes 621 Mbits/sec 863 87.7 KBytes
[ 4] 3.00-4.00 sec 74.6 MBytes 626 Mbits/sec 818 76.4 KBytes
[ 4] 4.00-5.00 sec 76.2 MBytes 639 Mbits/sec 702 66.5 KBytes
[ 4] 5.00-6.00 sec 74.1 MBytes 622 Mbits/sec 711 73.5 KBytes
[ 4] 6.00-7.00 sec 75.8 MBytes 636 Mbits/sec 805 55.1 KBytes
[ 4] 7.00-8.00 sec 73.7 MBytes 618 Mbits/sec 946 76.4 KBytes
[ 4] 8.00-9.00 sec 73.1 MBytes 613 Mbits/sec 644 77.8 KBytes
[ 4] 9.00-10.00 sec 75.3 MBytes 632 Mbits/sec 759 74.9 KBytes

rock64 als iperf3 server
Accepted connection from linuslap, port 54339
[ 5] local rock64 port 5201 connected to linuslap port 54340
[ ID] Interval Transfer Bandwidth
[ 5] 0.00-1.00 sec 68.0 MBytes 571 Mbits/sec
[ 5] 1.00-2.00 sec 72.4 MBytes 608 Mbits/sec
[ 5] 2.00-3.00 sec 72.1 MBytes 605 Mbits/sec
[ 5] 3.00-4.00 sec 72.8 MBytes 610 Mbits/sec
[ 5] 4.00-5.00 sec 72.8 MBytes 611 Mbits/sec
[ 5] 5.00-6.00 sec 72.4 MBytes 607 Mbits/sec
[ 5] 6.00-7.00 sec 73.4 MBytes 616 Mbits/sec
[ 5] 7.00-8.00 sec 73.4 MBytes 616 Mbits/sec
[ 5] 8.00-9.00 sec 73.2 MBytes 614 Mbits/sec
[ 5] 9.00-10.00 sec 72.6 MBytes 609 Mbits/sec
[ 5] 10.00-10.03 sec 1.85 MBytes 464 Mbits/sec

Gruß
Claudia

Zitat von Raybuntu

Das ist ja seltsam mit dem ethtool. Schaue mal was da schief läuft.

Danke, gibt es eigentlich einen seperaten Ort wo buildspezifische Anmerkungen gepostet werden sollen oder auch hier?
Sachen wie zum Beispiel ethtool oder, was Neues, eventlircd.

PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
  354 root      20   0    2888    624    544 R  94.4  0.0 151:27.93 eventlircd  
 4046 root      20   0  126852  29800  24852 R  94.4  0.7   0:01.03 kodi.bin    
 4050 root      20   0    2704   1604   1396 R  11.1  0.0   0:00.03 top

Cheers
Claudia

@Raybuntu
ok, dann gilt es nur noch ein lauffähiges ethtool Programm zu bauen bzw aus der armhf zu nehmen und dann sollte das Problem behoben sein.

Ein kurzer Test (hab mir das ethtool von einem anderen Image geliehen) mit

ethtool -K eth0 tx off

und rekonfigurierter Schnittstelle

[ 3942.021112] rk_gmac-dwmac ff540000.eth eth0: Link is Up - 1Gbps/Full - flow control rx/tx

zeigt bis dato das es generell funtioniert. iperf tests mache ich später (oder weiß jemand wie man addons auf der command line installiert?)

LibreELEC:/tmp # ls -l /usr/sbin/ethtool
-rwxr-xr-x 1 root root 215672 Sep 13 13:21 /usr/sbin/ethtool

LibreELEC:/tmp # ls -l ethtool
-rwxr-xr-x 1 root root 215524 Sep 27 12:15 ethtool

LibreELEC:/tmp # /usr/sbin/ethtool
Segmentation fault

LibreELEC:/tmp # /tmp/ethtool
ethtool: bad command line argument(s)
For more information run ethtool -h

Gruß
Claudia

Zitat von Raybuntu

Noch nicht probiert, aber kwiboo hatte letztens ein paar stmmac commits in kernel. Evtl ist das schon gefixed aber im Moment bin ich mit anderen allgemeinen LibreELEC Projekten beschäftigt.

Ok, wenn ein neues build vorhanden ist teste ich es gerne.
Nur zur Info, ayufan hat es damit gelöst dass er per ethtool rx/tx checksumming disabled. Siehe hier.

Ich hätte das gerne auch mit dem Rock64 getestet, allerdings schmeisst ethtool ein segmentation fault.

Gruß
Claudia

Zitat von Raybuntu

Im moment tut sich wenig. Keine Ahnung was das für ein 1G Problem sein soll.

Verstehe ich richtig, Du hast kein Problem damit?
Sprich der Netzwerkport läuft im 1Gb full duplex Modus und Du siehst per iperf(3) zufriedenstellende Werte?
Oder noch einfacher, einfach per ssh verbinden und ein dmesg aufrufen - Du bekommst den kompletten Kernel-Ring-Buffer?

Bei mir ist dem nicht so. Ich habe Abbrüche. Wenn ich aber das Interface auf 100Mb full duplex setze habe ich keine Probleme.
Das Gigabit-Problem ist bei der Pine Community bekannt, die Stock Images scheinen dies auch noch immer zu haben, aber
ayufans Images seit einiger Zeit nicht mehr.

Danke und Gruß
Claudia

So, eMMC und SD angekommen und angetestet - hier die Ergebnisse.

Zuerst die guten Nachrichten:

@Raybuntu
Danke und ja, die trigger auf none bzw. nicht setzen löst das Problem des hektischen blinkens,
eröffnet aber ein anderes Problem, nämlich dass man nun nicht mehr erkennen kann,
wann das System heruntergefahren ist. Da ich jetzt aber weiß wo ich editieren/konfigurieren muß
werde ich sicherlich eine für mich pasende Lösung finden.

Das Image kann auf die eMMC geschrieben und gestartet werden. (siehe Seltsames weiter unten)
Im Gegensatz zur SD ist es ein bisschen schneller beim booten, (ca 2 Sekunden)
im Gebrauch mit der Gui(KODI) ist aber nicht wirklich ein Unterschied zu merken.

Hier der Beweis, wenn auch schwer nachzuvollziehen ob von eMMC gestartet wurde.
Getestet, von SD und eMMC gebootet, habe ich das YouTube Addon und die
h264 test streams von Big Bunny und Avatar - liefen problemlos.

Nun zum Problem:
Das Image scheint den Gigabit-Bug noch zu haben, da es Abbrüche gibt wenn das Interface für 1Gb gesetzt ist.
Die ayufan Linux-Images haben dieses Problem nicht mehr, vielleicht hilft Dir das um den Fehler einzugrenzen bzw. zu beheben.
Leider kann ich Dir nicht sagen, mit welcher Version er dies gefixt hat.
Eine 100MBit Konfiguration läuft stabil.

Und nun zum Seltsamen (ist wohl eher ein Rock64 issue).
Da muß ich ein kleines bisschen ausholen.

Am Rock64 sind ein USB2 Stick und die eMMC sowie die SD im Einsatz. Linux images von ayufan.

Als erstes habe ich mir das debian minimal image auf die SD geschrieben und gebootet -> debian welcome.
Danach habe ich per wget ein ubuntu minimal auf den USB Stick kopiert und per dd auf die eMMC geschrieben.
Shutdown, SD entfernt und neu gestartet -> Ubuntu welcome erhalten -> OK
Shutdown, SD eingesteckt und wieder gestartet -> Debian welcome erhalten -> OK
Soweit so gut.

Nun habe ich das LibreELEC Image per wget auf den USB gespeichert und
von gebooteten eMMC per dd auf die SD geschrieben.
Reboot -> Ubuntu welcome
Per lsblk geschaut, auf SD ist das LibreELEC Image. fdisk und parted sagen alles ok.
Shutdown, eMMC entfernt und gebootet -> LibreELEC startet.

OK - die mögen sich nicht, aber warum?

Bei Pine64 im Forum gestöbert und über diesen Beitrag gestolpert. (https://forum.pine64.org/showthread.php?tid=4924)

Da wird beschrieben wie ein Image von SD auf eMMC geschrieben wird unter Benutzung von serieller Konsole und Jumper.
Als Grund wird genannt, dass beim Rock64 die Bootreihenfolge eMMC und dann SD ist und daher der Jumper gesetzt
werden muß um von SD zu booten (bzw. nach 2-3 Sekunden entfernt werden muß um von SD zu booten und eMMC zu erkennen)

Hmmm, bei meinen Tests mit den minimal images hatte ich dieses Problem aber nicht.
Nun gut, ein Versuch kann nicht schaden.

eMMC wieder aufgesetzt, Jumper gesteckt und gestartet -> LibreELEC startet. OOKKKayy ??
Shutdown, Jumper entfernt und neu gestartet -> Ubuntu welcome -> hmmm.
Shutdown, Jumper wieder gesetzt und gestartet -> LibreELEC.

Hmmm, ok, schieben wir mal beiseite - nächster Test LibreELEC auf eMMC schreiben.

Von eMMC gebootet und per dd das debian minimal image auf SD geschrieben
Reboot und siehe da - debian welcome (ohne gesetzten Jumper).

Nun, per dd das LibreELEC image auf die eMMC geschrieben.
Reboot - nichts passiert - kein output - keine Registrierung beim DHCP Server - nichts.
Rote und weiße LED leuchten ständig.
Da ich keinen USB-TTL Konverter habe kann ich leider nicht sehen was an die Konsole geschickt wurde.

Hmmm ???

Ausgeschalten, den Jumper gesteckt und gebootet -> Debian welcome.
OK ?? Per lsblk geprüft was mit der eMMC ist und siehe da, die ist nicht vorhanden.
eMMC geschrottet

Moment, da war doch was mit Jumper entfernen um von SD zu booten und eMMC zu sehen - ok - let's give it a try.

Ausgeschalten - Jumper ist gesteckt. Da der Einschaltknopf so klein ist, habe ich den Powerstecker abgezogen
und wieder eingesteckt. Einundzwanzig, Zweiundzwanzig - Jumper entfernt -> Debian welcome.
lsblk -> eMMC ist erkannt. Zwei Partitionen sieht gut aus. fdisk und parted sagen alles ok - was nun??

Hmmm, kann es sein, dass eMMC und eine bootbare eingesteckte SD gleich partioniert sein müssen???

OK, shutdown - SD ausgesteckt und am PC mit LibreELEC beschrieben.
SD wieder am Rock64 eingesteckt und gebootet (ohne gesteckten Jumper).

Nichts - kein output - keine DHCP Registrierung.

Ausgeschalten, Jumper gesteckt, gestartet und nach 2 Sekunden Jumper entfernt -> LibreELEC -> ssh konfiguriert.
Per ssh eingeloggt und per mount geschaut was verfügbar ist. USB und eMMC sichtbar. eMMC laut parted ok.
Warum auch immer, ich habe dann nochmal per dd das LibreELEC image von USB auf eMMC geschrieben.
Gestoppt, Jumper abgezogen, SD entfernt und gebootet -> LibreELEC ist gestartet!!!

Ehrlich gesagt bin ich ein bisschen verwirrt, aber für mich heisst das, dass nur von gebooteter SD mit LibreELEC
image das LibreELEC image auf die eMMC geschrieben werden kann. Wieso auch immer.

Kurzum: wenn man am PC die SD mit LibreELEC beschreibt, vielleicht auch gleich die image Datei auf einen USB speichern.
Dann den USB Stick und die SD am Rock64 einstecken, den Jumper setzen, einschalten und nach 2 Sekunden den Jumper abziehen.

VORSICHT: nicht die anderen PINs (RPi PINs) kurzschließen

LibreELEC konfigurieren (vorallem SSH aktivieren) und dann per ssh verbinden.
Mit dd das image vom USB-Stick auf die eMMC schreiben.

Ausschalten, SD entfernen und neu starten - nun sollte LibreELEC von der eMMC grüßen.

Bin noch immer verwirrt!!

Gruß
Claudia

Zitat von TheMexx

@ClaudiaF: Lustige Geschichte, so ein Schlawiner dein Kind. Auch ich habe auf deinen eMMC Bericht gewartet.

Da hab ich mich mißverständlich ausgedrückt, verdächtige meine Nichte - absolut spitze die Kleine, aber auch sehr neugierig.
Wenn ich Glück habe, bekomme ich den Ersatz schon morgen, Paket ist angeblich bereits unterwegs.

Bis dann
Claudia

@Raybuntu, nur zur Info, eigentlich wollte ich, wie versprochen, die Änderungen und die eMMC testen und Bescheid geben,
leider sind sowohl die SD als auch die eMMC abhanden gekommen .
Meine kleine Tatverdächtige will sich dazu aber nicht äußern.
Neue sind bestellt und kommen hoffentlich am Wochenende an.

Sorry für die Verspätung.
Bis dann.

Claudia

Werd ich am Wochenende testen und Bescheid geben.

Vielen lieben Dank
Claudia

Zitat von infinity

1. Kann mir jemand (am besten für Dummies) erklären, wie man das Image auf die eMMC bekommt? ( ClaudiaF?)

Solltest Du keinen Adapter haben, gäbe es noch die Möglichkeit über eine SD Karte und dem Program Etcher ein minimal Image
wie https://github.com/ayufan-rock64/…04-arm64.img.xz auf
die SD zu schreiben.

Dann von SD booten und einloggen. Am besten gleich danach eine

sudo su

machen, um root zu werden, dann brauchst Du nicht immer ein sudo vor jeden Befehl setzen.

Das LibreELEC Image dann mit

wget https://github.com/Raybuntu/Libre…rypton18.img.gz

holen, mit

gunzip LibreELEC-ROCK64.arm-8.2-rb-krypton18.img.gz

dekomprimieren

und dann mit dd das Image LibreELEC-ROCK64.arm-8.2-rb-krypton18.img auf die eMMC Karte schreiben.
Dazu musst du aber zuerst herausfinden, welches Device deine SD und welches die eMMC ist. Das machst Du mit den Befehl

lsblk

der Output sieht dann ähnlich wie dieser aus

mmcblk0rpmb  179:128  0    4M  0 disk 
mmcblk0boot0 179:64   0    4M  1 disk 
mmcblk0boot1 179:96   0    4M  1 disk 
mmcblk0      179:32   0 28.9G  0 disk 
├─mmcblk0p1  179:33   0  3.9M  0 part 
├─mmcblk0p2  179:34   0   64K  0 part 
├─mmcblk0p3  179:35   0    4M  0 part 
├─mmcblk0p4  179:36   0    4M  0 part 
├─mmcblk0p5  179:37   0    4M  0 part 
├─mmcblk0p6  179:38   0  112M  0 part 
└─mmcblk0p7  179:39   0 28.8G  0 part 
mmcblk1      179:0    0 29.8G  0 disk 
├─mmcblk1p1  179:1    0  3.9M  0 part 
├─mmcblk1p2  179:2    0   64K  0 part 
├─mmcblk1p3  179:3    0    4M  0 part 
├─mmcblk1p4  179:4    0    4M  0 part 
├─mmcblk1p5  179:5    0    4M  0 part 
├─mmcblk1p6  179:6    0  112M  0 part /boot/efi
└─mmcblk1p7  179:7    0 29.7G  0 part /

Hier zeigt sich, dass es ein Device mmcblk0 und ein mmcblk1 gibt.
Beim Beispiel siehst Du , dass das Root-Verzeichnis / bei mit auf mmcblk1p7 lieg.
Da ich von SD gebootet habe weiß ich nun, dass mmcblk1 meine SD und daher mmcblk0 die eMMC ist.
Der Befehl um das LibreELEC Image nun auf die eMMC zu schreiben heisst dann

dd if=LibreELEC-ROCK64.arm-8.2-rb-krypton18.img of=/dev/mmcblk0 bs=10M

Nachdem das Image geschrieben wurde, ein shutdown eingeben.
SD herausnehmen und neu starten.

Ich habe bis dato aber NICHT getestet, ob das Image auch von der eMMC gestartet werden kann.

Gruß
Claudia

Krypton18 Image bootet wenn eMMC nicht angesteckt ist, CEC funktioniert, youtube addon installiert und geguckt - super.

Zwei Sachen die mir aufgefallen sind,

1. die Power LED und die HDD LED blinken wie verrückt auch nach 10 Minuten ohne etwas getan zu haben und
2. die MAC-Berechnung in deinem Image scheint eine andere zu sein als die, die in den Community-Build- oder Stock-Images genutzt wird.

Punkt 1 stört wenn der Rock im sichtbaren Blickfeld ist - ist das bei Dir auch so?
Punkt 2 ist nicht schlimm, wenn das einfach zu lösen ist wäre es ein nice to have.

Gruß
Claudia

Btw. könnte morgen testen ob ein Image auf der eMMC sich anders verhält, falls Du daran interessiert bist.

Muss noch was anderes fertigstellen und werde dann den rock64 an den Monitor schließen und schauen was passiert.
Ggf eMMC abstecken und testen. Melde mich wieder. (spätestens morgen Nachmittag)

Gruß
Claudia

Scheint nicht von SD zu booten. Meine eMMC ist das aktive OS - dort komme ich mit root-libreelec nicht weit

Sollte das aus deiner Sicht funtionieren?

Mit den Rock64 Ubuntuimages habe ich damit kein Problem. Wenn keine SD vorhanden ist, bootet er von eMMC und
wenn SD eingesteckt ist, dann wird von SD gebootet.

Gruß
Claudia

Edit: evtl. uboot config !?

Hab ich versucht - geht nicht.

Moment ...

Darf ich fragen wie die Credentials für das Rock64 Image sind?

Danke
Claudia