tar: invalid tar magic

[alfred.s]

Wie kann ich ein älteres build-system installieren?
Das speedlinux war ein paar Jahre alt. Ich habe vor dem ersten Versuch alle Pakete aktualisieren lassen. Nach dem Fehler habe ich es komplett neu installiert. Auch das Image habe ich mal neu geladen.

 

[er13]

Sorry, da kann ich dir nicht helfen. Denn, wie gesagt, ich habe weder coLinux noch speedlinux jemals genutzt. Frag' die speed2fritz-Entwickler (von denen meiner Vermutung nach dieses speedlinux stammt), ob sie ähnliche Probleme haben und wenn ja, ob sie vielleicht schon die Lösung kennen. Wenn du von den speed2fritz Entwicklern was erfährst, wäre es nicht schlecht, wenn du dich anschließend in diesem Thread melden würdest und dein Wissen mit uns teilst, denn auch wenn ich mir zu 99,9% sicher bin, dass es an dem Build-System liegt, ist es immer noch eine Vermutung meinerseits.

 

[hermann72pb]

Es ist natürlich akademisch interessant dem Problem auf den Grund zu gehen, ich würde aber versuchen etwas weiter rauszuholen und folgende Fragen stellen/beantworten:
1. Brauchst du denn überhaupt noch diese speed2fritz-Lösung? Soweit ich informiert bin, unterstützt FREETZ mittlerweile durch Alien auch die SpeedPorts. Das wäre einer der Gründe sein, warum an speed2fritz wenig weiter passiert. Bring bitte das zunächst in Erfahrung, alfred.s. Ja, bei FREETZ muss man evtl. ein Paar Schritte mehr machen, als bei dem automatisierten speed2fritz. Was nützt dir es aber, wenn du ständig solche Probleme haben wirst? Du quellst dich, uns, deinen Rechner usw. In der Zeit, die du in diese Suche investiert hast, hättest du mit FREETZ von Null anfangen können und deutlich weiter sein, als jetzt.
2. Die ganzen CoLinuxe, cygwins und wie die alle auch immer heißen, taugen früher oder späeter nichts für Crosscompiling, was du hier bei FREETZ zwingend brauchst. Auf den Wiki-Seiten gibt es eine gute Anleitung zu freetz-linux, einer auf Ubuntu-basierten virtuellen Maschine. Im Netz gibt es Abbilder dieser VM, die du runterladen kannst. Mag sein, dass sie nicht auf dem neusten Stand sind, aber updaten/upgraden unter debian-artigen Linuxen geht sehr einfach. Zugegeben, du musst etwas Zeit investieren, dir diese Buildumgebung samt VM-Player, WinSCP, Putty, etc. zu installieren, danach hast du aber eine stabile Build-Umgebung, die du unkompliziert immer warten und pflegen kannst. Die VM liegt in einer Datei. Sprich, auch Umzug zu einem anderen Rechner ist kein Problem.

Wie gesagt, überlege dir es ganz gut, wie du weiter vorgehst.

MfG

 

[alfred.s]

Da hast Du allerdings völlig recht. Die Idee kam mir auch heute, nachdem ich gesehen habe, dass "alien-hardware" nicht speed2freetz ist, sondern bei Euch im Trunk, war das auch meine Idee.
Speedlinux ist schon deinstalliert und freetz-linux in der VirtualBox holt gerade die aktuellen Updates ...
Wäre mir der Unterschied zwischen freetz-linux und freetzlinux bekannt gewesen und hätte ich gewusst, dass die "alien-hardware" mittlerweile Standard bei freetz ist, wäre ich schon früher umgestiegen. Die VirtualBox läuft bei mir ab Installation schmerzfrei. VM-Ware habe ich zuerst versucht, das hat furchtbar wegen der Virtualisierung gezickt, da ich hier ein 32bit Windows habe (der 64-bit steht schon in den Startlöchern, braucht aber noch 100.000 installierte Programme).

Die paar manuellen Schritte sind kein Schmerz. Notfalls kann ich mir auch ein shellscript zimmern, wenn es nervt. Dafür reicht es gerade noch.

Heute wird es zeitlich nicht mehr für ein Build reichen, aber ich hupe nochmal, wenn es gelaufen ist.

Danke an alle Helfer und sorry für die kommunikativen Verwirrungen! Versucht bitte, die nicht-Unixer ein wenig zu verstehen. Für mich als Ex ist es schon schwer genug (alleine die Suche nach der .config wird beispielsweise zur Odyssee, wenn man nicht mehr gespeichert hat, dass "ls -l" ohne die Option -a die .xxx-Dateien nicht anzeigt), ich kann mir daher vorstellen, dass andere noch viel mehr Probleme dabei haben.

 

[hermann72pb]

Darum appeliere ich nochmal: Lies dir die Anleitungen auf freetz.org durch. Die sind wirklich gut geschrieben. Besonders Schritt-für-Schritt. Ich bin seit bald schon 10 Jahren hier und habe das Entstehen von diesen Anleitungen bei freetz.org miterlebt. Früher hat man sich die ganzen Sachen hier im Forum mühsam zusammengesucht. Das waren noch die Zeiten. Mittlerweile gibt es seit mehreren Jahren freetz.org mit den ganzen Infos dort. Vor allem die Schritt-für-Schritt-Anleitungen wurden sehr oft von den Benutzer geschrieben, die gerade mal mit FREETZ angefangen haben. Die sehen zwar für einen Linux-Profi vielleicht manchmal zu langweilig oder an einigen Stellen zu naiv, da werden aber genau solche Sachen mit dot-Dateien beschrieben. Hättest du der Anleitung gefolgt, müsstest du nicht selbst darauf kommen. Da steht es nämlich drin, weil ich es dorthin irgendwann mal eingetragen hatte. Übrigens, die ganzen Anleitungen kannst du auch gerne ergänzen oder editieren. Schreibrechte im Wiki haben alle, wenn ich mich nicht täusche.

Viel Spass! Vielleicht kehrst du noch zu Linux zurück...

MfG

 

[alfred.s]

Freetz-Linux unter VM-Box läuft einwandfrei. Da die Installation wirklich kein Aufwand ist, habe es mir am Arbeitsplatz auch schnell installiert und ein Image erstellen lassen. Es sieht optisch gut aus (kein Klartext) und ist etwa 3MB größer. Fehler kam auch keiner. Flashen teste ich dann zuhause, weil hier noch ein Speedport installiert ist.

An alle, die das gleiche Problem haben: speedlinux (ehemals freetzlinux) dürfte vermutlich der Verursacher sein.
Wäre schön, wenn die Betroffenen kurz Rückmeldung geben könnten, ob sie auch mit speedlinux erstellt haben, oder eine andere Linuxversion verwenden.

@vasila: did you use speedlinux to create the image? It's probably the cause for the malfunction. I changed to freetz-linux (NOT freetzlinux!) using Oracle Virtual Box and it seems to work fine.

 

[alfred.s]

Und noch zum Abschluss: das neue Image läuft problemlos. Es liegt also wirklich daran, dass speedlinux plötzlich nicht mehr als Buildsystem funktioniert.
Nicht jeder Fehler sitzt vor dem Bildschirm.

 

[PeterPawn]

Nicht jeder Fehler sitzt vor dem Bildschirm.

So sehr ich das ja verstehen kann, daß manche nicht zwischen Freetz und dem Build-Host unterscheiden können ... aber das "Nachtreten" ist doch unnötig und - in gewisser Hinsicht - hier im Freetz-Forum auch einfach fehl am Platz.

Das Freetz-Projekt bietet doch selbst gar kein eigenes Image an (sowohl freetz-linux als auch freetzlinux (aka speedlinux) liegen auf GitHub) und die Erwartungshaltung, daß hier jeder sofort etwas mit "SpeedLinux" anfangen kann, wenn man es am Rande erwähnt, finde ich schon etwas übertrieben.

Ich persönlich kannte z.B. zwar coLinux und den dort verfolgten Ansatz, daß es eine "spezielle Inkarnation" in Form einer angepaßten Build-Umgebung für Freetz überhaupt gibt (und die dann auch noch SpeedLinux heißt, was genauso gut der Name irgendeiner weiteren Linux-Distribution sein kann), war mir nicht bekannt - wenn Du Dein Problem in einem SpeedLinux-Forum/-Thread publiziert hättest, wäre das sicherlich klarer geworden.

Also nicht alles so persönlich nehmen und nicht hinter jeder Bemerkung einen Angriff vermuten ... versetze Dich doch mal mit den neuen Erkenntnissen, die Du im Laufe der Lösung Deines Problems bzgl. der Build-Umgebung gewonnen hast, in die Lage der hier Antwortenden und überprüfe (notfalls mit der Forensuche des IPPF) Deine Erwarungshaltung bzgl. der hier vorhandenen Kenntnisse zu "speedlinux". Du wirst schon an der Häufigkeit der Erwähnung dieser Umgebung feststellen, daß das doch eher exotisch ist/war. In diesem Licht muß man dann auch noch einmal die Antworten lesen und dann kann man diese sicherlich besser bewerten.

Auch die "Anforderung" eines Hexdumps einer Datei ist nun - bei halbwegs vorhandenen Computerkenntnissen - ja nicht so exotisch und wenn dann die Antwort erst mal aus "funktioniert nicht" besteht, dann denkt man sich als Hilfewilliger eben auch seinen Teil dazu.

 

[hermann72pb]

@alfred.s: Ich schließe mich dem Kommentar von PeterPawn vollkommend an. Er hat es schon ziemlich vorsichtig formuliert und auf den Punkt gebracht, worum es uns allen hier ging, als wir dich zugegebenermaßen angezettelt hatten. Du hast allerdings im Verlaufe der Suche schon sehr viel Mut und die Bereitschaft zur Problemlösung gezeigt, sodass ich dir zukünftig wünsche, dass du weniger solche Probleme mit FREETZ bekommst und irgendwann mal vielleicht doch dein eigenes Paket für FREETZ entwickelst.

MfG

 

[xrated]

Ich habe mit freetz 1.3.1 und 1.3.2 ebenso die Meldung invalid tar header bei der aktuellen trunk version.

Ich kann das Image normal entpacken mit tar xf und mit anschließend
../tools/find-squashfs var/tmp/kernel.image
Size is 1961224
Strange, no squashfs signature found...

Während make hatte ich eine Fehlermeldung von squashfs, danach gab ich ein:
make e2fsprogs-host-distclean
make e2fsprogs-host
Als das abermals nicht funktionierte machte ich:
make distclean
und der make ging durch.

Anbei .config
Anhang anzeigen .config.zip

fmake.log
Anhang anzeigen fmake.zip

libreadline6-dev ist auch installiert

 

[PeterPawn]

Ich habe mit freetz 1.3.1 und 1.3.2 ebenso die Meldung invalid tar header bei der aktuellen trunk version.

Ich rate mal und sage, daß Du mit "freetz 1.3.1" das VM-Image für FreetzLinux mit Ubuntu 12.04 meinst? Von hier: http://sourceforge.net/projects/freetz-linux/ ?

Das "speedLinux", um das es hier ursprünglich ging, findet sich unter der URL ohne den Bindestrich zwischen "freetz" und "linux", das war so ziemlich das Unsinnigste, was passieren konnte.

In diesem Falle empfehle ich erstens die Verwendung von "freetz-linux-1.3.2.ova" und zweitens als erstes ein "sudo aptitude dist-upgrade", um auf Ubuntu 14.04 zu kommen: https://wiki.ubuntuusers.de/Long_Term_Support

Ich kann das Image normal entpacken mit tar xf und mit anschließend
../tools/find-squashfs var/tmp/kernel.image
Size is 1961224
Strange, no squashfs signature found...

Da bei einer 7362SL der Kernel und das Dateisystem in unterschiedlichen Dateien liegen, ist das nicht weiter verwunderlich. Das SquashFS-Image hört auf den (etwas absonderlichen) Namen "filesystem.image" und sollte - anders als bei NOR-Boxen, woher Du das vielleicht noch kennst - als gesonderte Datei mit einer von Null verschiedenen Größe vorliegen.

Wenn nach dem bereits ausgeführten "make distclean" beim anschließenden "make" kein Fehler auftrat, wieso ist das dann eigentlich "ebenso die Meldung"? Ich blicke es im Moment nicht, wo diese Fehlermeldung bei Dir überhaupt aufgetaucht ist.

Im fmake-Log sehe ich nichts davon ... also "raten": Das "invalid tar magic" beim Auspacken tritt dann (auch bei Dir) unter einer bereits auf der Box laufenden Freetz-Version beim Versuch des Aktualisierens auf? Wenn ja, bitte das Protokoll davon und ebenfalls einen Hexdump der ersten 512 Byte des Images (inkl. ASCII-Darstellung dahinter, nicht wieder "hex pur") posten - idealerweise noch die Ausgabe von

tar tvf [I]imagefile[/I]

auf der FRITZ!Box für dieses Image (einfach irgendwo auf dem USB-Stick ablegen und das Kommando per Telnet, Rudi-Shell, SiaB ... oder was auch immer Du hast (ssh?) - ausführen).

Es kommen ja nur zwei Fehler in Frage, entweder stimmt das Image nicht (dafür der Hexdump) oder das falsche "tar"-Kommando wird verwendet (dafür der Test auf der Box). Welcher Fehler das nun sein mag? Selbst beim Raten hat man nur eine 50:50-Chance ... dieses Verhältnis läßt sich mit einigen zusätzlichen Tests deutlich verbessern.

 

[xrated]

Es handelt sich um freetz-linux-1.3.2.ova mit apt-get update und upgrade.

Die Fehlermeldung beim bauen trat auf bevor ich make distclean eingegeben habe und die anderen 2 Commands brachten keine Änderung.

tar tvf 7362_06.30-freetz-devel-13439.de_201
51027-012215.image
drwxr-xr-x 0/0         0 2015-10-27 01:21:47 ./
drwxr-x--- 0/0         0 2015-10-27 01:22:33 ./var/
-rw-r--r-- 0/0       341 2015-10-27 01:22:33 ./var/.packages
tar: invalid tar header checksum

Der Output oben ist der selbe wie im Log beim FW Update.

Hex:


Ich glaube das Problem ist das die Datei von freetz-linux über ftp auf einem Windows PC fehlerhaft übertragen wird. Mit 7z bekomme ich ebenso einen Fehler beim Win PC.

Edit: Wie vermutet, nachdem ich das File über scp runtergeladen habe ging das Update. Der ftp server in freetz-linux funktioniert irgendwie nicht so wie er soll.

 

[PeterPawn]

Das mit dem Hexdump ist zwar in diesem Falle länger als 512 Byte, reicht aber immer noch nicht aus, um den Header nach der .packages zu sehen ... und der ist ja "der Böse". Wobei auch das nicht so ganz klar ist, denn das "checksum" ist wohl tatsächlich eher ein Hinweis, daß da eine Checksumme nicht stimmt und kein Dateiname, diese heißt m.W. immer noch "chksum". Also ist entweder die Prüfsumme für die .packages falsch (dann bezieht sich der Fehler auf die .packages und die Nachricht ist blöd formuliert) oder der nachfolgende Header enthält eine ungültige Prüfsumme (wofür eigentlich?) oder es gibt einen neuen Header "checksum", den die Version des tar-Kommandos auf der Box nicht versteht (kriegt man in den Quellen raus, aber erst weiter eingrenzen, das "Quellenstudium" ist aufwändiger als weitere Tests).

Hast Du eine Idee, wie Du die ersten 4 KB (das sollte reichen) der Image-Datei mit "dd" in eine andere Datei kopieren kannst? Die dann mit ZIP gepackt und man müßte sie hier anhängen können, auch ohne gegen die Bestimmung "keine Firmware" zu verstoßen, denn da dürfte noch nichts Sinnvolles mit zu machen sein und der eindeutige Wille zur Fehlersuche sollte hier sichtbar sein.

Wenn ich das richtig verstehe, kannst Du das Image unter dem Ubuntu-Linux (mit heute aktuellem Stand) entpacken?

Kannst Du das noch einmal mit dem (dann ja heute auch frisch erstellten) "tar" der Busybox - unter tools/busybox liegt die - testen? Am besten das o.a. tar-Kommando noch einmal mit dem "nominellen" "tar"-Kommando des Ubuntu ebenfalls ausführen. Die Frage wäre, welches "tar"-Kommando hat da ein falsches Format erzeugt? Normalerweise würde Freetz beim Erstellen der Firmware das "tar" aus der Busybox nehmen, das sollte dann aber das Image auch lesen können. Wenn das damit auch nicht umgehen kann, wäre die nächste Frage, wie oft Du heute schon ein Image gebaut hast bzw. ob das Problem beim Packen reproduzierbar ist. Notfalls würde ich noch einmal das Verzeichnis "build" vor einem erneuten "make" (das dauert auch nicht sehr lange, Übersetzungen sind ja nicht notwendig) rekursiv löschen, beim "fmake" aus dem letzten Log war das originale Image ja bereits ausgepackt.

Wenn ich die Reihenfolge der Fehler richtig verstanden habe, hast Du heute neu ausgecheckt und dann ein "make" gestartet, was bei den e2fsprogs (und vermutlich bei den SquashFS-Tools für den Host) dann hängenblieb. An die Stelle des einzelnen "distclean" für die notwendigen SquashFS-Pakete trat dann bei Dir ein generelles "distclean" mit anschließendem "make", was dann entsprechend alles neu bauen mußte, theoretisch auch die Busybox in den Host-Tools. Auf der Box muß aber ein tar aus einer älteren/anderen Busybox (halt der vom letzten Freetz-Build bei Dir) das wieder lesen können. Da scheint es irgendwelche Diskrepanzen zu geben ... da das auch an irgendwelchen Änderungen am "fakeroot" liegen kann, ist ein Löschen von "build" erst einmal ein sinnvoller Test, da dann auch diese Fehlerquelle ausgeschlossen ist. Ich weiß gerade nicht (schaue auch nicht nach), ob bei einem "distclean" auch der "build"-Ordner mit gelöscht wird ... es spräche einiges dafür es zu tun, einiges dagegen.

 

[xrated]

Da haben sich unsere Postings wohl überschnitten, Problem hat sich gelöst. Der ftp server von freetz-linux hat das File verstümmelt oder bei meinem PC stimmt irgendwas nicht (VM läuft lokal unter Vmware Workstation).

 

[PeterPawn]

Ja, parallel lief das Pokalspiel, da war ich etwas abgelenkt und habe länger gebraucht zum Schreiben.

Beim nächsten Mal kannst Du ja den Übertragungs-"Modus" des FTP-Clients prüfen ... bei "mode binary" sollte es klappen, bei "mode ascii" eher nicht. Der MS-CLI-Client für FTP startet mit "ascii" und muß erst umgeschaltet werden (falls Du den benutzt haben solltest) - auch die Benutzung von Samba anstelle von SCP wäre eine Alternative (beim originalen Freetz-VM-Image).