[Erledigt] make stoppt mit Fehler 2

TorrSamaho2

Neuer User
Mitglied seit
27 Dez 2021
Beiträge
5
Punkte für Reaktionen
1
Punkte
3
Hallo.
Leider hab ich keine Ahnung von Linux. Ich wollte Eine Fritzbox 7330SL aufbohren und bin über Freetz-NG gestolpert. Und es klang ja auch zu schön.
Ich benutze Oracle VM VirtualBox mit Freetz-Linux-1.7.2-Ubuntu 21.10-(Impish Indri) 64-bit. Ich habe das aktuelle Fretz-NG runtergeladen und konnte es sogar starten. Als Einstellung habe ich Beginner gewählt und nur die vorgeschlagenen Programmteile ausgewählt. Leider wird mein make mit Fehler 2 abgebrochen.

/home/freetz/freetz-ng/source/toolchain-mips_gcc-4.8.5/gcc-4.8.5/gcc/sched-rgn.c :2042:5: note: here
2042 | case PRISKY_CANDIDATE:
| ^~~~
make[2]: Verzeichnis „/home/freetz/freetz-ng/source/toolchain-mips_gcc-4.8.5/gcc -4.8.5-build/gcc“ wird verlassen
make[1]: *** [Makefile:3893: all-gcc] Fehler 2

Ich habe die Prereqisits durchgeführt. Es hat keine Abhilfe geschaffen.
Leider kann ich mit der oben dargestellten Ausgabe nichts anfangen...
Habe ich irgendetwas vergessen zu laden? Was bedeutet der Fehler?

Ich danke Euch im Voraus.
 
Leider kann ich den Fehler nur bestätigen:
Code:
/home/freetz/pur/source/toolchain-mips_gcc-4.8.5/gcc-4.8.5/gcc/reload1.c:3059:5  note: here
 3059 |     case STRICT_LOW_PART:
      |     ^~~~
make[2]: *** [Makefile:1059: reload1.o] Fehler 1
make[2]: *** Auf noch nicht beendete Prozesse wird gewartet â¦
make[2]: Verzeichnis â/home/freetz/pur/source/toolchain-mips_gcc-4.8.5/gcc-4.8.5-build/gccâ wird verlassen
make[1]: *** [Makefile:3893: all-gcc] Fehler 2
make[1]: Verzeichnis â/home/freetz/pur/source/toolchain-mips_gcc-4.8.5/gcc-4.8.5-buildâ wird verlassen
make: *** [toolchain/make/kernel/gcc/gcc.mk:79: /home/freetz/pur/source/toolchain-mips_gcc-4.8.5/gcc-4.8.5-build/.compiled] Fehler 2
freetz@freetz:~/pur$
 
Ich nutze Ubuntu Studio 21.04.
der gleiche Fehler:
*** [Makefile:1059: reload1.o] Fehler 1
make[2]: *** Auf noch nicht beendete Prozesse wird gewartet …
make[2]: Verzeichnis „/home/harald/freetz-ng/source/toolchain-mips_gcc-4.8.5/gcc-4.8.5-build/gcc“ wird verlassen
make[1]: *** [Makefile:3893: all-gcc] Fehler 2
make[1]: Verzeichnis „/home/harald/freetz-ng/source/toolchain-mips_gcc-4.8.5/gcc-4.8.5-build“ wird verlassen
make: *** [toolchain/make/kernel/gcc/gcc.mk:79: /home/harald/freetz-ng/source/toolchain-mips_gcc-4.8.5/gcc-4.8.5-build/.compiled] Fehler 2
 
Ich erinnere mal (wieder) an die Möglichkeit/Notwendigkeit, bei solchen Problemen das KOMPLETTE Build-Protokoll zur Verfügung zu stellen (mittels fmake) - denn schon zwischen #1 und #2/#3 gibt es Diskrepanzen hinsichtlich der Stelle, wo das Problem auftritt (1x in sched-rgn.c, 1x in reload1.c) und der "Fehlercode" alleine ist noch lange keine Aussage, weil er lediglich zum Ausdruck bringt, wo der Fehler aufgetreten ist (eben beim Build für eine ältere GCC-Version).

Ich habe keine Ahnung, warum es für das hier wohl bei allen benutzte Ubuntu 21 keine vorübersetzte Toolchain gibt - das Problem tritt ja beim Erstellen des Cross-Compilers auf. Aber wenn es die nicht geben sollte (was ich wieder verstehen könnte, denn Ubuntu 21 anstelle von 20.04 LTS ist Unsinn, wie ich gleich versuchen werden zu erklären) bzw. wenn die Einstellungen das eigene Erstellen der Toolchain bewirken, muß eben erst einmal der passende GCC übersetzt werden, der auf der als Build-Host verwendeten Plattform das Erzeugen von Binärcode für die jeweilige FRITZ!OS-Plattform (das kann MIPS, ARM oder ATOM (x86+) sein) ermöglicht.

Mit 21.10 kam (iirc) bei Ubuntu der Umstieg auf GCC 11 - das wäre z.B. eine denkbare Stelle, wo durch das ständige (und m.E. vollkommen unnötige) Aktualisieren der Freetz-VM-Vorlage auch wieder ein Problem eingeschleppt worden sein könnte. Auch bei Verwendung von 21.04 kann es bei Updates zur Installation eines anderen GCC kommen - solange man auf einem System, mit dem man Freetz-Builds ausführen will, nicht auch noch mit anderen (Linux-)Programmen arbeiten will, braucht es am Ende aber nur Security-Fixes - wenn man kein ganz altes Build-System verwendet (vor 18.04 LTS).

Die LTS-Versionen (und die gibt es bei Ubuntu ja immer in Abständen von zwei Jahren: https://wiki.ubuntuusers.de/Long_Term_Support/) kriegen lange genug ihre Updates (und Ubuntu 21 ist nun mal keine Version, bei der es überhaupt ein LTS-Release gäbe), so daß man mit einer einmal funktionierenden VM (oder Side-by-Side-Installation für die Benutzung der Freetz-Toolchain) auf sehr, sehr lange Zeit "auf der sicheren Seite" ist und das Update für den Build-Host (wie gesagt, solange man nicht ständig mit dieser VM auch an anderer Stelle arbeitet - was dann aber sicherlich größere eigene "Expertise" bewirkt, bei der man sich auch selbst helfen kann bei Problemen wie oben) ist (a) vollkommen unnötig und (b) sogar "dumm", wenn man sich damit entsprechende Fehler neu einschleppt.

Es gibt nun mal bei Linux-Distributionen eine noch viel größere Bandbreite an möglichen Kombinationen, als bei Windows oder dem Apple-Zeug - das KANN dann einfach niemand mehr (alleine) testen, zumindest nicht in Kombination mit den (notwendigen) Regression-Tests ... denn wenn jetzt wieder Änderungen für GCC 11 notwendig sein sollten, wären sicherlich die Benutzer älterer/anderer Build-Systeme dann auch wieder verärgert, wenn diese Änderungen dazu führen, daß ihre Build-Systeme nicht mehr funktionieren. Für das Ergebnis in Form eines modifizierten Firmware-Images ist es aber vollkommen Banane, ob dafür nun der "neueste" GCC beim Erstellen der Cross-Development-Toolchain benutzt wurde oder nicht - es gibt also GAR KEINE Notwendigkeit, den Build-Host (abseits von Security-Fixes, die dann auch als solche ausgewiesen werden) irgendwie zu aktualisieren.

Mein Tipp also (neben dem ganz oben, daß man schon passende Protokolle vorzeigen muß, wenn man erwartet, daß sich jemand das Problem ansieht - dazu ist wahrlich genug schon geschrieben worden, seit dem "Anbeginn" von Freetz): Benutzt einfach eine der LTS-Versionen von Ubuntu für Eure Freetz-(NG-)Builds und hört auf mit dem Unsinn, dieses System (jenseits von Security-Fixes) ständig zu aktualisieren. Wenn so ein Update für das Build-System tatsächlich einmal notwendig sein/werden sollte, erfahrt Ihr das noch früh genug - diese Updateritis schadet jedenfalls deutlich mehr, als daß sie irgendeinen Nutzen bringen würde. Gerade die Freetz-VM mit ihrem ohnehin beschränkten Funktionsumfang ist ja nun kein System, was man auch für alle möglichen anderen Aufgaben heranziehen wollte - wer sich aus dieser VM erst ein "vollständiges" Linux-System bauen will, der wäre deutlich besser dran, wenn er "from scratch" beginnt und auch dafür/daher braucht es dann wieder keine Freetz-VM mit dem "aktuellsten" Ubuntu-Release.

Vielleicht sollten alle mit dem hier beschriebenen "Problem" also einfach mal einen Schritt zurück machen und sich ein entsprechendes Image mit 20.04 LTS (es ginge sogar 18.04 LTS) besorgen, in dem man dann den Freetz-Build erneut probieren kann. Erst wenn auch da dann Probleme auftreten, lohnt sich tatsächlich die Suche nach deren Ursache - irgendwelche Problemchen, die durch halbjährliche Updates einer Distribution eingeschleppt werden, sind so unnötig wie ein Kropf.

Ich habe noch nicht in GitHub nachgesehen, ob/was @cuma da (etwas) unternommen hat - aber es ist (aus den o.a. Gründen) auch nicht sinnvoll, alle sechs Monate erneut über derartige Probleme zu klagen, wenn man sie doch letztlich selbst zu verantworten hat. Zumal ich jetzt mal die These aufstelle, daß es nicht wirklich ausführliche Regression-Tests nach solchen Änderungen gibt und damit die (durchaus reale) Gefahr besteht, daß diejenigen, die tatsächlich (vernünftigerweise) mit LTS-Versionen arbeiten, dann von entsprechenden Korrekturen auch negativ betroffen sein können.

Das Ziel der meisten dürfte es ja eher sein, ein funktionierendes Image für ihre FRITZ!Boxen zu erzeugen und nicht, bei jedem neuen Build erst mal die VM komplett neu einzurichten, nur weil seit dem letzten AVM-Release auch eine neue Ubuntu-Version erschienen ist und die Freetz-VM bzw. die Freetz-Toolchain jetzt erst mal wieder neu erstellt werden müssen/sollen, weil Änderungen für neue Ubuntu-Versionen dazu führen, daß die aktuelle Freetz-(NG-)Version nicht mehr auf älteren LTS-Versionen funktioniert.
 
Hallo.
Tut mir leid. Es lässt sich nur die Variante mit Ubuntu 21.10 runterladen. Das Image mit 20.04 LTS finde ich nicht. Das Freetz-Linux soll nur dazu dienen, ein Freetz-Image für die Box zu kreieren.
./fmake wird mit "exit code 2" abgebrochen.
Ich halte mich nur an das Handbuch für newbies. Ich pfusche nicht im Linux rum.
 
Es lässt sich nur die Variante mit Ubuntu 21.10 runterladen
Ich vermute einfach mal, daß es hier um das Image der "Freetz-VM" geht. Wenn da tatsächlich keine älteren Versionen zum Download angeboten werden, sollte zumindest @gismotro (der die ja jeweils erstellt) in der Lage sein, Dir auch eine ältere Version zur Verfügung zu stellen - für die 20.04 LTS (mit dem Update auf 20.04.01) sollte das Version 1.5.8 gewesen sein: https://www.ip-phone-forum.de/threads/buildumgebung-freetz-linux.199449/post-2388834

./fmake wird mit "exit code 2" abgebrochen.
Alles andere wäre auch ziemlich überraschend, denn das ist ja nur ein Wrapper für den make-Aufruf, der VOLLSTÄNDIGE Protokolle speichert, die man hier dann als Textdatei anhängen kann. Warum sollte das also ein anderes Ergebnis bringen, als genau denselben Fehler beim make, wie das auch ohne diesen Wrapper der Fall ist? Dieses Skript soll nur verhindern, daß Leute ohne jegliche Ahnung selbst entscheiden, welche Ausgaben für die Diagnose eines Problems nun relevant sind (und in einen Beitrag hier zu kopieren wären) und welche nicht.
 
Ich habe die Prereqisits durchgeführt. Es hat keine Abhilfe geschaffen.
Da ich neulich über ein ähnliches Problem gestolpert bin, wie viel Speicher (virtuelle Festplatte) steht dem Linux in der VM zur Verfügung? Bei zu wenig (<10GB) hatte ich einen ähnlichen Fehler (und hatte mich nach der Ursache "totgesucht").

Aber BTW habe ich auch nicht verstanden, weshalb @gismotro bei freetz-linux nicht bei den LTS-Releases bleibt...
 
Aber BTW habe ich auch nicht verstanden, weshalb @gismotro bei freetz-linux nicht bei den LTS-Releases bleibt...
Weil ich ein Spiel-Kind bin und gerne mein System aktuell haben möchte.

Das Freetz-Linux-1.5.8-Ubuntu 20.04.01 LTS (Focal Fossa) 64-Bit.ova liegt wieder auf dem Server

Ergebnis :
Code:
STEP 3: PACK/SIGN
  checking for left over version-control-system files
  integrate freetz info file into image
packing var.tar
  checking signature key files
    creating private signature key file
    creating public signature key file
    adding public signature key file
creating filesystem image (SquashFS3-lzma)
  SquashFS block size: 64 kB (65536 bytes)
merging kernel image
  kernel image size: 14.9 MB, max 15.4 MB, free 0.5 MB (527616 bytes)
  Aproximately maximal time for the answering machine: 1 min, 39 sec (99 sec)
adding checksum to kernel.image
packing images/7330SL_06.55.ger_freetz-ng-18796-fd0213e08_20211230-202553.image
  packed image file size: 16.0 MB (16752640 bytes)
signing packed .image file
  signed image file size: 16.0 MB (16752640 bytes)
source firmware: 7330-SL_de 116.06.55 rev38630 {GER} (09.08.2019 14:09:13)
  source image file size: 16.0 MB (16732160 bytes)
done.

FINISHED
freetz@freetz-linux:~/73$
 
Zuletzt bearbeitet:
  • Like
Reaktionen: PeterPawn
Hallo gismotro,
ich hab es runter geladen und es funktioniert. :) Danke
Wie hätte die log-Datei vom fmake der Version mit Ubuntu 21.10 heißen müssen?
 
  • Like
Reaktionen: gismotro

Statistik des Forums

Themen
246,288
Beiträge
2,249,444
Mitglieder
373,878
Neuestes Mitglied
sellselldead00
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.