Erstellt vor 3 Jahren

Geschlossen vor 3 Jahren

Zuletzt geändert vor 20 Monaten

#1584 closed defect (fixed)

Box bootet nicht mehr (ohne replace kernel)

Erstellt von: make Verantwortlicher: cuma
Priorität: high Meilenstein: freetz-2.0
Komponente: avm Version: devel
Beobachter: kriegaex Product Id: 7390
Firmware Version: 84.05.07-20869

Beschreibung (zuletzt geändert von kriegaex)

Revision 7919 lief (und läuft) wunderbar, revision 7939 mit ansonsten ungeänderter .config bleibt "irgendwo" im Bootvorgang hängen. Mangels Konsole kann ich das leider nur sehr vage eingrenzen:

  • Kein WLAN (WLAN-Leuchte aber an)
  • Kein AVM-UI
  • Kein Freetz-UI
  • Keine External-Dienste

Einzige Abhilfe: Recovern, letztes Image flashen, Einstellungen wieder herstellen.

[kriegaex: Ich nehme an, die "WLAN-Leute" sind in Wirklichkeit eine Leuchte. ;-)]

Anhänge (1)

config.txt (152.1 KB) - hinzugefügt von make vor 3 Jahren.
.config des nicht startenden Images

Alle Anhänge herunterladen als: .zip

Änderungshistorie (24)

Geändert vor 3 Jahren durch make

.config des nicht startenden Images

comment:1 Geändert vor 3 Jahren durch kriegaex

  • Beschreibung geändert (Diff)

comment:2 Geändert vor 3 Jahren durch kriegaex

  • Beschreibung geändert (Diff)

comment:3 Geändert vor 3 Jahren durch dileks

Evtl. probieren r7893 zu reverten und Feedback wieder hier, vergleiche auch Ticket #1576 Kommtentar #1

comment:4 Geändert vor 3 Jahren durch er13

Es müsste etwas Box unabhängiges sein, meine 7170 zeigt genau das gleiche Verhalten.

comment:5 Geändert vor 3 Jahren durch cuma

Ich hab vorgestern sowas auch mit der 7320 gehabt. Box schient normal zu booten, aber war nachher mit ping nicht erreichbar. Hab es dann auf meinen Versuch geschoben die DL-Toolchain selbst zu bauen.
Im Zweifel ist immer der BusyBox bump schuld!

comment:6 Geändert vor 3 Jahren durch make

Genau - die Busybox, das war auch mein erster Gedanke.

Da die Box hier bis morgen abend gebraucht wird, kann ich mich leider erst ab Mittwoch daran machen, die Vorschläge abzuarbeiten und die Revision zu finden, ab der das Problem auftritt.

@dileks: Warum soll ich auf r7893 reverten, wenn r7919 lief und auch jetzt wieder läuft?

@kriegaex: In meiner Box sind tatsächlich keine Leute drin, hab zur Sicherheit nochmal nachgeschaut. Merci.

Zuletzt geändert vor 3 Jahren von make (vorher) (Diff)

comment:8 Geändert vor 3 Jahren durch mrspeccy

Habe dieselben Schwierigkeiten auf einer 7270v2 mit r7937, während r7913 läuft. Die Box ist mit dem r7937-Image weder über LAN noch über WLAN zu erreichen. Aber: Sie ist nicht wirklich hängengeblieben, sondern kann noch per Fernwartung übers Internet angesprochen werden. Das System-Log zeigt dann DNS-Fehler an, Telefonnummern sind nicht registriert, Datum bleibt bei 1970.

comment:9 Geändert vor 3 Jahren durch shooter3406

Habe dasselbe Problem: FB 7270 v2 - Freetz wurde ohne zusätzliche Pakete oder Patches gebaut.

Nach dem Bootloader passiert nichts mehr (es wird keine IP vergeben, und per manueller IP ist ebenfalls kein Ping möglich)

Wlan ist allerdings sichtbar, ich kann allerdings auch nicht per Wlan verbinden.

comment:10 Antwort: Geändert vor 3 Jahren durch dileks

Ich kann mir nicht vorstellen, dass busybox-1.19.3 das Problem sein soll. Hier wurden lediglich die 1.19.2-Fixes integriert. Natürlich kann es sein, dass das DL-Tarball karp0tt ist.

Mir ist aufgefallen, dass einige ChangeSets wie r7921 folgendes anzeigen:

Error: No such node
No node trunk/make/busybox/patches/busybox-1.19.2-buildsys.patch at revision 7921

Desweiteren hinkt das GIT-Repository 3 Commits hinterher (Aktuell: r7940 vs r7937).

Just FYI: Es wurde aufm Server auf subversion-1.7.x umgestellt.

Ich selbst habe keinen Admin-Zugriff, die freetz-devel ML habe ich angeschrieben bzgl. meiner Beobachtungen.

[1] https://github.com/olistudent/freetz/commits/master

Zuletzt geändert vor 3 Jahren von dileks (vorher) (Diff)

comment:11 Geändert vor 3 Jahren durch cuma

Schon interessant wie du immer wieder zu deinem Lieblings(-)thema GIT kommst

comment:12 als Antwort auf: ↑ 10 Geändert vor 3 Jahren durch kriegaex

Replying to dileks:

Mir ist aufgefallen, dass einige ChangeSets wie r7921 folgendes anzeigen:

Error: No such node
No node trunk/make/busybox/patches/busybox-1.19.2-buildsys.patch at revision 7921

Das habe ich gerade frisch behoben, siehe ML.

Desweiteren hinkt das GIT-Repository 3 Commits hinterher (Aktuell: r7940 vs r7937).

Danach habe ich noch nicht geschaut.

@cuma: Dein Tag-Nacht-Rhythmus ist wohl gerade meinem ähnlich, wie?

Version 0, vor 3 Jahren von kriegaex bearbeitet (Nächste(r/s))

comment:13 Geändert vor 3 Jahren durch cuma

  • Lösung auf fixed gesetzt
  • Status von new nach closed geändert
  • Verantwortlicher auf cuma gesetzt

In [7941]:

Upsi, fix typo in r7923 (closes #1584)

comment:14 Geändert vor 3 Jahren durch cuma

@kriegaex: Bei dem Wetterchen schlaf' ich manchmal unvorhergesehen zu früh ein.
Hat mich vorhin schon gewundert dass das Trac mitten in der Nacht überhaupt keine Revisionen mehr anzeigte…

comment:15 Geändert vor 3 Jahren durch kriegaex

  • Beobachter kriegaex hinzugefügt

comment:16 Geändert vor 3 Jahren durch kriegaex

@dileks: Tja, da paßt irgendwas nicht mit git-svn (das in Wirklichkeit ein Perl-Modul ist), weil da ein weiteres Perl-Modul nicht gefunden wird:

Can't locate SVN/Core.pm in @INC (@INC contains: /usr/share/perl/5.10.1 /etc/perl /usr/local/lib/perl/5.10.1 /usr/local$

Ich habe schon herumgespielt mit manuellen Paket-Updates, aber da ging mehr kaputt als ganz wurde. Irgendwann gab es mit neuerer svn-lib einen Segfault usw., da habe ich das wieder rückgängig gemacht. Ich kenne mich da zu schlecht aus und lasse das lieber jeman anderen beheben.

comment:17 Antwort: Geändert vor 3 Jahren durch dileks

@kriegaex: Danke für die Erledigung.

@cuma: Da lagst 2x falsch. Tatsächlich ein SVN-Repo Problem und r7923 hatte ich hier noch als einer der möglichen Culprit-Commits offen. Bin vorm Schlafengehen nicht mehr dazu gekommen, einen Revert zu testen. Statt permanent gegen mich zu sticheln, arbeite einfach sauber. Teste dein Zeugs bevor du es eincheckst. Wie ich im IRC schon scherzhaft sagte, wer gegen GIT wettert, bekommt prompt die Quittung :-).

comment:18 als Antwort auf: ↑ 17 Geändert vor 3 Jahren durch er13

Replying to dileks:

@cuma: arbeite einfach sauber. Teste dein Zeugs bevor du es eincheckst.

@cuma: Lieber cuma, kann mich dem nur anschließen. Leider ist es nicht das erste Mal, wo Du was eincheckst ohne es vorher getestet zu haben. Ein kurzes kritisches Drüberschauen über den eigenen Commit unmittelbar vor dem Einchecken hilft auch ungemein (wenn ich die Zahl richtig im Kopf habe, werden bis zu 60% der Fehler beim Review gefunden - kritisches Drüberschauen über den eigenen Code ist auch eine Art Review). Danke!

comment:19 Geändert vor 3 Jahren durch cuma

@dileks: "Sticheln" ist überflüssig, wenn man dir genügend Zeit gibt widersprichst du dir wie man sehen kann selbst. Über "Zeug testen" hatten wir uns schon unterhalten, und du bist der der für 1 Satz im Wiki zu beabeiten 5 Commits brauch, zu denen 25 Zeilen sinnfreie Kommentare gehören. Und das nur weil du es nicht raffst "Vorschau" zu drücken. Außerdem hab ich dich schon öfter auf deine Schrei(-)fehler ("Deppenbindestriche") hingewiesen, aber das juckt ja auch nicht. Hast also vorerst genug mit dir selbst zu tun
@er13: Schön dass man von dir auch mal wieder was hört. Und danke für die hilfreichen Tipp, ich weiss gar nicht wie ich ohne diese bislang überhaupt existerien konnte. Ich hab zu danken
Ganz davon abgesehen hatte ich den Patch einige Tage vorher jemand anderem geschickt der es auch übersehen hatte. WELTUNTRGANG!!!!!

comment:20 Geändert vor 3 Jahren durch kriegaex

So, meine Herren, das reicht wieder. Ich bin ja auch nicht konfliktscheu, wie jeder weiß, aber das geht zu weit. Bitte die allfälligen Beleidigungen auf persönliche E-Mails beschränken, wenn es sein muß, oder einfach unterlassen. Kritik wird hier nicht unterdrückt, aber sie sollte sachlich bleiben.

comment:21 Geändert vor 3 Jahren durch dileks

Über das Thema "Review-Prozess" von Patches oder Patchsets habe ich bereits kritisch im IRC und auch schon mit er13 gesprochen. Der trunk Branch ist nicht dazu gedacht durch vermeidbare Fehler instabil gemacht zu werden. Es hat hier verschiedene Menschen sinnlos Zeit gekostet. Bei Debian glauben auch einige Menschen durch Unachtsamkeiten den sid (aka unstable) Release bewusst oder unbewusst instabil zu machen, dabei gibt es für offentsichtliche Experimente "experimental". Bei cuma ist es mir zum wiederholten Male aufgefallen, auch anderen. Spricht man ihn direkt an, nimmt er keine Kritik an. Ich habe Xorg als Bsp. angeführt, hier durfte bisher Hinz & Kunz in master und in die verschiedenen stable GIT-Branches einchecken. Das führte irgendwann zu einem sehr instabilen Xserver. Besserung kam erst auf, nachdem man sich für einen Release-Manager (erstmalig mit v1.7) entschieden hat, nur dieser darf Commits einchecken. Genauso bleiben die Release-Manager auch nach dem Final-Release für Bug-Fixes erhalten. Bevor überhaupt eingechecked wird, gibt es einen Review-Prozess. In den Patches findet man sodann Reviewed-by, Tested-by, Acked-by etc. Dieser Work-Flow ist nich neu, es gibt ihn schon seitdem es GIT gibt in der Linux-Kernel Entwicklung. Zum Thema "Patches" könnte ich einen kleinen Vortrag auf der FreetzConf halten (sofern gewünscht).

comment:22 Geändert vor 3 Jahren durch kriegaex

OT, bitte auf der ML besprechen.

comment:23 Geändert vor 20 Monaten durch cuma

  • Meilenstein von freetz-1.3 nach freetz-2.0 geändert
Hinweis: Hilfe zur Verwendung von Tickets finden Sie in TracTickets.