mrbiz
Please get a replacement unit from your dealer. Sorry!

@gutemine
Danke für die Hinweise erst mal. Nur mal ins Blaue hinein, würde die Option noauto in der fstab nicht zum selben Zustand führen?

emanuel
Das geht ohne Probleme, auch mit 2.2.

Fallstricke könnten sein, dass man z.B. beim kopieren von OE2.2 nach OE2.2-exp hardlinks erstellt anstatt richtige Kopien (am besten immer neu herunterladen), oder dass man bitbake.env bereits von einem Verzeichnis verwendet hat und sich dann wundert, wieso später das falsche Bitbake aufgerufen wird, wenn man sich in einem anderen Verzeichnis befindet. Um letzteres zu vermeiden, kann man entweder immer make benutzten statt bitbake direkt aufzurufen, oder man kann für jede Version ein neues Terminal-Fenster öffnen.

TERM=dumb kommt von Deinem SSH-Client. vt100 wäre der Default, sofern der SSH-Client nichts setzen würde.

NFS-Mounts hängen beim 3.4er Kernel mit der Version der nfs-utils nicht, wenn man eine NFS-Version mit angibt. Ich glaube 4.0 war ok. Es gibt da scheinbar Unterschiede zwischen dem dokumentierten und dem tatsächlichen Verhalten.

Zitat von gutemine

obi - du hast meine reply aber gesehen dass das flash-rescue wegen der Größe verweigert, oder habe ich was falsch gemacht (und muss erst ein bin.gz draus machen oder ähnliches ?)

Da wurde der Falsche Dateityp auf den Webserver kopiert. Es sollte vmlinux.gz-rescue*.bin sein. Wird gleich behoben...

Danke auch für den Hinweis mit den nfs-utils. Sollte nun auch erledigt sein.

Die Feeds sollten eigentlich bereits zugänglich sein, nur sind sie eben nicht auf dreamboxupdate.com verlinkt. D.h. vom installierten Image aus kann man bereits Pakete nachinstallieren und Online-Updates durchführen.

Zu „experimental“ oder „unstable“ gekennzeichneten Images gehört der „unstable“ Feed.

Ein „experimental“ Feed ist in der Regel identisch mit dem „unstable“ Feed, enthält nur manchmal den Inhalt etwas früher (d.h. wenn keine Fehler beim Online-Update auftreten vielleicht eine Stunde) und wird für letzte Tests vor der Veröffentlichung von Updates verwendet. Benutzung auf eigene Gefahr. Ich würde es nicht empfehlen. Deshalb werden sie auch nicht nicht beworben. Hätten sie unbedingt geheim bleiben sollen, wären sie allerdings sicherlich besser versteckt worden.

Analog gilt dasselbe für testing und stable (statt experimental und unstable), wenn wir größere Änderungen haben und einen stable Branch erstellen (wie z.B. mit dora-stable geschehen, als der Wechsel auf gstreamer 1.0 kam).

Zitat von Viril

Habe mich doch verguckt. Bei make help steht auch die dm8000 dabei.

Viel Glück, aber die Boxen, für die es Version 2.2 schon nicht gab, sind hiermit absolut ungetestet. Erkenntnisse darüber bitte in einen anderen Foren-Thread auslagern.

Zitat von gutemine

Wenn du beim Online Recovery wieder ein 2.2 Image haben willst ... kannst du bleiben

Auch mit der Online-Recovery-Funktion vom Rescue-Image aus 2.5 bekommt man mit den MIPS-Boxen ein 2.2er Image. Sobald 2.5 stabil genug erscheint, wird man auch mit einem Rescue-Image aus 2.2 ein 2.5er Image bekommen.

Demnächst wird es die Möglichkeit geben, Einstellungen vor dem Flashen zu sichern und später wiederherzustellen. Wegen Abwärtskompatibilität sind aber bei MIPS noch Tests notwendig. Bis dahin gibt es keinen Grund, ein Rescue-Image aus 2.5 einem aus 2.2 vorzuziehen.

Zitat von makaveli

enigma2/4.3.0r19+gitAUTOINC+c04d0644c9-r0/enigma2_4.3.0r19/usr/share/doc/enigma2/LICENSE [license-checksum]

Ich weiß nicht, wo gitAUTOINC+c04d0644c9 bei Dir herkommt, aber von uns kommt es meiner Meinung nach nicht. Bei uns kommt enigma2 aus nem Tarball, nicht von Git. Im Tarball existiert die Datei.

Bitte ohne lokale Änderungen testen.

Lauter gute Ideen!

Zitat von gutemine

Und das mit gcc 5.3 heisst das es mir beim Debian auf der Box sogar mit Jessie schon eng werden wird, aber das ist ein lösbares Problem

Benutzt Du in Deinem Debian für die Boxen Binaries von uns (außer Kernel+Treiber)? Dann wäre wichtiger, dass die Versionen der benötigten Bibliotheken auch passen, oder dass Du die Bibliotheken einfach aus unserem Image kopierst, zusätzlich zu denen von Debian. Die Compilerversion macht normalerweise kaum etwas aus.

Zitat von wiesel25

Du hast geschrieben dass mit dem aktullen Stand man ein Image auch für die dm900 erstellen kann.

Warum klappt das bei mir nicht...oder ist das aktuell noch nicht möglich ?

Anhand Deiner Fehlermeldung kann ich ehrlich gesagt nicht erkennen, wo das Problem liegt. Aber geht es denn bei Dir mit MACHINE=dm520 z.B.? Es würde mich nicht wundern, wenn das ebenfalls fehlschlägt.

Sollte es doch gehen, bitte ich Dich zu überprüfen, ob Du noch Reste von früheren Versionen in Deiner Umgebung hast. Am besten in einem neuen Verzeichnis neu beginnen und schauen, dass kein altes Bitbake im $PATH steht.

Zitat von dre

Habt ihr meine patches für gcc5 übernommen oder braucht es die gar nicht mehr? Hatte aktuell noch keine zeit, es selbst zu testen.

Die Patches sind nicht mehr nötig. OpenEmbedded benutzt in der Version „krogoth“ übrigens selbst gcc-5.3.0.

makaveli
Habe Deinen Fehler gefunden, werde ihn gleich beheben.

Grundsätzlich würde ich empfehlen, in conf/local-ext.conf (neu anlegen) folgende Zeile hinzuzufügen:

INHERIT += "opendreambox-autorev"

Dadurch werden von vielen Softwarepaketen immer automatisch die neuesten Versionen verwendet.

Hi,

allgemein zur Info: Mit dem aktuellen Stand wurden Images für dm520/dm525, dm820, dm900 und dm7080 erstellt. Auch MIPS wurde im Betrieb getestet. Hier und da gibts noch kleine Mängel bei den MIPS-Boxen aufgrund des älteren Kernels (z.B. mit NFS), die demnächst noch behoben werden. Für viele Nutzer ist der aktuelle Stand sicherlich schon alltagstauglich.

Trotzdem ist es sinnvoll, aufgrund der geringen Verbreitung diese Version zunächst noch als Betaversion zu betrachten. Nur für Mutige, auf eigene Gefahr usw...

Nix-niX
Der Fehler kommt mit relativ hoher Wahrscheinlichkeit durch lokale Änderungen. Bitte überprüfe, ob er auch ohne Änderungen auftritt.

Zitat von tine1084

Bei mir kommt mit der dm7080hd nach dem erstellen des Backups auch nicht der download button. Bei der dm820hd funktioniert es aber das nach dem Backup der download button kommt.

Ist Dein Image auf der dm7080 vielleicht deutlich größer? Kommt es vielleicht zu einem Timeout beim Laden der Seite? Wird das Laden manuell mit Escape abgebrochen?

Die Software ist bezüglich Rescue-Loader dieselbe bei dm7080 und dm820.

Zitat von sirdir

Also ich habe längere Zeit gewartet (mehrere Minuten, nachdem die Statusmeldungen vom Backup kamen) und die Seite auch mehrmals neu geladen. Erst nach einem Reboot war das Backup da.
Browser: Safari 8.0.2, OS X 10.10.1

Kann ich leider nicht reproduzieren (OSX 10.10, Safari 8 und Chrome 39). Was mir aufgefallen ist, ist dass Safari die Backup-Seite erst anzeigt, wenn sie vollständig geladen ist. Daher empfehle ich erst mal, stattdessen Firefox oder Chrome zu benutzen.

Zitat von sirdir

Nein, anscheinend muss man erneut in's recovery image booten um die Dateien angezeigt zu bekommen...
Zwar etwas unschön, aber eigentlich nicht so schlimm da man ja kaum ein backup machen und es sofort wieder zurückspielen muss.

Man muss nicht neu booten, sondern einfach abwarten, bis die Sicherung abgeschlossen ist. Das ist dann, wenn der Download-Button erscheint. Sobald /data/.recovery/backup.tar.gz angelegt wurde, erscheint es auch auf der backup-Seite (backup.dhtml). Eventuell muss man die Seite neu laden (F5), falls der Browser eine alte Version im Cache hat.

Falls es sich reproduzierbar anders verhält, bitte ich um Angabe von Browser- und Betriebssystem-Versionen.

Zitat von DerMicha

Und warum muss das (wie immer) so ein Hexenwerk sein ?
Im dbackup von gutemine, wähle ich "sichern" oder "flashen"

Der Weg wurde gewählt, damit die Sicherungen garantiert konsistent sind. Sicherungen aus dem laufenden Betrieb heraus beinhalten in aller Regel einen inkonsistenten Zustand, da der Inhalt des Dateisystem während des Backups geändert werden könnte und da geänderte Einstellungen noch nicht gespeichert sein könnten.

Zitat von m0rphU

Der Rescue-Loader kommt nicht per Online-Update oder beim Neu-Flashen oder? Also anders als früher der SecondstageLoader?

Ja. Den Rescue-Loader muss man manuell aktualisieren, wenn man das möchte. Es ist aber im Allgemeinen nicht nötig. Selbst wenn es ab und zu neue Rescue-Images auf dreamboxupdate.com gibt, beinhalten sie oft nur kleine Änderungen, die für die Funktion des Rescue-Loaders nicht wichtig sind.

Wir aktualisieren ihn nicht automatisch, weil das Schreiben auf den SPI-Speicher relativ langsam ist und somit die Zeitspanne während des Schreibens, in der ein Stromausfall oder "gewaltsames" Ausschalten vom Benutzer vorkommen könnte, zu lang ist. Dabei würde der Rescue-Loader kaputt gehen, und es wäre besonders doof, wenn man das erst bemerkt, wenn man ihn braucht. Deshalb: Immer nach Update des Rescue-Loaders sofort überprüfen, ob er funktioniert.