Das Backup-Script hinterlässt die Mounts so, wie es sie beim Start vorgefunden hat. Ist /data vor dem Backup gemountet, bleibt es auch nachher gemountet. Wenn /data nach dem Backup gemountet ist, wird auch der Download-Button angezeigt. Mit der Browserversion hat das zunächst nichts zu tun.
In der nächsten Version wird /data nach dem Backup wieder gemountet, so dass der Button immer sichtbar sein sollte.
Der fehlende Download-Button war tatsächlich ein Bug. Sorry, war mir vorher nicht aufgefallen. Sollte im nächsten Update behoben sein.
Falls es automatisiert werden soll evtl. so, aber ohne Gewähr:
apt-cache -oAPT::Cache::ShowDepends=false \
-oAPT::Cache::Important=true \
-oAPT::Cache::ShowOnlyFirstOr=true \
-oAPT::Cache::ShowRecommends=true \
depends $PACKAGE | sed -e 's,\<Recommends\>:,,' -e 's,<[a-z0-9.+-]\+>,,' | xargs apt-get installAber für den speziellen Fall ist eher folgendes besser:
Depends: python-misc (<< 2.7.11) | python-argparseHast du eine Idee wie man dpkg dazu bringt die Recommends: im Control File nicht zu ignorieren? Ich bräuchte das jetzt als Unterscheidung zum OE2.2 aber er installiert mir die notwendigen Pakete nicht.
Grundsätzlich installiert dpkg garkeine anderen Pakete mit. Meinst Du vielleicht apt? Das installiert standardmäßig auch alle Pakete, die in Recommends stehen. Aber ich nehme an, Du rufst apt-get -f install auf. Das lässt „Recommends“ aus, weil das Ziel von -f („Fix Broken“) ist, defekte Installationen mit minimalem Aufwand zu beheben.
Das Paket python-argparse gibt es übrigens auch in dora (openembedded-core/meta/recipes-devtools/python/python-argparse_1.2.1.bb).
Ich würde nur gerne wissen, ob es einen Grund gibt, wieso der Ordner /var/lib/samba samt Unterordner nicht gelöscht wird, obwohl Samba deinstalliert wurde.
Es werden in der Regel nur Dateien gelöscht, die auch bei der Installation Teil des Pakets waren. Zur Laufzeit angelegte Dateien bleiben erhalten, sofern es kein „postrm“-Skript gibt, das sie löscht. Man könnte eines anlegen, aber da die Deinstallation von Samba bisher kein wichtiger Usecase war, hat sich dessen niemand angenommen.
Sehe post 7 obi
Ich kann dort keinen Fehler erkennen.
Tar ist irgendwie bei centos defekt
Hier hilft vielleicht der Buildtools-Tarball weiter.
"-bash: words: bad array subscrip"
Danke, der Fehler ist inzwischen behoben.
wenn ich 2 links anlege geht das mit dpkg-scanpackages
es scheint so als passt der installationsort nicht
Danke! Problem erkannt. Wird demnächst korrigiert.
Was bedeutet dieses ignoret ist die Backup Datei nun nicht benutzbar?
Die Meldungen bezüglich der Sockets sind normal und können sowohl mit älteren als auch mit aktuellen Versionen erscheinen. Auf die Funktion des Backups hat es keine Auswirkung.
RL 103 ist nicht geeignet/fertig für OE 2.5, ich tendiere das wird demnächst behoben in 104/105
Gibt es etwas konkretes in Version 103, das nicht so funktioniert wie erwartet?
Man kann übrigens mit jeder Version jedes beliebige Image sichern (ab 102) und wiederherstellen.
Existiert das neue enigma2 schon im openembedded, und nur das enigma2- repository ist noch nicht aktuell?
Ja.
Also ich hätte Ghosts Antwort so interpretiert, dass es das neue enigma2 eben (immer) noch NICHT gibt...
Das war zu dem Zeitpunkt korrekt. Mittlerweile ist die Information überholt.
Das Problem wurde in dropbear behoben, aber nicht in der Version in opendreambox 2.2.
In opendreambox 2.5 ist dropbear 2016.72 enthalten. Vermutlich tritt das Problem damit nicht mehr auf.
Scheinbar ist Dein Rescue Image zu alt. Ich würde es an Deiner Stelle mal versuchen zu aktualisieren. Da Du derzeit kein normales System hast, ist es allerdings etwas riskant.
Die Befehle dazu wären:
wget http://dreamboxupdate.com/opendreambox/2.2/stable/images/dm7080/vmlinuz-rescue--3.4-r0.51-dm7080-20160405.bin
flash-rescue vmlinuz-rescue--3.4-r0.51-dm7080-20160405.binUm sicherzugehen, dass Du Dich nicht aus der Box aussperrst, könntest Du vorher ein Image manuell flashen und danach wget und flash-rescue aus dem laufenden Image heraus ausführen. Damit das nicht mit der zitierten Meldung fehlschlägt, müsstest Du /usr/sbin/librecovery editieren. Darin nach --numeric-owner suchen und aus der Zeile löschen, in der es vorkommt.
Anschließend:
wget http://dreamboxupdate.com/opendreambox/2.2/stable/images/dm7080/dreambox-image-deb-dm7080-20160514.tar.xz
flash-tarball dreambox-image-deb-dm7080-20160514.tar.xzBei wget immer darauf achten, dass der Download auch vollständig ist.
Busybox stellt eine Version von tar bereit, die auch in älteren Versionen bereits verfügbar war. Darüber hinaus liegt GNU tar seit kurzem auf unserem Feed.
Ich glaube die erste Version des Rescue-Loaders hat die Daten noch nicht lesen können.
Hier findest Du eine neuere Version:
http://dreamboxupdate.com/open…r0.51-dm7080-20160405.bin
Du kannst sie im Normalbetrieb (bitte nicht vom Rescue-Loader aus) auf die Box kopieren (oder direkt mit wget herunterladen) und dann über telnet oder ssh hiermit einspielen:
flash-rescue vmlinuz-rescue--3.4-r0.51-dm7080-20160405.binIch denke, dass die Daten verloren sind. Zumindest ist das Dateisystem defekt. Du könntest noch ein Image der Systempartition laden (bei den „6 Feldern für Experten“, mmcblk0p1) und am PC mit irgendwelchen Tools versuchen, einige Dateien wiederherzustellen, wenn es Dir wirklich wichtig ist. Das Dateisystem ist Ext4.
Anschließend würde ich erst mal versuchen, ob sich die Box neu flashen lässt. Wenn das nicht der Fall ist, ist wohl eine Reparatur nötig.
TSMusik
Danke für die detaillierte Fehlerbeschreibung! Das Problem wird im Ethernet-Treiber liegen. Bei Gelegenheit werde ich mal danach schauen.
Hier gibt es ein neues Rescue Image, in dem die IPv6-Probleme behoben sein sollten:
https://dreamboxupdate.com/ope…perimental/images/dm7080/
Dem was m0rphU geschrieben hat kann ich nur zustimmen.
kommt mount: mount point /data does not exist.
Hiergegen würde
mkdir /datahelfen.
Aber um Deine Ursprüngliche Frage zu beantworten: Du könntest die Systempartition manuell einbinden:
mount /dev/mmcblk0p1 /mntAnschließend findest Du Deine Dateien im Verzeichnis /mnt.
Dann kannst Du mit folgendem Befehl manuell ein Backup erstellen:
tar -C /mnt -czf backup.tar.gz .Sollte es wegen irgendwelchen Meldungen mit „sockets“ abbrechen, kannst Du die Dateien einfach löschen und es nochmal versuchen.
Die Datei backup.tar.gz kannst Du dann z.B. mit SCP von der Box kopieren.
OoZooN:
Bei einem „internal compiler error“ lässt sich nicht viel machen. Ist vielleicht die CPU überhitzt? Gabs irgendwelche Warnungen im Kernel-Log? Evtl. hilft es, PARALLEL_MAKE zu reduzieren. Tritt es wieder an derselben Stelle auf, wenn Du es nochmal versuchst?
Leider ist es das nicht. Die Zeile findet sich bereits in openembedded-core/meta/classes/kernel.bbclass.
makaveli
Wer die exakte Stelle findet, die das Verursacht, bekommt ein Bier ausgegeben.
Es hat allerdings keinen Einfluss auf das Endergebnis. Insofern ist die Kategorisierung (Error statt Warning) an dieser Stelle etwas irreführend.
Thomas_SX1
Im Rescue Loader steht „It's possible to create and download a backup copy of your data.“
Dort auf „create“ klicken, um ein Backup zu erstellen. Anschließend erscheint es auch zum download auf der Dir bekannten Seite. Wenn das Erstellen schon fehlschlägt, kannst Du mal die Fehlermeldungen dazu hier posten.
Die Firmware beinhaltet unabhängig vom verwendeten Tuner immer eine satellites.xml. Daher sollte es eigentlich nicht zu dem Fehler kommen. Danke dennoch für den Hinweis! Das könnte man mal abfangen. Eine cables.xml kann man zwar reinkopieren, aber sie sollte eigentlich für einen Sendersuchlauf nicht notwendig sein. Die Bouquets und Senderlisten befinden sich übrigens in /etc/enigma2/.