Angepinnt Bootstrap - Erweiterungen / Änderungen auf USB auslagern

      Bootstrap - Erweiterungen / Änderungen auf USB auslagern

      Moin Leutz!

      Da ich zwar gern Bastel, aber dabei möglichst nichts zerstören will - kam schon recht früh der Drang auf, es lieber auf dem USB zu machen...

      Jetzt gibt es mehrere Wege zu einem Ergebnis zu kommen:
      Der einfachste wäre das 'Optifien' - man legt sich einen /opt-Ordner an und packt alles Eigene dort hinein - da der SPH (noch) recht viel Platz über hat, ginge das. In dem Fall müsste man aber immer noch für alles Schreibrechte für das rootfs einrichten und wenn es Probleme gibt hat man schlimmstenfalls einen SoftBrick...

      Für den Bootstrap gibt es natürlich auch mehrere Möglichkeiten:
      Eine wäre, beim Start alle notwendigen Dateinen nach /tmp zu kopieren und von dort in das System zu integrieren und gegebenenfalls zu starten. Bei kleinen Sachen ok, aber /tmp liegt im RAM des SPH und eignet sich deshalb wohl nicht für große Anpassungen. (mal von der Zeit für das Kopieren beim Routerstart abgesehen)
      Ein großer Vorteil dieser Variante allerdings: das Dateiformat des USB-Sticks ist egal.

      Der von mir gewählte Weg:
      Der USB-Stick wird auf einen Temp-Ordner gemountet, von dort wird der Boostrap-Unterordner auf /opt gebunden.
      (der Bootstrap-Ordner überlagert danach sozusagen den eigentlichen /opt-Ordner)

      Vorteile: kein Kopieren, der /opt-Ordner hat Schreibrechte, die Pfade sind einfach zu merken ;) (/opt, /opt/bin, etc)
      Nachteil: der USB-Stick muß zwingend ext3-Formatiert sein, wegen den Dateirechten. (notfalls eben einen 2. Stick nutzen)

      Das Schöne: ich hab' da mal was vorbereitet ;)

      Erstmal das Script:

      Shell-Script

      1. #!/bin/sh
      3. echo 'bootstrap gestartet...' > /tmp/bslog
      5. for i in 1 2 3 4 5 6 7 8 9 10 11 12
      6. do
      7. sleep 10
      8. echo "bootstrap mount Versuch $i..." >> /tmp/bslog
      9. bsbase="$(ls -d /mnt/*/_bootstrap_ 2>/dev/null)"
      10. if [ -n "$bsbase" ]
      11. then
      12. break
      13. fi
      14. done
      16. if [ -n "$bsbase" ]
      17. then
      18. bsinit="$(ls $bsbase/bootstrap_init.sh 2>/dev/null)"
      19. usbname="$(echo $bsbase | cut -d '/' -f 3 2>/dev/null)"
      20. usbdev="$(mount | grep $usbname | cut -d ' ' -f 1 2>/dev/null)"
      21. mkdir /tmp/bsmnt
      22. mount -o exec $usbdev /tmp/bsmnt
      23. mount -o bind /tmp/bsmnt/_bootstrap_ /opt
      24. echo 'mount durchgeführt...' >> /tmp/bslog
      25. if [ -n "$bsinit" ]
      26. then
      27. . /opt/bootstrap_init.sh
      28. echo 'bootstrap_init.sh ausgeführt...' >> /tmp/bslog
      29. else
      30. echo 'bootstrap_init.sh nicht gefunden...' >> /tmp/bslog
      31. fi
      32. else
      33. echo 'mountpoint nicht gefunden...' >> /tmp/bslog
      34. fi
      36. echo 'bootstrap beendet...' >> /tmp/bslog

      Zur Erklärung:

      Mein Script sucht beim Routerstart erstmal nach dem Ordner _bootstrap_ unterhalb des /mnt. Da der USB-Stick erst verzögert eingebunden wird, versucht es das bis zu 12 mal mit jeweis 10 Sekunden Pause dazwischen. (es sucht dabei den Ordner _bootstrap_ - und entscheidet danach, welcher USB-Stick richtig ist) --> bei mir ist meist der 5. Versuch erfolgreich...
      Wenn er einen _bootstrap_ gefunden hat, wird erst der Stick auf /tmp/bsmnt gemountet (um Ausführungsrechte zu setzen) und danach nur der _bootstrap_-Ordner nach /opt gebunden. Sollte in _bootstrap_ auch eine Datei bootstrap_init.sh sein, so wird diese ausgeführt. Das ganze wird übrigens in einem Logfile --> /tmp/bslog kommentiert ;)

      Da zu diesem Zeitpunkt das eigentliche Boostrapping schon erledigt ist, kann man sich in diesem Init-Script schon auf /opt beziehen - was das Scripten durchaus vereinfacht. (die USB-Mount-Pfade sind ja nervig lang...)
      Am Ende ist also _bootstrap_ == /opt && _bootstrap_/bin/ == /opt/bin/ und so weiter ;)

      Sollte beim Start kein bootstrap_init.sh gefunden werden, wird eben nur der Mount duchgeführt - findet es auch keinen _bootstrap_-Ordner, gibt's einen normalen Start. (bei Problemen beim Basteln reicht es also, den Router ohne Stick zu starten...)

      Damit das funktioniert sind nur 2-3 kleine Änderungen am SPH selbst notwendig:

      Zum einen brauchen wir die Ordner /opt und /opt/bin im rootfs des SPHs.
      (gibt da einen netten Post zum Thema Schreibrechte auf rootfs ;) )

      Und in /opt/bin das Bootstrap-Script. Ihr könnt einfach den opt-Ordner aus dem angehängten Zip nehmen ;)
      Wichtig ist bei dem Allem, daß ihr auf die Dateirechte achtet! der /opt inklusive Unterordner hat bei mir 777er Rechte. (später einschränken geht immer...)
      Aber ein chmod 0777 -R /opt schadet nicht wirklich...

      Nun kommt das Schwierigste:
      Wir müssen die Datei /etc/profile bearbeiten. Im oberen Bereich wird:

      Quellcode

      1. PATH=/bin:/sbin:/usr/bin:/usr/sbin
      2. export PATH

      zu

      Quellcode

      1. PATH=/bin:/sbin:/usr/bin:/usr/sbin:/opt/bin
      2. export PATH

      Wir fügen also :/opt/bin an die Zeile beginnend mit PATH an.

      Am Ende der Datei wird

      Quellcode

      1. tftpd -s /etc/tftpd &
      3. mic
      5. echo "Done"

      zu

      Quellcode

      1. tftpd -s /etc/tftpd &
      3. sh /opt/bin/bootstrap &
      5. mic
      7. echo "Done"

      Also ein sh /opt/bin/bootstrap & wird über mic eingefügt.

      Wichtig: nach dem Speichern die Dateirechte unbedingt wieder auf 770 setzen --> 'chmod 0770 /etc/profile'
      Das solltet ihr am besten per Terminal machen - FileZilla/Ftp hat da so seine Schwierigkeiten!

      Das waren schon alle notwendigen Änderungen ;)

      Ab jetzt reicht es dann, eine Executable in den Ordner _bootstrap_/bin des Sticks zu packen, schon ist sie in /opt/bin und damit im Pfad des SPH...
      Im Zip-Archiv ist auch mein _bootstrap_-Ordner zum Testen. Packt ihn auf einen ext3-Formatierten USB-Stick. (Dateirechte 777)
      Nach dem Neustart ist dann busybox-mips und sphfreq im Pfad und eine laufende sphfreq-WebUi unter speedport.ip:8080/cgi-bin/sphfrequi ;)
      (wird durch das bootscript_init.sh gestartet)

      Zusammengefasst:
      /opt aus dem Zip --> SPH-'/'
      _bootstrap_' aus dem Zip --> ext3-formatierter USB-Stick
      die beiden oben genannten Änderungen an /etc/profile
      chmod 0777 -R _bootstrap_ (auf dem Stick)
      chmod 0777 -R /opt (auf dem SPH-rootfs
      chmod 0770 /etc/profile

      Vor Allem die Dateirechte der /etc/profile besser 2-3x überprüfen vor dem Neustart! (sonst kann's echt Probleme geben)

      Übrigens: wenn ihr denkt, ihr müsstet etwas ändern, was von aussen nicht geht - zB. die Telekom-WebUI...
      ...ihr könnt euch auch ganze Ordner vom SPH auf den Stick kopieren - dort ändern - und dann eure Kopie per Mount-Bind im Init-Script über dem Original-Ordner auf dem SPH 'einblenden' --> dieser sieht dann eure Kopie ;)

      mfg, emkay

      PS.: das das Script eventuell für Manche seltsam aussieht, liegt wohl daran, daß der SPH recht eingeschränkt ist beim Scripten - und ich mich vorher selten mit Shellscripting befasst habe ;)

      EDIT: wenn ihr meinen _bootstrap_-Ordner nutzt/testet: bitte noch in den httpd.conf eventuell die Beschränkung auf IP 192.168.2.* anpassen... könnte ja sein, daß ihr einen anderen IP-Bereich benutzt ;)
      Dateien

      • bootstrap_daten.zip

        (692,05 kB, 1.558 mal heruntergeladen, zuletzt: )

      Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „Stricted“ ()

      @Stricted: jupp - Executables nach _bootstrap_/bin/ -- startscript von bootstrap_init.sh starten lassen und für Log-Files einfach ein _bootstrap_/var/ anlegen (wird zu /opt/var) -- erleichtert die Sache ungemein...

      EDIT: der einzige Nachteil, den man im Kopf behalten muß ist, daß es nach dem Start rund 50Sek. (mein System&Stick) dauert, bis das bootstrap_init.sh aufgerufen wird.

      Moin,

      nach nun nun ein paar Wochen mit Bootstrap ist heute etwas passiert das ich noch nicht ganz blicke.. Urplötzlich hat der Speedport den Dailyreboot nicht überlebt und scheint irgendwie zu hängen. Ich gehe stark davon aus irgendwo etwas kaputt gemacht zu haben, allerdings habe ich kein Plan wie ich den guten überhaupt erstmal wieder aus laufen kriegen - gibt's nen auto Firmware Update per USB, dass er beim bot macht?
      Die Lanports sind jedenfalls tot, ds/lte kommen auch nicht :)

      Ich hab nun mehrere Powercycles durchlaufen... Am Ende leuchtet nur die PowerLED - er scheint irgendwo haengen zu bleiben, mein eigentliches Vorhaben, vnStat ins Boostrap zu packen war die letzte Aktion die ich gemacht hatte - ich gehe davon aus, dass ich irgendwo Dateirechte verbogen habe ohne es zu merken, die /etc/profile war zuletzt auf 770 und daher habe ich mir keine sorgen gemacht.

      Der Bootstrap stick scheint auch in Ordnung.

      @shell Wenn Du beim Einschalten den Reset-Knopf gedrückt hälst...und dann nach 5 Sekunden losläßt, sollte es möchtlich sein, von einem PC, der per LAN angeschlossen ist und z.B. die 192.168.2.2 hat ....dann per HTTP auf 192.168.2.1 zugreifen zu können. Dort kannste dann die Firmware einspielen. ...die Einstellungeen bleibenerhalten. ...dein Bootstrap ist dann erstmal wech. ..aber kommst ohne Probleme per telnet wieder rein.

      Schon mal probiert?

      Grüße

      danXde

      Moin Leutz!

      Also @shell... vorausgesetzt der Bootstrap ist geglückt (Rechte von profile und /opt/bin passen und /opt/bin/bootstrap ist in Ordnung) - sollte der Router eigentlich bei Problemen einfach durch Abziehen des USB-Sticks reaktiviert werden können.
      (ohne den Stick läuft der Bootstrap ins Leere und wird übersprungen)

      Wenn Du allerdings noch an anderen Dateien direkt im RootFS geschraubt hast - da muß man schon vorsichtig sein. Allerdings sollte es selbst dort schwer sein, den Notfall-Bootloader zu killen. (solange man keinen anderen, als den /dev/mtdblock0 mit Schreibrechten mountet und zur Sicherheit einen unmount durchführt vor dem reboot, damit eventuelle Schreibpuffer geleert werden...)
      ==> und der Reset-Button sollte eigentlich immer funktionieren.

      Was ich persönlich als gefährlich einstufe, ist jede Art von Zeitschaltuhr am SPH - wenn die einmal im falschen Moment die Stromversorgung unterbricht, ist Sense... :D
      (da seh' ich immer noch die wahrscheinlichste Ursache für @hefr54s SPH-Kill...)

      Ich selbst habe ja so ziemlich alle möglichen Erweiterungen laufen - allerdings ohne dabei zu viel am eigentlichen RootFS verändert zu haben. (nur Bootstrap und xdslcmd - für den SNRM und ich hab' ne /etc/hosts angelegt wegen NSS)
      Die CPU macht das auch alles ganz brav und ohne größere Belastung mit - und brennt auch bei Vollast (Multithreaded-Compiler-Lauf mit gcc im chroot... :D ) nicht gleich durch.

      Naja - wenn Du den Austausch schon eingeleitet hast, ist dein Problem ja schon fast gelöst... sonst hätte ich auch nochmal auf den Notfallmodus verwiesen. Den zu killen sollte wirklich schwer sein ;)

      mfg, emkay

      Ich frag' mich allerdings schon, ob's da nich 'nen Serienfehler gibt...
      Sind schon zwei Tote hier im Forum - und hier und da liest man Ähnliches auch an anderer Stelle.
      Wie gesagt - meiner läuft (noch) stabil. Trotz teils hoher Belastung bei recht hoher (24-27°) Umgebungstemperatur.
      (vielleicht sollte ich doch mal die Temperaturfühler mit-loggen...)

      mfg, emkay

      EDIT: @hefr54: statt ZSU besser cronjob/reboot - das ist sauberer...

      @hefr54: Temperatur-Messung sollte per AT-Kommando gehen - Huaweis können das normalerweise. (in der AT-API war glaub ich was)

      Bezüglich der 'Lichtorgel': Poti und fertig :D
      Sonst geht das wohl nur per API - schätze in der Broadcom-Hardware-Abstraction-Lib...
      (mann könnt eventuell mal nen Trace machen, während man die LED-Änderung erzwingt - dann sieht man vielleicht, ob's nen CLI-Zugriff gibt)

      mfg, emkay