danisahne-mod

[olistudent]

Die Box wird dir der mod nicht killen.
Da aber bei jedem Flashvorgang ein Fehler auftreten kann, wie man auch an den häufigen Meldungen hier im Board sieht, ist es genauso gefährlich wie ein normales Firmware Update.
Und wir haben den mod ja erfolgreich getestet und für gut befunden.

MfG Oliver

edit: Okay, vielleicht ist es doch ein bißchen gefährlicher...

 

[danisahne]

ACHTUNG: Hab ds0.1rc5 gleich wieder rausgenommen, weil es bei buehmann bei einem 2ten Update zu genau den selben Problemen kam, wie ich sie hatte. Unsere Vermutung ist, dass der Update einer bereits mit "contiguous squashfs" modifizierten Box fehlschlägt (muss erst noch reproduziert werden). Für alle wenigen, die ds0.1rc5 bereits installiert haben: Keinen weiteren Firmware-Update machen, bis eine Lösung da ist (bis jetzt konnte man eine tote Box jedesmal wieder mit dem recover Skript wiederbeleben).

Modden ist ja wie eingangs erwähnt auf eigene Gefahr, also schön das recover Perl Skript von Enrik und eine ungemoddete Firmware bereithalten.

Gruß,
danisahne

 

[fritzchen]

Hi danisahne,

ich lasse meine Box erst mal auf dem Stand, weil sie gebraucht wird.

Ich habe es mir trotzdem angeschaut, und festgestellt, dass die Konfiguration viel schwieriger geworden ist.

Egal - unter suse 10 bekomme ich die Meldung, ncurses sei nicht installiert - stimmt aber nicht.

Unter debian läuft es jedoch alles sauber durch

 

[danisahne]

Das ist wohl Ansichtssache. Was würdest du an der Konfiguration ändern? "Compiler options" brauchst du ja zum Erstellen der Firmware nicht, vielleicht sollte ich die besser verstecken. Mit den vordefinierten Optionen kannst du immer die aktuelle Version erstellen, mußt also nichts ändern. Ich hab die Konfiguration halt lieber in Form von menuconfig als verteilt in mehreren Config Dateien. make menuconfig ist finde ich intuitiver.

Zu ncurses: Wenn ich mich recht erinnere brauchst du ncurses-dev, da das menuconfig Programm ja erst kompiliert werden muss.

EDIT: Ja, es müßten die Development Pakete sein, die man für ncurses benötigt. Zu menuconfig: Wären weniger Untermenüs übersichtlicher?

EDIT2: Mittlererweile ist dank olistudent klar, wo das Problem mit dem "contiguous squashfs" liegt: Das Programm copy_firmware nimmt beim nächsten Firmware Update die nach dem Patch nun veränderte Adressen für mtd1 zum erneuten Flashen, d.h. das root Filesystem landet an der falschen Stelle. Gibt es noch jemanden, der ds0.1rc5 installiert hat?

Mfg,
danisahne

 

[fritzchen]

@danisahne:

es ist sicherlich besser geworden - an mir nagt nur die Macht der Gewohnheit. Aber ich bin natürlich FÜR das menü

ncurses unter suse macht weiter Probleme, dev ist naütrlich installiert. Da können wir uns wohl auf ein paar viele Fragen gefasst machen. Aber dafür gibt es ja Knoppix.

Was ich mit komplizierter meinte:
ich mache wechselnd images für die fbf, fbf wlan und die 7050. Aber dafür kann ich ja verschiedene .conf-Dateien anlegen.
Wie binde ich jetzt das openvpn-Paket ein? Meinen Ansprüchen genügt es bereits .

Besten Dank!

 

[dksoft2]

Wie binde ich jetzt das openvpn-Paket ein? Meinen Ansprüchen genügt es bereits .

Einfach das tar-Archiv in das Verzeichnis packages extrahieren. Dann hast du dort ein Unterverzeichnis openvpn-0.2. Danach in packages.static openvpn-0.2 eintragen. Fertig.

Wenn dein Image zu groß wird kannst du die Datei packages/openvpn-0.2/usr/bin/openvpn löschen, musst dann aber eine URL mit dem tar-Archiv, in dem usr/bin/openvpn liegt, im Menü einstellen. Das ist eine Hilfslösung, solange ds-mod keine dynamischen Pakete implementiert hat.
Ansonsten mal kurz in das README schauen.

 

[buehmann]

ncurses unter suse macht weiter Probleme, dev ist naütrlich installiert.

Bei hat es übrigens unter SuSE auf Anhieb funktioniert; aber frag mich jetzt bitte nicht, warum. ;-)

Wie binde ich jetzt das openvpn-Paket ein?

Ich hatte gestern auch Probleme, mal eben ein eigenes Paket einzubinden; das war "früher" mit packages.static praktischer.

@danisahne: Schön, dass die Ursache für unsere Recover-Fälle schon gefunden ist. Ich hatte gestern Nacht noch genau dieselbe Idee mit den "falschen" Positionen für mtd0/1. Aber wie lösen bzw. umgehen wir das Problem?

Gruß,
buehmann

 

[olistudent]

Hi, buehmann.
Ich werde mich an der Lösung dieses Problems versuchen.
Wir müssen die Grenzen für den mtd0/mtd1 so lassen, wie sie sind.
Das hidden_root muss als zusätzliche Partition hinzugefügt und als root registriert werden.

MfG Oliver

 

[danisahne]

So hätte ichs mir überlegt:

Normal:
|----------------mtd1----------------|------------------mtd0-------------------|
|-------Kernel-------|---unbenutzt---|---------------Dateisystem---------------|

Was nicht geht:
|--------mtd1--------|--------------------------mtd0---------------------------|
|-------Kernel-------|-----------------------Dateisystem-----------------------|

Wie es gehen könnte:
|--------mtd1--------|---Ende_mtd0---|---------------Anfang_mtd0---------------|
|-------Kernel-------|-----------------------Dateisystem-----------------------|

Allerdings ist das etwas schwieriger, weil noch tiefer eingegriffen werden muss. Es muss beim Lesen eine Adressumsetzung passieren, also an einer anderen Stelle Code wie der Patch war. Was sind andere Vorschläge? Wenn wir eine weitere Partition anstatt Ende_mtd1 machen, dann sind wir wieder am Anfang, wie es auch schon beim hidden squashfs war oder kann mann vielleicht ein squashfs über 2 Flashpartitionen hinweg mounten? Wenn das nicht geht, dann wäre vielleicht das Patchen vom der squashfs Implementierung der beste Weg. Jetzt hab ich mal ein bisschen mit den Gedanken gespielt, mal sehen was sich verwirklichen lässt.

EDIT: Hab mtd0 und mtd1 vertauscht, in der Darstellung oben ist es nun korrekt.

Mfg,
danisahne

 

[buehmann]

Ich finde den Vorschlag von Oliver am saubersten (und am einfachsten umzusetzen); wenn ich ihn richtig verstanden habe, sieht er in deiner graphischen Darstellung so aus:

Olivers Vorschlag:
|----------------mtd0----------------|------------------mtd1-------------------|
                     |----------------------------mtd4711----------------------|
|-------Kernel-------|-----------------------Dateisystem-----------------------|

Es wird also einfach ein neuer Bereich für die Root-Partition allokiert, der mit den bestehenden überlappt. Gelesen werden der Kernel aus mtd0 und das Dateisystem aus mtd4711; zum Schreiben wird wie bisher die Kombination mtd0/1 benutzt.

Gruß,
buehmann

 

[danisahne]

Ach das fänd ich auch besser. Wußte nicht, dass sich Flash Partitionen überlappen können.

 

[buehmann]

Wußte nicht, dass sich Flash Partitionen überlappen können.

Sagen wir mal so: Ich hoffe, dass das geht.

 

[danisahne]

Eigentlich müßte es gehen (ist mir gerade aufgefallen), da ja das hidden squashfs hinter dem Kernel doch auch ein mtd Device bekommt, oder? Das überlappt aber mit mtd0.

EDIT: Es muss mtd1 heißen; der Kernel ist in mtd1

 

[buehmann]

das hidden squashfs hinter dem Kernel doch auch ein mtd Device bekommt, oder? Das überlappt aber mit mtd0.

Stimmt! (mtd6 oder mtd7) Kann man eigentlich den Partitionen beliebige Namen geben oder verlässt sich irgendetwas auf diese mtd?-Konvention? /dev/mtdblock/root oder so wäre nicht verkehrt.

 

[danisahne]

Gute Nachrichten: olistudent hat bereits einen funktionsfähigen Kernel mit "contiguous squashfs", der das Problem mit den Firmware Updates umgeht. Ihr dürft euch also auf eine korrigierte Fassung mit dem neuen Feature zum Wochenende freuen.

Mfg,
danisahne

 

[Massa]

Gute Nachrichten: olistudent hat bereits einen funktionsfähigen Kernel mit "contiguous squashfs", der das Problem mit den Firmware Updates umgeht. Ihr dürft euch also auf eine korrigierte Fassung mit dem neuen Feature zum Wochenende freuen.

Mfg,
danisahne

Cool 8)
Dann bin ich mal gespannt, ob ich mit rc5/rc6 noch zurecht komme.
Und vor allem, ob ich meine "custom" Änderungen noch problemlos reinbekomme

Edit: ich habe gerade mal die erste Seite neu gelesen.
Wie sieht es denn mit dem Update von einer bestehenden Version aus?
Funktioniert das dann noch oder muss ich meine ganzen danisahnemod-Einstellungen neu machen ?
Oder sollte ich womöglich vor dem Update die ds-mod Einstellungen sicherheitshalber entfernen :shock: ?

MfG,
Massa

 

[danisahne]

Und vor allem, ob ich meine "custom" Änderungen noch problemlos reinbekomme

Wenn du die rc.custom oder die debug.cfg meinst, dann wirst du deine Änderungen wahrscheinlich problemlos behalte können.

Edit: ich habe gerade mal die erste Seite neu gelesen.
Wie sieht es denn mit dem Update von einer bestehenden Version aus?

Kein Problem, außer du hast ds0.1rc5 installiert. Dann solltest du dich unbedingt bei mir per PN melden.

Funktioniert das dann noch oder muss ich meine ganzen danisahnemod-Einstellungen neu machen ?
Oder sollte ich womöglich vor dem Update die ds-mod Einstellungen sicherheitshalber entfernen :shock: ?

Wenn du mit Einstellungen die Einstellungen auf der Box meinst (also Port 81 Webinterface und /tmp/flash), dann mußt du überhaupt nichts machen. Das bleibt alles wi e es ist. Beim Erstellen der Firmware hat sich so manches geändert, also bevor sie auf die Box kommt.
Der neue Kernel, insbesondere "contiguous squashfs", ist (fast) völlig transparent für dich, du kannst dich nur über mehr Platz im Image freuen.

Mfg,
danisahne

 

[Massa]

Wenn du die rc.custom oder die debug.cfg meinst, dann wirst du deine Änderungen wahrscheinlich problemlos behalte können.

Jein
Die meinte ich auch, aber eigentlich meinte ich die "Custom"-Möglichkeit beim Firmware bauen.
Da gab es doch die Möglichkeit (ich glaube es war DO_CUSTOM=yes) ein eigenes Script auszuführen.
Das nutze ich intensiv, um Webseitenänderungen durchzuführen (ENUM, Internationale Vorwahl, ...) :wink:

Kein Problem, außer du hast ds0.1rc5 installiert. Dann solltest du dich unbedingt bei mir per PN melden.

Nöö, habe noch rc4

Wenn du mit Einstellungen die Einstellungen auf der Box meinst (also Port 81 Webinterface und /tmp/flash), dann mußt du überhaupt nichts machen. Das bleibt alles wi e es ist.

Ja, ich meinte das per modsave im Flash gespeicherte tar...

Beim Erstellen der Firmware hat sich so manches geändert, also bevor sie auf die Box kommt.
Der neue Kernel, insbesondere "contiguous squashfs", ist (fast) völlig transparent für dich, du kannst dich nur über mehr Platz im Image freuen.

Na dann freue ich mich schonmal 8)

MfG,
Massa

 

[danisahne]

Die meinte ich auch, aber eigentlich meinte ich die "Custom"-Möglichkeit beim Firmware bauen.
Da gab es doch die Möglichkeit (ich glaube es war DO_CUSTOM=yes) ein eigenes Script auszuführen.

Das bleibt auch alles wie gewohnt. Einizger Untrschied: Die Variable DO_CUSTOM (sie hieß ein wenig anders) gibt es nicht mehr, das Skript `fwmod_custom' wird jetzt immer aufgerufen. Du mußt also im Grunde nur deine alte fwmod_custom in den aktuellen mod nach dem Entpacken reinkopieren.

Um es mal generell zu sagen: Ich habe nicht vor die Konfiguration auf der Box und den Einsatz des Skripts `fwmod_custom' jemals inkompatibel zu verändern. Es wird wenn dann nur Erweiterungen geben.

@Massa:
Du kannst mir gerne mal deine Patches schicken, dann kann ich sie vielleicht optional mit einbauen. So ein Art "Massa patch-pack"

Gruß,
danisahne

 

[Massa]

@Massa:
Du kannst mir gerne mal deine Patches schicken, dann kann ich sie vielleicht optional mit einbauen. So ein Art "Massa patch-pack"

Naja, das sind halt einfach Webseitenanpassungen, die hier im Forum in verschiedenen Threads verteilt beschrieben sind.
Insgesamt werden damit halt weitere Optionen über die Webseiten freigeschalten.
Ob die jeder brauchen kann, oder ob das für manchen dann zu kompliziert wird, kann ich nicht sagen.
Wenn Du willst, kann ich Dir ja mal meine fw_custom schicken.
Habe ich allerdings hier gerade nicht parat - frühestens morgen abend

Vielleicht sollte ich die nochmal anpassen, damit die Änderungen dann nur bei Aktivierung von "erweiterten Einstellungen" auftauchen
und auch bei jeder Branding-Version funktionieren...

Achja, nochwas was Du IMHO ganz einfach als Menüpunkt in Deinen ds-mod einbauen könntest :wink:
Das Einstellen des Brandings also z.B. eine Radiobuttonliste mit "AVM (avm), AVM International (avme), 1und1 (1und1), freenet, ..."
Auslesen lässt sich das ja über

cat /proc/avalance/env | grep firmware_version

und Speichern dann z.B. über

echo "firmware_version avm" > /proc/avalanche/env

(wirkt allerdings erst nach Reboot)

Oder meinst Du die Auswahlmöglichkeiten braucht keiner und jeder will eine "avm"-Version :wink: ?