RaspberryPi + ipfire: abhilfe für zu schnelles booten gesucht

Re(12): RaspberryPi + ipfire: abhilfe für zu schnelles booten gesucht

colo — Tue, 13 Aug 2013 06:57:04 GMT

Ein beherztes sleep 30 als pre-up-Script fuer die Schnittstelle in der /etc/network/interfaces (siehe man 5 interfaces) sollte das eigentlich ohne viel Frickelei regeln koennen.

Eleganter und richtiger waere natuerlich ein pre-up-Script das erst dann returned, wenn das Modem einen vielversprechenden Status liefert, z. B. durch eine Abfrage via AT-Commands.

Re(11): RaspberryPi + ipfire: abhilfe für zu schnelles booten gesucht

user86060 — Sun, 11 Aug 2013 11:56:40 GMT

Ist in diesen /etc/init.d/-Scripts immer dasselbe Spielchen / derselbe Aufbau:

ein paar (je nach Bedarf) Funktionen zur Ergänzung und immer ein start) (bei Verwendung als S*-Symlink) + stop) (bei K-Symlink) Block ....

Dein Problem ist offenbar, daß das notwendige Netzwerkdevice irgendwo zw. Module-Loading und udev angelegt wird und die Verzögerung im network-Script schon zu spät ist.

Ich kram einmal mein E220 heraus und schau mir das näher an...

Re(10): RaspberryPi + ipfire: abhilfe für zu schnelles booten gesucht

Thunder — Sun, 11 Aug 2013 11:47:15 GMT

thx, ich werd mich mal dran machen um

/etc/rcS.d/S07kmod = /etc/init.d/kmod probieren

zu verstehen, wenn ich wieder zeit hab. das ergebnis post ich auf jeden fall

Re(9): RaspberryPi + ipfire: abhilfe für zu schnelles booten gesucht

user86060 — Sun, 11 Aug 2013 10:42:24 GMT

zu früh gefreut, ich muss den rasp schon "weiter oben" stoppen, beim interface
zuweisen ist es anscheinend zu spät

Re(9): RaspberryPi + ipfire: abhilfe für zu schnelles booten gesucht

user86060 — Sun, 11 Aug 2013 10:42:24 GMT

zu früh gefreut, ich muss den rasp schon "weiter oben" stoppen, beim interface
zuweisen ist es anscheinend zu spät

dann würd ich es in /etc/rcS.d/S07kmod = /etc/init.d/kmod probieren (je kleiner die Zahl nach "S" ("S"tart) im Symlink, desto früher kommt das Script dran = implizite Sortierung/Reihenfolge über den Filenamen, detto bei K / beim Runterfahren ("k"illen) des jeweiligen Runlevels)

Eventuell hilft es auch, die notwendigen Module für das USB-Teil in die /etc/modules einzutragen, falls deren Initialisierung klug genug ist, den Startup ihrer Klienten abzuwarten - hab ich aber noch nie untersucht (weil man das Problem auf Standgeräten nicht hat) ... aber falls ich einen launigen Nachmittag hab, erfährst du's als Erster

Re(8): RaspberryPi + ipfire: abhilfe für zu schnelles booten gesucht

Thunder — Sun, 11 Aug 2013 10:29:42 GMT

zu früh gefreut, ich muss den rasp schon "weiter oben" stoppen, beim interface zuweisen ist es anscheinend zu spät also die pause müsste kommen, bevor er auf die idee kommt, nach usb devices zu suchen.

Abfrage + Abbruchbedingung

bahnhof dort, wo grad die pause eingebaut ist, wir sowohl beim interface zuordnen als auch entfernen (vor einem restart) eine pause gemacht. war zu faul, die richtige if schleife zu suchen... ist aber durch die neue erkenntnis eh hinfällig.

Re(7): RaspberryPi + ipfire: abhilfe für zu schnelles booten gesucht

user86060 — Sat, 10 Aug 2013 13:50:45 GMT

das einfache sleep war mir dann zu langweilig

für eine Abfrage + Abbruchbedingung, die berücksichtigt, wann zB lsusb oder lsmod einen passenden return liefert hattest dann aber doch keine Lust

Re(6): RaspberryPi + ipfire: abhilfe für zu schnelles booten gesucht

Thunder — Fri, 09 Aug 2013 21:25:55 GMT

hab ein wenig herumprobiert und in /etc/init.d/networking anscheinend das startscript fürs rote interface gefunden (in meinem fall ist das fürs modem zuständig). irgendwo kurz nach dem beginn das sleep eingefügt und den ersten erfolg gehabt

das einfache sleep war mir dann zu langweilig ->

for (( i=30; i>0; i--)); do
  sleep 1 &
  printf "  $i \r"
  wait
done

ob das ganze nun elegant ist und in der "richtigen" datei ist mir egal - es funktioniert mal und morgen test ich das ganze am rasp thx nochmal

Re(5): RaspberryPi + ipfire: abhilfe für zu schnelles booten gesucht

user86060 — Fri, 02 Aug 2013 11:07:56 GMT

man könnt eine usb zeitschaltuhr dazwischenhängen

das Script für die Initialisierung von USB oder GSM/UMTS sollte wohl zu finden sein, bzw. zB /etc/init.d/ifplugd ist IMHO ein heißer Kandidat für ein Timeout (am Anfang des "start)"-Blocks)

Re(4): RaspberryPi + ipfire: abhilfe für zu schnelles booten gesucht

Thunder — Fri, 02 Aug 2013 10:54:04 GMT

in /etc/init.d/networking o.ä. ... /etc/rc.local ist wahrscheinlich zu spät -
müßt ich erst schauen

werd mir mal ipfire in der vm installieren und probieren, der rasp steht nämlich ein paar km weit weg... ipfire ist ähnlich dem (was ich so gelesen hab, angestaubten) ipcop. ipcop hatte mit einem neuern huawei ein bissl probleme (bzw kanns auch an mir gelegen haben ) und ARM unterstützung gibts glaub ich auch keine.

Stromverbrauch eines USB-Hubs = vernachlässigbar

ich kenn aktive hubs, die man besser mit der grillzange angreifen sollte. gibt wohl solche und solche.

aber vom Ablauf betrachtet würde das dein Problem nicht lösen

man könnt eine usb zeitschaltuhr dazwischenhängen

Re(3): RaspberryPi + ipfire: abhilfe für zu schnelles booten gesucht

user86060 — Fri, 02 Aug 2013 10:47:34 GMT

hab an den eintrag von ein paar zeilen in einer datei oder einem script
gedacht, vielleicht stell ich mirs auch mangels linuxkenntnissen zu leicht
vor.

ah so ... natürlich ... kenn ipfire nicht konkret, aber "sleep 10" (für zB 10 Sekunden) sollte im Startscript / jedem Shellscript am Weg dorthin funktionieren (in /etc/init.d/networking o.ä. ... /etc/rc.local ist wahrscheinlich zu spät - müßt ich erst schauen)

möglich aber auch wieder nicht. vermutlich braucht der powered hub mehr strom
als modem und rasp zusammen

Stromverbrauch eines USB-Hubs = vernachlässigbar. Soll auch USB-Power-Netzteile mit 2 Ausgängen geben (aber vom Ablauf betrachtet würde das dein Problem nicht lösen)

Re(2): RaspberryPi + ipfire: abhilfe für zu schnelles booten gesucht

Thunder — Fri, 02 Aug 2013 10:39:27 GMT

ergänzend dazu: ich bin froh, dass ipfire dank img und automatischer modemerkennung nach dem eintragen einiger weniger dinge (dns, dhcp) rennt, das wars dann auch schon wieder mit meinen linuxkenntnissen. hab an den eintrag von ein paar zeilen in einer datei oder einem script gedacht, vielleicht stell ich mirs auch mangels linuxkenntnissen zu leicht vor.

self-powered USB-Hub betreiben

möglich aber auch wieder nicht. vermutlich braucht der powered hub mehr strom als modem und rasp zusammen wieder ein kistl mehr, stecker ist auch nur einer dort -> zusätzliche steckdosenleiste notwendig...

Re: RaspberryPi + ipfire: abhilfe für zu schnelles booten gesucht

user86060 — Fri, 02 Aug 2013 10:22:06 GMT

berryboot (das multiboot-Utility) hat ein Timeout für die Auswahl drin - das sollte reichen?

PS: anderer Ansatz: das Modem über einen self-powered USB-Hub betreiben?

Re: RaspberryPi + ipfire: abhilfe für zu schnelles booten gesucht

user86060 — Fri, 02 Aug 2013 10:22:06 GMT

berryboot (das multiboot-Utility) hat ein Timeout für die Auswahl drin - das sollte reichen?

RaspberryPi + ipfire: abhilfe für zu schnelles booten gesucht

Thunder — Fri, 02 Aug 2013 10:01:41 GMT

wie im betreff schon steht, hab ich einen rasp in verwendung, auf der ausschließlich zum bereitstellen eines 3g-internetzuganges per rj45 dient. einen kleinen schönheitsfehler hat die sache allerdings: wenn man ihn einschaltet = anstecken, dann bootet das ganze graffel so schnell, dass das usb modem noch nicht bereit ist. abhilfe schafft nur ein neustart ohne ihn komplett abzustecken, da das modem dann weiterhin strom hat. ich brauch also entweder eine stupide verzögerung von zb 30sek vor dem zeitpunkt, wo das modem gesucht (bzw für ipfire/ipcop kenner das rote interface konfiguriert) wird. wenns genauso leicht geht, kann durchaus auch eine intelligenz dahinter sein: warte so lange bis das internet da ist oder was weiß ich. hat wer einen sinnvollen ansatz? meine suche hat bis jetzt eher das gegenteil gebracht