[Erledigt] Freetz Build Fehler FW 06.30 für FB 7490

[Akki01]

Hi

ich wollte für meine FB 7490 nochmal ein FreetzImage bauen mit der Firmware 06.30 für
mein Archiv.

Leider bricht er beim bauen ab, mit folgender Fehlermeldung ab.

Spoiler

--2018-06-17 19:54:42-- http://freetz.3dfxatwork.de/mips_gc...el-2.6.32-freetz-r13747-shared-glibc.tar.lzma
Auflösen des Hostnamen »freetz.3dfxatwork.de (freetz.3dfxatwork.de)«... 31.172.113.113
Verbindungsaufbau zu freetz.3dfxatwork.de (freetz.3dfxatwork.de)|31.172.113.113|:80... verbunden.
HTTP-Anforderung gesendet, warte auf Antwort... 404 Not Found
2018-06-17 19:54:42 FEHLER 404: Not Found.
Download failed - "http://freetz.3dfxatwork.de/mips_gc...el-2.6.32-freetz-r13747-shared-glibc.tar.lzma" -> error code 8
--2018-06-17 19:54:42-- http://freetz.magenbrot.net/mips_gc...el-2.6.32-freetz-r13747-shared-glibc.tar.lzma
Auflösen des Hostnamen »freetz.magenbrot.net (freetz.magenbrot.net)«... 31.172.113.113
Verbindungsaufbau zu freetz.magenbrot.net (freetz.magenbrot.net)|31.172.113.113|:80... verbunden.
HTTP-Anforderung gesendet, warte auf Antwort... 404 Not Found
2018-06-17 19:54:42 FEHLER 404: Not Found.
Download failed - "http://freetz.magenbrot.net/mips_gc...el-2.6.32-freetz-r13747-shared-glibc.tar.lzma" -> error code 8
--2018-06-17 19:54:42-- http://freetz.wirsind.info/mips_gcc...el-2.6.32-freetz-r13747-shared-glibc.tar.lzma
Auflösen des Hostnamen »freetz.wirsind.info (freetz.wirsind.info)«... 188.165.115.52
Verbindungsaufbau zu freetz.wirsind.info (freetz.wirsind.info)|188.165.115.52|:80... verbunden.
HTTP-Anforderung gesendet, warte auf Antwort... 404 Not Found
2018-06-17 19:54:42 FEHLER 404: Not Found.
Download failed - "http://freetz.wirsind.info/mips_gcc...el-2.6.32-freetz-r13747-shared-glibc.tar.lzma" -> error code 8
make: *** [dl/mips_gcc-4.8.5_uClibc-0.9.33.2-nptl_kernel-2.6.32-freetz-r13747-shared-glibc.tar.lzma] Fehler 1
freetz@freetz-linux:~/7490$

Die Datei "mips_gcc-4.8.5_uClibc-0.9.33.2-nptl_kernel-2.6.32-freetz-r13747-shared-glibc.tar.lzma" befindet sich
leider nicht mehr auf den Freetzserver.

Hat eventuell jemand diese Datei noch auf seinen PC oder oder woanders liegen und könnte mir diese zukommen lassen.

Würde mich darüber sehr freuen.

Grüße Akki

 

[PeterPawn]

Dann muß man eben die Toolchain selbst erzeugen ... der Fehler beschreibt den (vergeblichen) Versuch, die Toolchain für ein (relativ aktuelles) Changeset von Freetz und einen uralten Linux-Kernel zu laden.

Seit der Version 06.5x verwendet FRITZ!OS aber den Kernel 3.10.73 - solange sich jetzt nicht noch jemand findet, der die alte Toolchain erzeugt und zum Download bereitstellt (vermutlich wird mich @er13 gleich wieder Lügen strafen und die Download-Version umgehend erzeugen - auch das bringt Dich dann weiter), kann man sich aber ganz leicht auch selbst damit behelfen, daß man die Toolchain im Rahmen des Build-Prozesses selbst erzeugen läßt - wenn die Option dazu nicht sichtbar ist, muß man ggf. am Expertise-Level in der Konfiguration etwas drehen.

 

[er13]

Als erstes der Hinweis, es bedarf keines Downgrades auf 6.30, wenn Du Freetz auf einer Box installieren möchtest, auf der eine Fritz!OS-Version >= 6.5x installiert ist.

Ansonsten hat es die Datei mit dem Namen nie gegeben. Der Fehler befand sich an einer anderen Stelle und wurde in r14736 gefixt.

 

[Akki01]

Vielen Dank Euch beiden für eure Antworten, @PeterPawn soweit stecke ich in der Materie nicht drin, das ich mir selber ein aus einen altes Toolchain mir selber was erstellen kann, drum habe ich ja um Hilfe gebeten.

Ich bin ganz normal nach der Anleitung vorgegangen, und hab gesehn die "mips_gcc-4.8.5_uClibc-0.9.33.2-nptl_kernel-2.6.32-freetz-r13747-shared-glibc.tar.lzma" wird nicht gefunden wird,
also gehe ich doch davon aus, das die Datei nicht auf dem Server zu finden ist.

Wenn du sagst @er13, die Datei hat es nie gegeben, dann frage ich mich warum er dann die Datei sucht?

Da ich nicht das Hintergrundwissen haben wie Ihr beiden, heißt dies jetzt das man kein 06.30 FW Freetz Image
mehr bauen kann?

Ok werde mir das ansehen, was gefixt wurde.

Dann sage ich mal Danke @er13 fürs Fixing, werde gleichmal ein Build starten.

Alles super geklappt, Danke nochmals!!!!!!!!

 

[PeterPawn]

@er13:
OK, hier "rächt" es sich jetzt, daß das Bilden von TARGET_TOOLCHAIN_COMPILER in toolchain/make/Makefile.in nicht einheitlich erfolgt (wer außer Dir soll das am Ende noch finden?) und beim Hinzufügen neuer Kernel-Versionen vor 2,5 Jahren das "Schema" nur für Kernel > 3.10 geändert wurde.

Bei neuen Boxen mit 2.6er-Kernel (z.B. die Puma-Boxen) sucht man genauso wie bei der 7390 ... die "alten" Toolchains auf den Download-Servern könnte man ja umbenennen und den "kernel"-Zusatz einheitlich über alle Toolchain-Versionen verwenden.

Gesetzt den Fall, ich stelle den entsprechenden Patch bereit (der aber auch ziemlich witzig wäre, denn die zu ändernden Stellen sind ja sehr überschaubar) ... wäre nicht der Umstieg auf eine einheitliche Benennung (zumindest für andere) übersichtlicher?

Die "Idee", daß bei fehlendem "kernel"-Bestandteil im Toolchain-Namen die Kernel-Version des Target-Systems < 3.10 ist, muß man ansonsten eben "kennen" oder man sucht sich einen Wolf. Das hatte ich vor kurzem erst irgendwo, als ich eine Download-Toolchain für den RasPi als Build-Host bereitstellen wollte und bei der 7390 der dazu notwendige Dateiname dann ein anderer war (nicht nur von den Werten, sondern vom Aufbau) als bei der 7490, die ich parallel dazu bereitgestellt hatte. Das hatte ich erst vor wenigen Tagen also schon mal auf dem Schirm, aber auch umgehend wieder vergessen, wie Du sicherlich auch gemerkt hast. Warum sollte man es unnötig schwer machen, durch die "Interna" von Freetz durchzublicken?

@Akki01:
Hier war das Problem beim Bilden des Namens der Download-Toolchain tatsächlich noch ein anderes ... aber mit einer eigenen Toolchain hättest Du das eben auch umschiffen können (so, wie es jeder spätere Leser ebenso kann, wenn mal wieder ein Download nicht funktioniert, weil entweder die Datei gar nicht existiert oder alle Mirror "down" sind) - dabei interessiert der "Dateiname" der Toolchain dann nicht wirklich.

Das ist am Ende nämlich auch ganz simpel eine Einstellung in der Menü-Konfiguration von Freetz ... da braucht man gar nicht "tief in der Materie zu stecken" - man muß nur die richtige Stelle finden (den Hinweis auf die, für die Anzeige der "Toolchain options" notwendige, Einstellung beim "Level of user competence" hatte ich auch noch gegeben) und an der passenden Stelle sein "Kreuz" machen.

Das ist sogar deutlich leichter als eine echte Wahlentscheidung, weil keine Notwendigkeit besteht, sich noch mit "Programmatik" auseinanderzusetzen.

Wenn es tatsächlich komplizierter wäre, könnte man vielleicht eine "ausführliche Anleitung" erwarten ... wobei Du eben auch nicht der Erste bist, der ein Problem im Zusammenhang mit einer Download-Toolchain hat und da - nach dem Hinweis - dann auch die (erneute) Suche nach den Lösungen, die bei anderen zum Erfolg führten, durchaus eine Option gewesen sein sollte.

 

[er13]

Dass die 2.6.32er-Toolchain kein Suffix mit der Kernel-Version hat, ist ... historisch entstanden. U.a. deswegen, weil dieselbe Download-Toolchain sowohl für 2.6.28 als auch für 2.6.32 verwendet wird, was streng genommen Blödsinn ist - 2.6.28 und 2.6.32 unterscheiden sich was die Anzahl der unterstützten syscalls angeht deutlich mehr als z.B. 2.6.13 und 2.6.19 (ich habe es mal analysiert und irgendeinem Ticket sogar zusammengefasst).

Patch: vorerst kein Patch, ich wollte mir sowieso Gedanken machen und das Naming-Schema für die Download-Toolchain ändern. Erst neulich kam ja noch 24kc vs. 34kc hinzu, das gehört auch mitaufgenommen. Stand jetzt würde ich sagen, der Name soll sich aus folgenden Bestandteilen zusammensetzen (Variablenamen nur "in etwa"):

$(ARCH)-$(KERNEL_VERSION)-$(UCLIBC_VERSION)-$(UCLIBC_VERSION_NPTL_SUFFIX)-$(GCC_VERSION)-$(CPU_ARCH/TUNE)

Habe ich was übersehen?

Edit: hier ist das Ticket, und hier die Vergleiche: 2.6.13-vs-2.6.19, 2.6.28-vs-2.6.32
Edit2: meine Aussage in Bezug auf die Anzahl Unterschiede stimmt allerdings nicht

 

[Akki01]

@PeterPawn

Ich habe mir das ebend nochmal angeschaut, gefunden hab ich die "Toolchains (Download and use precompiled toolchains)" allerdings habe ich bis gestern von der Funktion nie gehört bzw. benutzt.

Da ich kein englisch verstehe und spreche, vermute ich einfach mal laut Freetz Wiki, das man
falls ein Download nicht funktioniert, die Möglichkeit hat eine andere Version dort anzugeben, hab ebend
mal reingeschaut, da ist nur eine Version Verfügbar.

Vielleicht kannst Du mir sagen ob ich richtig liege oder nicht mit meiner Vermutung.

 

[PeterPawn]

Wenn Du da den Punkt "Build own toolchains (requires 4GB diskspace)" auswählst, dauert so ein Build zwar etwas länger (die Möglichkeit der Download-Toolchains soll diesen Vorgang ja abkürzen), Du bist dann aber nicht vom Vorhandensein oder Fehlen irgendwelcher Dateien auf einem Mirror abhängig (auch die können tatsächlich mal alle nicht erreichbar sein, wenn das Internet mal wieder in verschiedene autonome Netze zerfällt, weil zentrale Router defekt sind oder angegriffen werden) und kannst zusätzlich (dafür braucht man das sicherlich am ehesten, auch wenn das dann eher "advanced usage" ist) auch noch eigene Optionen für die in der Toolchain ansonsten angebotenen Komponenten verwenden, wenn man weiß, was man da macht.

BTW: "Google Translate" macht auch für des Englischen Unkundige aus den Angaben in der "menuconfig" dann folgendes:

The menu item text:

(X) Download and use precompiled toolchains
( ) Build own toolchains (requires 4GB diskspace)

will be translated to:

(X) Downloade und verwende vorkompilierte Toolchains
() Erstellen Sie eigene Toolchains (benötigt 4 GB Speicherplatz)

Man muß sich halt da die Hilfe suchen, wo sie angeboten wird.

Der Punkt, eine eigene, bereits vorkompilierte Toolchain im Download aus einer anderen Quelle zu verwenden, ist dann tatsächlich noch einmal etwas komplizierter ... u.a. weil man dazu die MD5-Prüfsummen bereits vorher ermitteln muß, wozu man die Toolchain in aller Regel auch erst einmal laden muß.

@er13:
Abgesehen davon, ist eben eine MD5-Prüfsumme auch nicht mehr so ganz zeitgemäß ... zumindest dann, wenn man so viel Zeit für das Finden einer Kollision hat, wie es beim Download irgendwelcher statischer Dateien der Fall ist. Das ist ja kein Vergleich mit einer "on-the-fly"-Nutzung von MD5, wo die Benutzung dieses veralteten Algorithmus gerade noch so durchgehen könnte ... AVM nutzt es ja wohl auch noch immer, wobei ich noch nicht weiß, ob/was da beim Signieren in der Labor-Reihe noch geändert wurde - es gibt ja Berichte, daß mit neueren Labor-Versionen die (AVM-)Signaturprüfung beim Update keine selbstsignierten Dateien mehr mag.

Wenn Du an dieser Stelle also etwas ändern willst, würde ich zusätzlich noch Überlegungen dahingehend einbeziehen, daß man bei Freetz eine Liste von vertrauenswürdigen PGP-Keys definieren kann (das macht jede Paketverwaltung genauso) und dann an die Stelle von (einfachen) Hash-Tests zur Identitätssicherung einer Datei auch das Signieren (da ist der Hash ja auch schon drin) mit einem passenden Key treten kann (auch als "detached signature", wenn eine Datei desselben Namens mit der zusätzlichen Erweiterung ".sig" existiert).

Wenn ich das richtig gelesen habe in der BusyBox-ML, sollen ja künftig auch deren Quellen signiert erhältlich sein (für die leichtere Handhabung durch Maintainer anderer Distros) ... es erleichtert einiges, wenn man bei einem "version bump" (oder beim eigenen Update für irgendein Projekt) nicht den Hash-Wert direkt im Makefile angeben muß (wobei da die meisten Projekte ja auch inzwischen bei SHA-Hashes, am besten auch jenseits von SHA-1, angekommen sind, wenn es um das "Veröffentlichen" von Hash-Werten geht und an dieser Stelle ja Freetz auch SHA-2 und SHA-3 "versteht").

Aber beim Signieren gibt eben der "Unterschreibende" auch gleich noch den zu verwendenden Hash-Algorithmus vor bzw. man braucht sich bei der Prüfung auch nicht mehr darum kümmern, ob das nun SHA-1, -2 oder -3 ist. Das klappt sicherlich nicht gleich für alle Pakete ... aber wenn man ändert, kann man vielleicht ja auch sukzessive auf einen moderneren Weg umstellen.