Sie sind nicht angemeldet.

Anzeigen

**Wir werden in den kommenden Tagen einen Umzug auf einen neuen Server durchführen. Im Rahmen dieser Maßnahme wird das Forum ca. 1 Stunde nicht erreichbar sein.** nslu2-info.de ist ein privates Projekt von mir, welches jeden Monat aus eigener Tasche finanziert wird. Mit einer freiwilligen Spende wird der Erhalt und der weitere Ausbau dieses Forums unterstützt. Um mich beim Erhalt des Forums zu unterstützen, kannst Du entweder via Flattr oder Paypal spenden. Ich bedanke mich schon jetzt bei allen Unterstützern.

Lieber Besucher, herzlich willkommen bei: Die NSLU2 Community****wenns ums speichern und streamen geht****. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.

foogy

Anfänger

  • »foogy« ist der Autor dieses Themas

Beiträge: 31

Firmwareversion / your current Firmware: Debian

  • Nachricht senden

1

Samstag, 17. Januar 2009, 08:20

Bootvorgang hängt: sh /etc/rc.D

Moin,
gestern habe ich nach 13 Tagen meine Slug nochmal runtergefahren. Jetzt bootet sie nicht mehr richtig durch. Zum Glück hatte ich vor einer Weile dafür gesorgt, dass der SSH-Serve und das Netzwerk schon sehr früh gestartet werden, daher komme ich zumindest noch an eine Shell.

Ein htop gibt mir dann folgende, kurze Liste:

Quellcode

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
  CPU[#*                                3.2%]     Tasks: 14 total, 1 running
  Mem[||||||||||||||###**************10/28MB]     Load average: 0.26 0.12 0.08 
  Swp[                               0/196MB]     Uptime: 00:12:28

  PID USER     PRI  NI  VIRT   RES   SHR S CPU% MEM%   TIME+  Command                           
 1440 root      20   0  2764  1164   952 R  3.9  3.9  0:01.99 htop
 1416 foogy     20   0  8548  1720  1260 S  0.0  5.8  0:00.57 sshd: foogy@pts/1
    1 root      20   0  2040   668   584 S  0.0  2.3  0:05.98 init boot
  712 root      20   0  2040   248   164 S  0.0  0.8  0:00.01 init boot
  713 root      20   0  2984  1504  1144 S  0.0  5.1  0:00.53 /bin/sh /etc/init.d/rc S
  792 root      16  -4  2944  1548   524 S  0.0  5.2  0:02.98 udevd --daemon
 1137 root      20   0  1704   516   432 S  0.0  1.7  0:00.04 /sbin/bootlogd -r -c
 1375 root      20   0  5532  1304   952 S  0.0  4.4  0:00.02 /usr/sbin/sshd
 1385 root      20   0  2972  1460  1112 S  0.0  4.9  0:00.25 sh /etc/rcS.d/S30checkfs.sh start 
 1413 root      20   0  2344   800   672 S  0.0  2.7  0:00.03 sulogin /dev/console
 1414 root      20   0  8548  2556  2100 S  0.0  8.7  0:00.33 sshd: foogy [priv]
 1417 foogy     20   0  4392  2852  1320 S  0.0  9.7  0:02.22 -bash
 1436 root      20   0  2720  1092   888 S  0.0  3.7  0:00.10 su
 1437 root      20   0  2976  1656  1284 S  0.0  5.6  0:00.13 bash
Auffällig finde ich den Eintrag "sh /etc/rcS.d/S30checkfs.sh start". Das scheint mir das gerade laufende (oder eben stecken gebliebene) Script zu sein. Macht ja Sinn, denn "/bin/sh /etc/init.d/rc S" hat es wohl gestartet.

Aber es tut sich nichts. Da kann ich noch so lange warten. Ich habe jetzt gerade den Prozess mal gekillt, dann bootet sie weiter.

Weiß jemand, wie ich hier weiter nach der Ursache suchen kann? Ich kenne mich im Debian Bootprozess leider nicht sonderlich aus.

Vielleicht noch folgendes: ich hatte die Slug runtergefahren, um das Netzteil zu tauschen. Habe mir ein Universalnetzteil bestellt, da das andere nur geliehen ist. Beim booten mit diesem Netzteil trat das Symptom dann erstmalig auf. Da dachte ich schon, es liegt am Netzteil. Also wieder runtergefahren, Originalnetzteil dran. Aber gleiches Phänomen. Daher kann ich das neue Netzteil als Ursache wohl ausschließen. Habe es auch vorher mit dem Meßgerät überprüft. Wollt es nur erwähnt haben.

Achso, es handelt sich um ein Debian Lenny, Kernel 2.6.26-1-ixp4xx
Update: Ok, sie bootet nach dem kill zwar durch, aber ist unerträglich langsam. Die Seite von CUPS baut sich quasi gar nicht vollständig auf bzw. erst nach einigen Minuten. Laut htop langweilt sich die Slug aber währenddessen.

Update2: in /var/log/boot hätte ich natürlich auch vorher mal reinschauen können. Dort wurde gemeldet, dass zwei Partitionen, die ich mit UUID in der fstab stehen habe, nicht identifiziert werden konnten. Naja ist ja auch klar, die Platte ist ja auch nicht eingeschaltet. Aber es kann doch nicht sein, dass fsck das System blockt, wenn ein Device gar nicht da ist. Was mich noch wundert: ich habe ein beep-Script, das nach dem Hochfahren ausgeführt wird. Seitdem die Slug nun wieder bootet, dann folgt wenigen Sekunden nach dem beep-Script noch ein dreimaliges Piepen. Allerdings frage ich mich wo das herkommt. War vorher nicht da. Kommt das nun aus Debian oder von der Hardware?

Danke und viele Grüße,
Andreas

Anzeigen

foogy

Anfänger

  • »foogy« ist der Autor dieses Themas

Beiträge: 31

Firmwareversion / your current Firmware: Debian

  • Nachricht senden

2

Samstag, 17. Januar 2009, 14:13

AW: Bootvorgang hängt: sh /etc/rc.D

Hat sich erledigt und hatte NICHTS mit dem Netzteil zu tun. Eigentlich zu peinlich, um weiter drüber zu reden. Trotzdem kann ich nur jedem empfehlen, die SSH-Verbindung so weit vor wie nur möglich zu schieben. Oder gleich ne serielle Schnittstelle anbauen. Sonst würde ich wohl noch jetzt suchen.

Anzeigen

konkretor

Anfänger

Beiträge: 3

Firmwareversion / your current Firmware: originale Firmware 2.3r24

  • Nachricht senden

3

Sonntag, 25. Januar 2009, 15:09

AW: Bootvorgang hängt: sh /etc/rc.D

interessant wäre doch, was es jetzt genau war

foogy

Anfänger

  • »foogy« ist der Autor dieses Themas

Beiträge: 31

Firmwareversion / your current Firmware: Debian

  • Nachricht senden

4

Sonntag, 25. Januar 2009, 15:29

AW: Bootvorgang hängt: sh /etc/rc.D

Nur ein winziges Detail: habe meinen Router getauscht und vergessen, der Slug zu sagen, dass das Gateway nun eine andere IP hat.
Zumindest lief sie wieder, nachdem ich drauf gekommen bin und das korrigiert hatte. Ans Neztwerk hatte ich aber zunächst nicht Gedacht, da ich ja per SSH draufgekommen bin. Aber kein wunder, Subnet und IP der Slug blieben ja unverändert.

Social Bookmarks