[Problem] USB-Root boot loop auf 7360v1

bugmenever

Neuer User
Mitglied seit
3 Jun 2014
Beiträge
11
Punkte für Reaktionen
0
Punkte
1
Hallo,

ich habe mich jetzt etwas eingearbeitet und soweis ich das sehe, ist USB-Root eine gute Möglichkeit, das Speicherlimit des Flashspeichers zu umgehen. Ich bin der Anleitung gefolgt, aber habe es nicht hinbekommen. Ich habe auch schon im Forum gesucht, aber nichts war Hilfreich. Habe also TTY rangelötet und mir die Ausgabe wärend des Bootens angeschaut. Dabei ist die letze Zeile bevor es neu startet (sowohl mit, als auch ohne USB):

Code:
/etc/init.d/rc.usbroot: .: line 21: can't open '/var/env.mod.daemon'

Soweit ich das sehe, gibt es diese Datei nicht im Flash Image. Somit durchaus verändlich, dass eine nicht vorhandene Datei nicht geöffnet werden kann.

Wie kann ich das Problem lösen?
 
Nicht falsch verstehen, aber ich verlinke mal auf die "Notiz", die dem usb_root-Package zur Seite gestellt ist: https://github.com/Freetz-NG/freetz...34f6e1f299612e72e8/make/usbroot/Config.in#L28

Das sicherste Zeichen dafür, daß da seit Urzeiten nichts mehr gemacht wurde, ist die Liste der Kernel-Versionen im rc-File für dieses Paket: https://github.com/Freetz-NG/freetz-ng/blob/master/make/usbroot/files/root/etc/init.d/rc.usbroot ... und wenn Du tatsächlich an dem herumprobierst, was Du (iirc) anderenorts angekündigt hast (nämlich die Firmware der v2 auf die v1 bringen zu wollen), dann handelt es sich bei der verwendeten Firmware ja vermutlich um eine 06.8x, die dann auch irgendeinen 3.10er-Kernel verwenden wird.

Wobei ich damit nicht sagen will, daß es - nachdem man entsprechende Zweige für die neueren Kernel-Versionen hinzugefügt hat - mit nur wenigen Änderungen wieder lauffähig gemacht werden könnte. Die Unterschiede KÖNNEN deutlich größer sein - es wird Gründe geben, warum sich in den letzten acht Jahren (wenn ich nach den Daten der richtigen Files in dem Paket schaue) dort nichts mehr getan hat.

PS: Um das Herumrätseln im zweiten Absatz hinsichtlich der Versionen zu vermeiden, ist es auch hilfreich, diese Angaben "zu erwähnen" und/oder die Konfiguration für Freetz-NG (am besten einmal als "vollständige Datei" und einmal in der Form, wo nur die geänderten Einstellungen ersichtlich sind -> zu erstellen mit make config-compressed) als Anhang bereitzustellen.
 
Ja tut mir leid, das ich vergessen habe die .config mit hochzuladen. Ich wollte USB-Root erstmal mit dem 2.6.32.61 Kernel ausprobieren, für welcher USB-Root noch gehen sollte. Die config habe ich jetzt angehängt.

Meine Erkenntnisse so weit:

Der Zugriff selbst, passiert in modlibrc. Es gibt ein https://www.gitmemory.com/issue/Freetz-NG/freetz-ng/325/863657683 issue, welches sich so anhört, als könnte es genau der Fehler sein, den ich habe. Ich bin zwar gewohnt mit Linux zu arbeiten, aber init.d ist doch etwas ungewohnt für mich. Es klingt danach, als würde USB-Root vor rc.mod ausgeführt, welches erst die Dateien anlegt, welche für USB-Root benötigt werden.

Mal noch eine Idee. Wäre es nicht möglich uboot in das NOR zu flashen und dann von uboot den kernel von usb zu laden? Also dass man folgen Ablauf hat: ADAM2 -> ubtoot -> freetz von usb.
Aber wahrscheinlich, ist usb da das Problem.
 

Anhänge

  • config.txt
    84 KB · Aufrufe: 1
Zuletzt bearbeitet:
Wenn man sich das bei GitHub direkt ansieht (Warum nimmt man eigentlich gitmemory.com? Das hier ist wieder mal ein schönes Beispiel für "incomplete data".): https://github.com/Freetz-NG/freetz-ng/issues/325, dann ist das - nach meinem Verständnis - gefixt.

Wobei es sein kann, daß beim Einsatz von usb_root die Ladereihenfolge so durcheinander gewürfelt wird, daß modload zu spät erst aufgerufen wird - schließlich soll bei dieser Art des Starts das init-Kommando durch das Shell-Skript rc.usbroot ersetzt werden.

Und das wäre die erste Stelle, wo man nachsehen sollte ... wie genau sehen denn (in der Boot-Console) die Kernel-Parameter aus? Irgendwo darin muß (a) das init durch das Shell-Skript ersetzt werden und (b) - wenn ich mich richtig erinnere, das ist schon wieder Jahre her - auch eine Angabe zu finden sein, welches Storage-Device als rootfs gemountet werden soll (bzw. gemountet werden und danach mit pivot_root gegen das aktuelle ausgetauscht werden soll).

Wobei ich Deine Intention dahinter nicht wirklich verstehe ... willst Du nun eine 06.2x für die 7360v1 bauen und dann auch wirklich benutzen (was Dich auf eine sehr alte und sehr unsichere Firmware festlegt) oder willst Du eine neuere (immer noch mit deutlichen Sicherheitsrisiken - auch die 06.8x ist für den "echten" Einsatz eigentlich nicht mehr tauglich, die hat m.W. die WLAN-Lücken der letzten zwei Jahre auch weiterhin) Firmware verwenden? Wie man es auch dreht und wendet - spätestens dann, wenn das Teil als Edge-Router oder mit WLAN eingesetzt werden soll, ist das ein wandelndes Scheunentor - weshalb würde man sich so etwas in sein Netz holen?

Wenn man das alte Schätzchen unbedingt in Betrieb nehmen wollte, dann wäre ggf. OpenWRT vielleicht noch eine Option - m.W. dann aber auch nur ohne WLAN, weil das unter OpenWRT nicht unterstützt wird (ebenso wie die Telefonie, etc.). Wo willst Du also eigentlich hin damit? Meine Neugierde ist u.a. dadurch begründet, daß man bei weiteren Diskussionen schon wissen sollte, wohin das am Ende führen wird - daran kann man dann abschätzen, wieviel Aufwand sich noch lohnt für solche alten Geräte. Nur weil man Freetz auf so einer Box installiert, merzt man eben die Sicherheitsprobleme alter FRITZ!OS-Versionen nicht aus, denn Freetz-NG baut ja auf irgendeiner FRITZ!OS-Version auf und verwendet für die allermeisten Komponenten auch die AVM-Software. Eigentlich wird das FRITZ!OS durch Freetz nur erweitert - es gibt praktisch keine Freetz-NG-"Fixes" für Probleme im FRITZ!OS - die bleiben einfach bestehen, wenn man die Komponenten nicht entfernt.
 
Wenn man sich das bei GitHub direkt ansieht (Warum nimmt man eigentlich gitmemory.com? Das hier ist wieder mal ein schönes Beispiel für "incomplete data".): https://github.com/Freetz-NG/freetz-ng/issues/325, dann ist das - nach meinem Verständnis - gefixt.
Weil google mir nur diese links angezeigt hat und ich diese auf github nicht gefunden habe.

Wobei es sein kann, daß beim Einsatz von usb_root die Ladereihenfolge so durcheinander gewürfelt wird, daß modload zu spät erst aufgerufen wird - schließlich soll bei dieser Art des Starts das init-Kommando durch das Shell-Skript rc.usbroot ersetzt werden.

Und das wäre die erste Stelle, wo man nachsehen sollte ... wie genau sehen denn (in der Boot-Console) die Kernel-Parameter aus? Irgendwo darin muß (a) das init durch das Shell-Skript ersetzt werden und (b) - wenn ich mich richtig erinnere, das ist schon wieder Jahre her - auch eine Angabe zu finden sein, welches Storage-Device als rootfs gemountet werden soll (bzw. gemountet werden und danach mit pivot_root gegen das aktuelle ausgetauscht werden soll).
Ich habe mich inwischen auch mit init auseinander gesetzt. Ich dachte nur, eventuell gibt es eine einfache Möglichkeit das zu fixen.
Eventuell könnte man mit kexec oder mit switch_root eine saubere Lösung bauen, als die bisherige Lösung. Wobei kexec den Vorteil hat, dass der geflashte Kernel und der Kernel auf dem USB-Stick nicht mehr der gleiche sein müssen.

Wo willst Du also eigentlich hin damit?
An sich wäre das Endziel ein so modernes FRITZ!OS wie nur möglich auf dieser Box laufen zu lassen. Nur ist mir klar, dass das eine verdammt große Aufgabe ist, wesswegen ich Stück für Stück vorgehen muss. Auch möchte ich Freetz kennen lernen und dann ist da auch noch der Spaß an der Freude.

Der erste Schritt, wäre es 06.8x von der 7360_v2 auf der 7360_v1 laufen zu lassen. Da dieses Image aber wesentlich größer ist, brauche ich einen Weg, das Speicherlimit zu umgehen. Auch ist der Vorteil, wenn von USB gebootet wird, dass man einfacher Dinge ausprobieren kann, da das flashen doch ziemlich lange dauert. Der nächste Schritt wäre es dann eine 07 version von der 7362 SL auf der 7360_v1 laufen zu lassen.
 
Vorab ein Wort der Warnung ... die Kombination aus "einfache Lösung" und "eine 07 version von der 7362 SL" funktioniert (zumindest nach meiner Erfahrung) so garantiert nicht. Ich will nicht behaupten, daß es komplett aussichtslos wäre - schließlich arbeiten beide Geräte mit demselben (Haupt-)Prozessor, aber schon bei der Frage, ob sie auch beim WLAN identische Komponenten verwenden, würde ich mich erst einmal vergewissern und das gilt ebenso für die weiteren (AVM-spezifischen) Komponenten wie das verwendete FPGA, den DECT-Chip, etc. - wenn Du das schon geklärt hast und die identisch sind (ich habe keines der alten Modelle, die einzigen VR9-Boxen sind die 7490 und die 7412, weil die einige Besonderheiten aufweist), dann lohnt es sich u.U. auch, da weiter zu machen.

Man kann Freetz auch unabhängig von dem Ziel mit 07.xx auf der Box kennenlernen - für eigene Versuche, die (m.E.) nötig wären, um das Problem hier in Angriff zu nehmen - ist die gesamte Toolchain (von den "host tools" bis hin zum "fwmod" als Image-Builder) aber zu unflexibel oder zumindest zu unhandlich. Teile davon kann man durchaus nutzen, aber mit einem einfachen make und einer Portion Gottvertrauen wird man nicht weit kommen - weil man dann seine eigenen Änderungen auch alle so gestalten muß, daß sie sich in das Freetz-Framework einfügen. Ich würde mir auch nicht die Arbeit machen, das Ganze dann über drei FRITZ!OS-Generationen lösen zu wollen (es sei denn, das primäre Ziel wäre das Erweitern von Freetz-NG um genau diese Optionen), sondern - wenn schon, denn schon - direkt auf das Ziel losmarschieren.

Am Ende willst Du ja offensichtlich einen "Spezialfall", der in Freetz-NG nur für ältere Modelle zur Verfügung steht, wobei man das eben auch erst noch verifizieren müßte (was sicherlich schon lange niemand mehr getan hat), denn bei Dir funktioniert das ja (wenn ich's richtig lese) auch mit der 06.33 für die 7360v1 nicht (ich vermute mal, daß das 06.20+ die 06.3x-Reihe (als Release) einschließen soll). Es ist nun mal nicht auszuschließen, daß Änderungen in Freetz-NG die Funktion dieses Pakets beeinflußt haben. Der einfachste Weg, das zu überprüfen (und erst mal ein bisect(ing) durchzuführen), wäre es jetzt, dasselbe mit dem originalen Freetz zu versuchen (die Unterstützung für die 7360v1 mit 06.33 ist da ebenso vorhanden): https://github.com/Freetz/freetz/blob/75984884e4353db3b45b04cd37707c6e929ca0ec/FIRMWARES#L217 ... damit kann man zumindest schon mal feststellen, ob man vor oder nach dem Fork suchen muß, welcher Patch das "zerstört" hat (wobei es soo viele Patches an den Dateien, die tatsächlich das Paket ausmachen, gar nicht gab, der überwiegende Teil ist noch aus 2013-2014).



Aber das ist dennoch (nach meiner Ansicht) ein sehr langer und auch sehr steiniger Weg - und den willst Du dann gleich für mehrere FRITZ!OS-Versionen gehen, die sich auch in den "inneren Werten" deutlich weiterentwickelt haben im Laufe der Zeit. Das würde ich auch nicht machen ... sondern (wenn ich die Zeit opfern wollte, was mindestens von den o.a. (Er-)Kenntnissen abhängt und den damit anzunehmenden Erfolgsaussichten) mir gleich die "finale" Version greifen und zunächst mal deren Kernel (und ggf. auch deren Dateisystem) so weit modifizieren, daß tatsächlich am Beginn nur die Aktionen ausgeführt werden, die für eine Initialisierung des USB-Stacks und die Benutzung von Storage-Devices am (internen) USB-Hub erforderlich sind. Das ist schon genug "Kram", der da gebraucht wird, aber alles das läßt sich immer noch ganz bequem im verfügbaren Flash-Speicher unterbringen. Letztlich macht das Freetz nach demselben Prinzip ... auch hier werden die Treiber für die USB-Unterstützung "außer der Reihe" geladen: https://github.com/Freetz/freetz/bl...usbroot/files/root/etc/init.d/rc.usbroot#L421 (ansonsten übernimmt das der udevd) und auch alle anderen "Vorbereitungen", die ansonsten in den init-Skripten stattfinden (auch dann noch, wenn neuere FRITZ!OS-Versionen mit supervisor (einen systemd-Derivat) arbeiten), werden in rc.usbroot ja in den versionsspezifischen Funktionen "von Hand" ausgelöst: https://github.com/Freetz/freetz/bl...usbroot/files/root/etc/init.d/rc.usbroot#L148 - warum die piglet-Treiber noch davor geladen werden, weiß ich nicht - entweder da gibt/gab es Abhängigkeiten oder es sollte die AVM-Reihenfolge so gut es geht nachgebildet werden.

Aber was auch immer der Hintergrund sein mag - am Prinzip, daß erst einmal der Kernel starten muß und der dann (ob nun per Flash-Scanner wie bei AVM oder über ein eingebettetes initramfs) irgendwo nach einem rootfs sucht, ändert sich ja nichts und damit ist das auch der allererste Teil (mit der richtigen Kernel-Version), den man zum Laufen bringen muß. Ob man danach das "richtige" Dateisystem auf dem USB-Speicher als SquashFS-Image mountet und mittels pivot_root dorthin wechselt (so macht es AVM ja selbst bei den VR9-Modellen mit NAND-Flash, nur daß für dessen Nutzung eben kein USB-Stack gebraucht wird) oder ob man es mit einem Overlay versucht (ich weiß nicht mehr genau, ab wann OverlayFS im Kernel verfügbar ist - aber bei AVM ist es (iirc) bei den VR9-Boxen nicht eingeschlossen), kann man sich immer noch überlegen, wenn man es erst einmal bis zu einem solchen Kernel geschafft hat.

Und vor diesem Erfolg (gerade dann, wenn Du am Ende bei einer Firmware landen willst, die eigentlich von NAND-Flash ausgeht, wie bei der 7362SL) hast Du noch so einige Hürden zu überwinden. Das geht - selbst wenn die Komponenten dieselben sind wie bei der 7362SL - dann wieder bei der Frage los, ob das Hardware-Layout (welcher GPIO-Pin ist wohin verbunden und wofür wird er genutzt) auch paßt - ansonsten muß man es erst einmal passend machen. Wenn bei der 7362SL das RST-Signal für irgendeinen Ethernet-PHY an der Stelle liegt, wo der Kernel eine der LEDs "vermutet", würde jeder Versuch, die LED zu schalten, den PHY zurücksetzen ... ähnliches gilt auch für die Anbindung des NAND-Flashs und praktisch aller weiteren Komponenten, die eben nicht über irgendeinen (komplexeren) Bus mit dem Hauptprozessor kommunizieren.

Es läuft dann vermutlich am Ende ohnehin auf einen eigenen Kernel, ggf. auf Basis der passenden Kernel-Quellen für die gewünschte FRITZ!OS-Version, hinaus - aber auch den mußt Du dann eben erst einmal "zusammen kriegen" (wobei Dir die Freetz-Toolchain (in Maßen) helfen kann) und (ausgiebig genug) testen - wobei die Initialisierung dieser Hardware-Komponenten i.d.R. schon direkt beim Start des Kernels erfolgt und das alles noch lange vor der Notwendigkeit eines rootfs erledigt ist. Danach muß man dann erst mal erkunden, welche Treiber bei der gewählten FRITZ!OS-Version tatsächlich benötigt werden, um den USB-Stack so weit zu initialisieren, daß man überhaupt daran denken kann, Storage-Devices dort zu erkennen und zu mounten.

Da das ganze usb_root-Zeug auch noch aus einer Zeit stammt, wo es bei AVM gerade mal eine Handvoll an SoC gab, die es zu unterstützen galt (praktisch alle MIPS - ggf. auch mal als LE-Variante), wird das vermutlich auch eher eine "Speziallösung" für VR9-Prozessoren werden - was man berücksichtigen müßte, wenn das Primärziel die Erweiterung von Freetz-NG sein sollte ... das Interesse an VR9-Boxen läßt inzwischen (bei der Masse der Benutzer) auch deutlich nach, das an Vx180-Geräten (primär 7390) ist - m.E. - praktisch gar nicht mehr vorhanden, weil die Plattform zu alt ist für moderne Anschlüsse (u.a. hat dieses SoC nur einen Core und ist damit entsprechend "unflexibel").

Ich will Dich auch nicht entmutigen ... aber anstatt über kexec nachzudenken (bis zu dem Punkt, wo man einen solchen Syscall überhaupt ausführen könnte, muß man auch erst mal kommen und dann diesen neuen auszuführenden Kernel auch erst einmal von irgendwo laden können), solltest Du Dich eher darauf konzentrieren, einen passenden Kernel für die Box zu erstellen (wie geschrieben, hast Du da bei der Initialisierung der Hardware vermutlich schon genug zu tun, auch wenn das meinerseits nur "geraten" ist anhand dessen, was ich so aus den Kernel-Quellen kenne), der tatsächlich den USB-Zugriff ermöglicht zu einem Zeitpunkt, wo der Rest der AVM-Komponenten noch gar nicht initialisiert ist. Denn bei einen Restart der Box findet eben auch ein Gutteil der Initialisierung schon im Bootloader statt (den kann man ja praktisch als BIOS sehen, auch wenn er kein API für das OS bietet, wie es ein "klassisches BIOS" nun mal macht) und irgendwelche "nachträglichen" Initialisierungsversuche durch einen neuen Kernel würden die meisten Komponenten auch erst einmal wieder zurücksetzen, womit dann auch wieder die Funktion des USB-Stacks in Frage gestellt würde, etc. ... das kexec ist nicht umsonst ein "spezieller" Syscall, der eher für Fehlersuchen und Entwicklung gedacht ist.

Was Du aber mal testen könntest ... ich bin mir nicht sicher (weil ich noch keine 7360v1 selbst getestet habe, die "abgespeckten" Modelle sind nicht so meins), würde dennoch behaupten/annehmen, daß auch bei der 7360v1 ein Start des OS aus dem RAM möglich ist (das ging auch bei der 7390). Zwar wird dieser Weg von AVM selbst nicht genommen, um das OS zu installieren (wie bei den Modellen mit NAND-Flash und wrapper-Partition mit YAFFS2-FS), aber das heißt noch nicht automatisch, daß man ihn nicht selbst gehen könnte. Man kann ja noch einmal in die Kernel-Quellen sehen (den Flash-Parser findet man schnell), ob das (a) unterstützt wird und (b), welche Dateisystemformate dabei berücksichtigt werden. Dann kann man sich aus dem Kernel und einem passenden Dateisystem wieder ein Image zusammenbauen, das man direkt aus dem RAM starten kann - das kostet zwar ein paar MB an Hauptspeicher zur Laufzeit, schont aber den Flash-Speicher und braucht i.d.R. auch weniger Zeit, als wenn man das Zeug erst in den Flash schreiben und dann von dort starten läßt.

Zumindest für die ersten Gehversuche (die sich ja i.d.R. darum drehen würden, erst mal einen "fehlerfreien" Start des Kernels zu ermöglichen) wäre das ein gangbarer Weg - erst recht dann, wenn man die serielle Console bestückt hat. Da bleibt auch noch genug übrig von den vorhandenen 128 MB RAM, so daß man diese Phase durchlaufen kann, ohne auch nur ein einziges Byte in den NOR-Flash (für das System zumindest) zu schreiben. Selbst wenn der Parser bei der 7360v1 ungenutzten Flash-Speicher als JFFS-Partition für den AB nutzen wollte, muß man eben dafür sorgen, daß er keinen solchen ungenutzten Platz findet. Da man (vermutlich zumindest) ohnehin einen eigenen Kernel verwenden muß, sind ein paar eigene Anpassungen da auch kein zusätzliches Problem bzw. kein zusätzlicher Arbeitsschritt/größerer Aufwand.

Ich denke jedenfalls nicht, daß ein (originaler) 07.12-Kernel für die 7362SL auf einer 7360v1 überhaupt eine Chance hat zu funktionieren - schon der Unterschied NOR vs. NAND erfordert ja ein anderes Layout, denn NAND-Flash ist eben nicht über den Data-Bus direkt als Speicher adressierbar und muß praktisch "sequentiell" ausgelesen und die Daten ins RAM geschrieben werden. Vielleicht hat AVM ja tatsächlich in den VR9-Quellen sowohl die Unterstützung von NOR-Flash als auch von NAND-Flash vorgesehen (da gibt/gab es immer mal wieder ein paar Symbole, die das nahelegen könnten), aber dann müßtest Du vermutlich immer noch den eigenen Kernel mit den richtigen Settings bauen (lassen).

Jedenfalls erfordert Dein Vorhaben schon einigermaßen solide Kenntnisse davon, wie Linux an sich und auf "embedded devices" im Speziellen funktioniert und wie AVM einiges davon gelöst hat. Da kommt dann noch ein grundlegendes Verständnis von C-Programmierung dazu, denn ganz ohne eigene Änderungen an den Kernel-Quellen (und die sind praktisch zu 100% C-Code) wird es vermutlich auch nichts werden. Das wird also ein recht anspruchsvolles Hobby ... was Dich nicht entmutigen sollte. Aber Du solltest dann eben auch nicht erwarten, daß Du sehr schnell große Erfolge erzielen kannst oder gewaltige Fortschritte sich quasi automatisch einstellen - wenn Du erst beginnst, Dich mit der Materie zu befassen, wird das eine lange "Lehrzeit" werden.

Aber auch eine Reise von tausend Meilen beginnt mit einem einzigen Schritt (wird als Zitat m.W. Konfuzius zugeschrieben) ... und wenn Du Dir "einen Plan" machst, solltest Du - meine Empfehlung - an den Anfang das Erkunden der Möglichkeiten der Hardware/des Bootloaders setzen (das wäre u.a. das Starten aus dem RAM) und den Vergleich der (primär Hardware-)Komponenten zwischen der 7360v1 und dem Gerät, dessen Firmware Dein "eigentliches Ziel" wäre. Du kannst zwar auch Schritt für Schritt den AVM-Versionen folgen (das wäre dann die 06.33 für die 7360v1, danach irgendwann mal die 06.8x für die 7360v2, dann später noch die 07.12 für die 7362SL), machst Dir aber am Ende auch dreimal die Arbeit. Allerdings stehen die Chancen, das bei der Firmware für die 7360v2 hinzubekommen, m.E. auch deutlich besser, als beim Versuch, eine - in weiten Teilen andere - Firmware (wie die der 7362SL) auf die 7360v1 zu bekommen.

AVM ist eigentlich nicht dafür bekannt, populäre Modelle allzu schnell fallen zu lassen (zumindest war das bis vor einigen Jahren so) und wenn da die Entscheidung getroffen wurde, die 7360v1 ab 06.5x nicht mehr zu unterstützen, hatte das sicherlich auch seinen Grund. Bei anderen Modellen mit knappem Flash-Speicher (wie z.B. der 7390) hat man sich ja auch etwas einfallen lassen (allerdings hat die auch noch internen Flash fürs NAS, den man dabei (mittlerweile) nutzt) und einen Plugin-Mechanismus eingebaut, der u.a. die für das WLAN benötigte Software (als "größerer Brocken") erst bei bestehender Internet-Verbindung von einem AVM-Server nachlädt - ähnliches könnte man (als Hobby zumindest) auch noch in Erwägung ziehen.

Wenn man es erst einmal hinbekommen hat, daß man ein Storage-Volume ansprechen kann, BEVOR die ganzen AVM-Komponenten initialisiert wurden, dann ist das schon deutlich mehr als nur die halbe Miete ... vielleicht wäre es doch klüger (je nach Nachhaltigkeit Deiner Ambitionen), entgegen meinem ersten Vorschlag, sich eher auf die Firmware der 7360v2 zu konzentrieren. Nur wirst Du mit der eben auch final nur auf einem Firmware-Stand landen, den man eigentlich nicht mehr einsetzen sollte - da man nicht genau weiß, wo die (Sicherheits-)Probleme der AVM-Firmware wirklich liegen (ich kenne auch nur eine kleine Auswahl davon und habe versucht, die zu dokumentieren), wird daraus dann vermutlich auch kein Gerät, was man guten Gewissens tatsächlich irgendwo produktiv nutzen kann (zumindest nicht in dem Umfang, wie es eine AVM-Firmware erlauben würde und wenn man den "zusammenstreicht", kann man sich auch gleich nach Alternativen umsehen).

Wenn man also ein so altes Gerät "in vollem Umfang" nutzen will (und wenn man sich eine 07.xx-Firmware wünscht, kann das ja fast nur noch wg. Mesh und/oder SmartHome sein, denn ansonsten hat AVM in den letzten Versionen ja (fast) nichts (wesentlich) geändert), dann lohnt sich (in meinen Augen) der Aufwand nicht (auch nicht "zum Üben", weil neuere Modelle dann auch wieder anders aufgebaut sind und andere Probleme haben/bereiten) ... etwas anderes wäre es z.B., wenn man das nur als zusätzliche DECT-Basis für einen zweiten Aufstellort oder als (internen) SIP-Registrar nutzen wollte, wobei man dann auch nicht zwingend auf eine 07.xx-Version muß - und mit der Option, nicht verwendete Teile aus der Firmware zu entfernen, auch schon wieder realistischere Aussichten hat, das in den vorhandenen Flash-Speicher zu packen. Aber ein "ich will alles" steht solchen Alternativen dann halt auch im Weg - die aber ohnehin nur in Frage kommen, wenn es sich um eine "rein interne" Nutzung handelt (ansonsten ist das Risiko wieder unkalkulierbar - das ist schon bei rein interner Nutzung "kein Spaß").
 
... aber schon bei der Frage, ob sie auch beim WLAN identische Komponenten verwenden, ...

Ich glaube an der Stelle hat man dann das gleiche Problem wie mit der 7412 (7430er 07 Alien auf 7412) denn bzgl. WLAN hat man da das Problem, das sowohl bei der 7360v1/v2/SL als auch der 7412 der Atheros AR9287 (aka Kiwi) zum Einsatz kommt und die dazugehörige Treiberunterstützung hat wohl AVM mit FRITZ!OS 7.xx entfernt, da es keine Modelle mehr von AVM mit FRITZ!OS >=7.00 und AR9278 gibt:
https://www.onlinekosten.de/forum/showthread.php?p=2459460#post2459460
https://www.ip-phone-forum.de/threa...560-7430-7362-sl-und-4040.299120/post-2296069

Bei der 7362 SL als auch der 7430 kommt der AR9231 (aka Osprey) zum Einsatz und daher sind dafür in FRITZ!OS 7.xx bzw. dem dazugehörigen VR9-Kernel noch funktionierende Treiber vorzufinden.
 
  • Like
Reaktionen: PeterPawn
Erstmal vielen Dank für die ganzen Infos. Ich weis garnicht wo ich anfangen soll zu antworten. Auf jeden fall ist es gut jetzt mal alle Informationen die ich brauche, auf einer Stelle zu haben, anstatt sie sich aus 100 Seiten zusammensuchen zu müssen.

Das eigentliche Ziel ist es halt etwas mehr über Linux und die Umgebung und Hardware zu lernen. Wenn ich mein Ziel von 7.xx auf der 7360 nicht schaffe, ist das nicht weiter schlimm, dann suche ich mir etwas anderes was man damit machen kann. Ich habe auf jeden fall schon beim Löten der seriellen Schnittstelle einiges gelernt. Ich finde es ja schön, dass ihr verhindern wollt, meine Zeit zu verschwenden, aber wie gesagt, ich sehe das hier als ein Hobbyprojekt und Erkentnisse nimmt man immer mit. Auch c Programmierung ist kein Problem, auch wenn es bisher nichts mit dem Linux-Kernel war.

Das Deteil bezüglich AR9287 und AR9381 hatte ich schon mal gelesen, aber mich damit noch nicht so viel damit beschäftigt. Eventuell reicht es ja vermagic der Kernelmodule anzupassen. Da weis ich leider nicht wie weit sich der Kernel verändert hat. Oder man schaut, ob man 3.10.73 mit der 7.xx zum laufen bekommt.

Also nochmal vielen Dank für die Infos vorallem dir PeterPawn! für deinen schreibwütigen Text er war auf jeden fall sehr Informativ. Abgehalten von meinem Plan hat mich das aber nicht. Ich werde mir auch mal den Thread bezüglich 7430 Alien auf 7412 durchlesen. Ich wette das ich auch nochmal wieder komme mit neuen Fragen und noch verrückteren Ideen.
 
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.