tar: invalid tar magic

[alfred.s]

Ich habe nichts verändert. Speedlinux installiert, benötigte Module laut Anleitung nachinstalliert. freetz.sh gestartet. Tools aktualisieren lassen. Im Menü ausgewählt, dass OpenVPN und inadyn-mt dazu kommen und laufen lassen.
Zur Sicherheit auch nochmal alles neu installiert und nochmal probiert. Gleiches Ergebnis.
Am trunk habe ich nullkommanichts verändert.

Wie kommst Du auf die Idee?

 

[alfred.s]

Falls Deine Frage mit CAM an mich gerichtet war: ich weiß nicht, was damit gemeint ist.

 

[alfred.s]

@alfred.s:
...über mehrere Postings hinaus hier im IPPF und im Ticket die entscheidenden Anfragen der Experten stillschweigend ignorieren, die Ratschläge nicht verfolgen,

Kannst Du mir konkret sagen, wo ich das Deiner Meinung nach getan habe?

 

[alfred.s]

Nur nochmal zur Verdeutlichung: exakt nach dieser Methode lasse ich seit Jahren immer wieder Images erstellen. Das hat bisher sowohl für die Speedbox 701V als auch für die 7490 bis Version 6.05 auch problemlos funktioniert. Erst mit der 6.24 klappt es nicht mehr.

 

[er13]

@hermann: ich verweise mal an Deine eigenen Worte an mich, in dem Ton führt die Diskussion zu nix.

@alfred: wenn du von Freetz sprichst, was genau meinst du damit? Wo hast du dein Freetz her genommen/runtergeladen? Hintergrund meiner Fragen: freetz.sh ist kein Bestandteil von Freetz. Das "M" im Namen deines Images sowie freetz.sh, welches wie gesagt kein Bestandteil von Freetz ist, deuten daraufhin, dass du kein originales Freetz verwendest, sondern ein Mod, welcher möglicherweise auf dem originalen Freetz aufsetzt. Wir können (bisher) mit dem originalen Freetz dein Problem nicht nachstellen, daher die Vermutung, der Fehler kommt mit den Modifikationen, die der Mod mitbringt, den du verwendest.

Edit: google liefert Hinweise, es könnte speed2fritz sein.

 

[alfred.s]

Das bringt speedlinux alles mit. Ich mach da manuell garnichts dran.
Speed2fritz ist da auch mit dabei, wird aber separat aufgerufen.

 

[alfred.s]

http://sourceforge.net/projects/freetzlinux/

 

[alfred.s]

http://wiki.ip-phone-forum.de/skript:andlinux
Das ist die Anleitung dazu.

 

[er13]

Sorry, ich habe speedlinux nie verwendet und weiß nicht, was das Script freetz.sh aus diesem macht.

Es wäre wünschenswert, wenn du das originale Freetz auscheckst und (ohne dieses zu modifizieren) testest, ob du auch mit dem originalen Freetz das Problem nachgestellt bekommst. Damit würde man ausschließen, dass es an den Änderungen liegt, die freetz.sh-Script vermutlich vornimmt.

Es spricht nichts dagegen, es unter speedlinux zu versuchen (sofern es sich um ein vollwertiges Linux handelt).

Zum Auschecken verwende bitte den Befehl svn co http://svn.freetz.org/trunk freetz-trunk, anschließend cd freetz-trunk; make menuconfig und nachdem du alles im menuconfig passend zu deiner Box eingestellt hast make oder ./fmake -c (wenn du ein Log des Build-Vorgangs anlegen möchstest). Diese Schritte (mit etwas detaillierteren Erklärungen) sind auch in dieser Anleitung zu finden (die Schritte, in denen es ums Aufsetzen der Build-Umgebung geht, kannst du auslassen, da du ja schon speedlinux hast).

Edit: warum verwenden speed2fritz-Entwickler immer noch den Namen freetzlinux? Sie sollen nicht nur den Namen des Projektes, sondern auch den Namen des SourceForge-Users ändern. Damit eben solche Verwechselungen erst gar nicht entstehen.

 

[alfred.s]

Das ist mal eine klare Ansage. Werde ich gerne versuchen. Kann aber ein wenig dauern.

 

[hermann72pb]

@er13: Zumindest hatte ich damit alfred.s zu einem mehrpostigen Monolog provoziert (es verzeihen ihm die Admins, die Forenregeln liest er anscheinend auch nicht...)! Und daraus konntest du die entscheidenden Worte "speedlinux" und "freetz.sh" rausfiltern... Ok, CAM war es anscheinend doch nicht, aber so weit entfernt davon doch nicht... Auch alles möglichst fertig irgendwo im Netz gefunden mit Minimalaufwand und wenig Verstand.

@alfred.s: Entweder folgst du endlich den Ratschlägen von er13, oder wende dich direkt an jpascher, wenn du speedlinux-spezifische Probleme hast. Ich habe keine Lust dir zum 25 Mal zu erklären, was du hier alles falsch machst. Gib dir bitte Mühe und lies dir nur diesen Thread mindestens 5. Mal akribisch durch. Versetze dich dabei bitte in die Lage der Gegenseite und zähle einfach alle Anweisungen auf, die du im Verlauf des Dialogs ignoriert hast.

MfG

 

[alfred.s]

Noch einmal: sag mir bitte konkret, welche Ratschläge ich hier im Thread ignoriert habe. Und speedlinux habe ich im Beitrag #7 und #8 klar erwähnt. Da speedlinux angeblich der Nachfolger von freetzlinux sein soll, bin ich bisher davon ausgegangen, dass es hier bekannt wäre.

Edit: es war mir bisher nicht klar, dass das zwei verschiedene Baustellen sind, die hier unter dem Namen freetz bzw freetzlinux im gleichen Forum unterwegs sind. Ich dachte, das würde alles aus einer Familie kommen.

 

[PeterPawn]

Da speedlinux angeblich der Nachfolger von freetzlinux sein soll, bin ich bisher davon ausgegangen, dass es hier bekannt wäre.

Ich gehe mal davon aus, daß die meisten Benutzer doch auf der Basis des Wikis von freetz.org vorgehen und dort wird speedlinux zwar auch erwähnt, aber erst als dritte Option.

Die bevorzugte Variante dürfte bei vielen (solange sie keine eigene Cross-Build-Umgebung aufgesetzt haben) "freetz-linux" als VM sein .. man beachte den Bindestrich. Wenn man nämlich dann in "http://sourceforge.net/projects/freetz-linux/" landet, sieht man auch, daß dort eine VM liegt, die ein gutes Jahr jünger ist, als die letzte coLinux-Version unter "freetzlinux". Auch die braucht zwar inzwischen wieder einige Anpassungen, aber als Basis für ein Buildsystem taugt sie locker ...

 

[alfred.s]

Ich bin vor ein paar Jahren auf freetzlinux/speedlinux gestoßen, weil ich ursprünglich nur Speedports hatte. Die meisten davon sind noch in Gebrauch. Mit der 7490 hat das ja vorher auch problemlos geklappt.
Unterstützt denn freetz-linux auch die Speedports? Dann würde ich umsteigen. Zwei verschiedene Build-Umgebungen würde ich gerne vermeiden.

 

[alfred.s]

@er13: ich bin heute früher raus, um es nach Deiner Anleitung auszuprobieren. Erst mal den Trunk von Speedlinux gelöscht, damit da sicher nichts mehr runhängt. Im menuconfig habe ich die 7490 ausgewählt, OpenVPN und inadyn-mt zugefügt und den Freetz-Securitylevel auf 0 gesetzt. Sonst alles auf default gelassen.

Das Ergebnis ist leider das gleiche. Da ./freetz.sh von Speedlinux soweit ich das laienhaft beurteilen kann, auch die gleichen Schritte abhandelt (nur die Downloadverzeichnisse werden ausgelagert, um Platz zu sparen und das Arbeitsverzeichnis hat einen anderen Namen), auch verständlich.

Ich habe die .config, fmake.log und freetz.sh (die wurde beim aktuellen Versuch aber nicht verwendet) mal hier angehängt. Zip war nötig, da die Originaldateien nicht akzeptiert wurden.

 

[hermann72pb]

Das Ergebnis ist nicht das Gleiche, denn "7490_06.24-freetz-devel-13048.de_20150329-080317.image" hat schon mal kein "M" und soweit ich beurteilen kann, lief es beim Packen laut Meldungen alles sauber:

STEP 3: PACK
  checking for left over Subversion directories
  integrate freetz info file into image
packing var.tar
creating filesystem image
  SquashFS block size: 64 kB (65536 bytes)
copying kernel image
  kernel image size: 1.9 MB, max 4.0 MB, free 2.1 MB (2232576 bytes)
copying filesystem image
  filesystem image size: 21.1 MB, max 48.0 MB, free 26.9 MB (28221440 bytes)
packing images/7490_06.24-freetz-devel-13048.de_20150329-080317.image
  image file size: 21.1 MB
done.

FINISHED

Was ist denn jetzt mit diesem Image? Lässt es sich nicht flashen? Hast du davon Hexdump gemacht?

MfG

 

[er13]

Vom Lesen her sieht der Output schon mal gut aus. Ich baue gerade unter meinem Ubuntu ein Image mit deiner .config - mal schauen, was dann der Diff ergibt. Deine Log-Datei ist übrigens unvollständig - der Anfang fehlt (tools, etc.). Hast du den Build-Prozess abgebrochen bzw. abbrechen müssen und dann neu gestartet oder warum ist die Log-Datei gekürzt?

Nur um sicherzustellen... Das Script freetz.sh (so wie es lese) kopiert am Ende das gebaute Image nach /mnt/win/Firmware.new/. Dieser Pfad ist dann wahrscheinlich unter Windows irgendwie zu sehen. In meiner Anleitung fehlt dieser Schritt - d.h. das nach "meiner" Anleitung gebaute Image befindet sich am Ende unter /home/freetz/Desktop/freetz-trunk/images in Linux-Umgebung und hat den Namen (laut deiner Log-Datei) 7490_06.24-freetz-devel-13048.de_20150329-080317.image. Du hast schon diese Datei verwendet und nicht irgendeine ältere aus /mnt/win/Firmware.new/?

Edit: habe jetzt ein Image mit deiner .config gebaut. Auffallend ist folgender Diff-Hunk.

@@ -5761,8 +8243,8 @@
   kernel image size: 1.9 MB, max 4.0 MB, free 2.1 MB (2232576 bytes)
 copying filesystem image
   filesystem image size: 21.1 MB, max 48.0 MB, free 26.9 MB (28221440 bytes)
-packing images/7490_06.24-freetz-devel-13048.de_20150329-080317.image
-  image file size: 21.1 MB
+packing images/7490_06.24-freetz-devel-13049.de_20150329-123622.image
+  image file size: 23.6 MB
 done.
.
 ^[[1mFINISHED^[[0m

Obwohl die einzelnen Pakete sich von der Größe her nicht unterscheiden, ist mein Image 2,5 MB größer. Mein Image ist ein valides Freetz-Image. Scheinbar geht in dem allerletzten Schritt was schief.

Edit2:
ich habe in r13051 einen sehr einfachen Image-Consistency-Check umgesetzt. Meine Vermutung, es geht was in diesem Schritt schief. Der Check behebt das Problem NICHT. Er sorgt lediglich dafür, dass es viel früher erkannt wird, dass das erzeugte Image beschädigt ist. Was die Ursache ist, ist immer noch unbekannt. Könnte ein Busybox-Problem sein, könnte auch ein "Miscompile von Busybox"-Problem sein, könnte sonst noch irgendein Build-System-Problem sein.

@alfred: könntest du bitte folgende Befehle in dem Freetz-Root-Verzeichnis auf deinem Build-System ausführen und die dabei erezugten Logdateien hier anhängen?

make busybox-host-distclean; make busybox-host 2>&1 | tee busybox-host.log
rm -rf .fakeroot-cache build; make 2>&1 | tee make.log

Weiterhin, könntest du bitte (nachdem du die Befehle oben ausgeführt hast) die Datei tools/busybox hier ebenso anhängen?

 

[alfred.s]

Das Image lässt sich auch nicht flashen. Obwohl es kein M im Namen hat. Das meinte ich damit, dass das Ergebnis das selbe ist.
Natürlich habe ich bei dem hier manuell erzeugten Image die Datei aus dem Image-Verzeichnis genommen.

(Die Zeile, die bei freetz.sh das fertige Image auf das Windows-Verzeichnis kopiert, hatte ich selbst eingefügt, um mir bei den Tests die Arbeit zu erleichtern.)

Jetzt habe ich auch ein Werkzeug für den Hexdump gefunden. Er hängt dran (als Bild uns als Text).

Die beiden angefragten Logs hängen auch dran.

Zur Frage nach dem Abbruch: ja, ich habe den build einmal abgebrochen, weil zu wenig Platz auf dem virtuellen Laufwerk war. Erst mal alle Imageleichen gelöscht und dann nochmal neu gestartet.
Mittlerweile habe ich das Laufwerk auch deutlich vergrößert, um Platzmangel als Ursache auszuschließen. Ändert leider auch nichts. Beim Probelauf kommt ein identisches Image (ok es hat einen anderen Zeitstempel ...) heraus.


Im Augenblick läuft gerade ein Resize, da ich sowohl den zugewiesenen RAM-Bereich, als auch den Swap-Speicher noch probeweise vergrößere. Falls das was bringt, melde ich mich.


tools/busybox habe ich verpennt. Kommt nach dem nächsten Test


Edit noch ein Nachtrag ich hatte auch nochmal die Erstellung einer 6.05-Version versucht. Die klappt auch nicht mehr. Gleicher Fehler.

 

[alfred.s]

Vergrößerung von RAM und Swap hat nichts gebracht.
Mit der 13051 kommt jetzt die Fehlermeldung, dass das Packen nicht geklappt hat. Es wird auch kein Image mehr erzeugt.
Logs und busybox hängen dran.

 

[er13]

Ich habe meine tools/busybox gegen deine ausgetauscht. Mit deiner busybox lässt sich bei mir problemlos ein valides Image erstellen. Damit scheidet "miscompile von busybox" aus. Irgendetwas in deiner Build-Umgebung sorgt dafür, dass das Busybox-Binary, welches bei mir problemlos funktioniert, in deiner Build-Umgebung kein valides Tarball erstellt.

Was ist denn dieses coLinux? Was heißt dieses "cooperative without using virtualization software"? Wie wird da das Dateisystem emuliert? Wann hast du zuletzt das Dateisystem gecheckt? Aktualisiert sich dieses coLinux automatisch? Wann hast du dein coLinux zuletzt aktualisiert? Hast du nach Problemen mit coLinux bzgl. Dateisystem-Emulation gegoogelt? Mit Wahrscheinlichkeit 99,9% liegt es an deinem Build-System - irgendetwas hat sich bei diesem geändert, sodass es jetzt zu Problemen kommt. Die Tatsache, dass 6.05 auch nicht mehr funktioniert, ist ein weiterer Hinweis, dass es vermutlich an dem Build-System liegt. Wenn du jetzt eine Freetz-Revision testen würdest, die "damals" funktioniert hat, würde diese meiner Erwartung nach auch nicht mehr funktionieren. Das wäre der eindeutige Beweis dafür, dass es nicht an irgendeiner Freetz-Änderung liegt, sondern an einer Änderung deines Build-Systems.