Fehlerhafte EXT2-Partitionen auf dem USB-Stick führen zum reboot

hermann72pb · 11 Sep 2009

Seit gestern hatte ich plötzlich festgestellt, dass meine Box angefangen hat sich zu rebooten. Was der Auslöser dafür war, weiß ich nicht, die Ursache für Reboots lag aber eindeutig an dem USB-Stcik. Nachdem ich USB-Stick abgezogen hatte, konnte die Box sich in eine "stabile Seitenlage" hochfahren.
Nun kommt die Frage, was habe ich denn alles auf dem Stick, dass es die Box dazu gebracht hat sich ständig zu rebooten? Zunächst mal zu Partitionen. Es ist eine 8GB-USB Stick mit 4 Primärpartitionen. Erste und dritte sind EXT2, zweite ist FAT16, vierte ist LINUX-SWAP. Swap-Partition ist eingebunden. Auf der sda1 liegen meine externalisierten Binaries. Dorthin logt auch mein syslog. Der wird auch relativ schnell gefüllt, weil viele Kiddies meine Box auf Ports 21 und 22 torpedieren. Aber eigentlich macht syslog eine rotation zwischen mehreren Dateien, sodass ich dort eher keine Probleme sehe.
Was ich letztens paar mal verbrochen hatte: Ich hatte etwa 10 Mal die Box upgedatet, ohne dass ich die Dienste runtergefahren hatte (aus Faulheit) und lies mein SWAP dadurch auf etwa 5-7 MB von seinen 256MB "hochlaufen". Ob dies das Problem sein könnte, weiß ich nicht.
Nun zum fsck. Natürlich hatte ich mein Stick heute durch fsck unter freetz-linux laufen lassen. Auf sda1 gab es sehr viele Fehler in inodes usw. fsck hatte sie aber relativ schnell beseitigt. Mit sda3 kämpfe ich immer noch und verstehe das gar nicht. Dort liegen eigentlich nur ein Paar Daten von mir. Partition war nie aktiv und intensiv benutzt. SWAP teste ich demnächst.

Fragen sind Folgende:
1. Früher war es doch so, dass wenn die Partition nicht sauber ist, dann wurde sie auf der Box nicht gemounted. Ist es mittlerweile nicht so?
2. Kann man / wäre es sinnvoll regelmässige fsck auf der Box per crond z.B. nachts laufen zu lassen? Selbstverständlich erstmal alles herunterfahren und dann wieder starten. Und auch nicht jeden Tag, sondern z.B. einmal pro Woche/Monat? Oder spricht was grundsätzliches dagegen?
3. Kann man wenigstens die SWAP-Partition vor dem einbinden als SWAP durchcheken? Wäre es sinnvoll?

MfG

Silent-Tears · 11 Sep 2009

Swap zu testen ist ziemlich sinnfrei, denn das ist ein raw-format. Da sind keine inodes opder sonst etwas drin, die man prüfen könnte.

Deine Box wird übrigens rebooten, wenn es Probleme beim Öffnen/schreiben irgendwelcher Filehandles gibt, das ist ein recht normales Verhalten insgesamt, da du ja anscheinend essentielle Sache nausgelagert hast per external.
Dazu hast du kontinuierlichen Schreibzugriff auf deine ext2-P?artition durchs syslog. Wieso siehst d da kein Problem? syslog schreibt, und schreibt und schreibt an diversen Stellen, egal wie dieses File heisst. Somit hast du ständige Schreibzugriffe auf deine Logfiles.

Das mit dem "10 mal updaten" musst du erklären, denn normalerweise ist der swap - eine Erweiterung des RAM - nach einem Reboot wieder geleert, oder aber wenn das entsprechende Binary aus dem tmpfs gelöscht wurde. Und bei einem Update wird alles normalerweise überschrieben, btzw. der Inhalt des tmpfs neu angelegt. Somit hast du wahrscheinlich prinzipiell 1 Image im RAM, und dies nutzt - wohl auf deiner 7170 oder anderen "kleinen" Boxen - den Swapbereich mit.

Ich würd dir erstmal vorschlagen, nicht per cron oder ähnlicher Tricksereien nicht mehr ext2, sondern ext3 zu nutzen, denn dies ist eindeutig Fehlerunanfälliger. Ein bisschen weniger Performant, aber das ist gar nicht nötig bei den paar Daten. Weiterhin sollte man gucken, ob man vllt. was am "commit-interval" der PArtitionen ändert, denn per Default wird alle 60 Sekunden was auf die "Platte" geschrieben. Nicht so der Hit

Als Idee, um deine Logfiles nicht stänmdig shcreibne zu lassen, könntest du evtl auch ein wenig Scripten, und das aktuelle im RAM speichern, und alle X 'Minuten per Cron auf den Stick zu schreiben oder so. Ich weiss nicht, ob vllt. auch der syslogd der BB einen Speicherort der altne Logs beim Rotate zulässt, auch da sollte man vllt mal gucken.

hermann72pb · 11 Sep 2009

Ok danke für Hinweise. Hab inzwischen selbst rausgefunden, dass man SWAP-Partition nur schwer überprüfen kann. Es gibt lediglich die Möglichkeit:

Code:

mkswap -c /dev/sda4

- vor dem anlegen den Platz zu checken, oder was da auch immer dabei durchgeführt wird. Die Frage ist: Wird bei uns in FREETZ "mkswap" beim hochfahren ausgeführt oder direkt und gleich "swapon /dev/sda4" ? Macht es überhaupt Sinn? Auf dem PC ging es eigentlich recht fix mkswap für 256MB auf einem Stick.

Zu den 10 Mal war gemeint, dass ich insgesamt 10 mal auf diese Weise upgedatet hatte. Früher hatte ich kein SWAP und müsste vor dem Update alle "großen" Dienste (wie z.B. SAMBA) runterfahren, damit mir bei meiner 7170 Platz im RAM zum Updaten reicht. Die letzten 10 Male hatte ich die Dienste nicht runtergefahren, sondern SWAP hochlaufen lassen. Dadurch war ein Teil vom zu flashenden Image anscheinend im SWAP drin. Denn ich hatte gesehen, dass die SWAP-Größe gewachsen war. Meine Sorge diesbezüglich war, dass Update-Skript eigentlich denkt, er würde aus dem RAM die Image-Inhalte kopieren und möglicherweise wird nach dem Update nicht alles sauber runtergefahren (z.B. SWAP).

Übrigens das Einstecken von meinem reparierten Stick bringt die Box wieder zum Abstürz. Ich muss da ganz genau reinschauen. Ich hatte da noch autostart.sh und autoend.sh für vsftp-Benutzerprofil am Laufen. Das ist das Einzige, was beim Einstecken da ausgeführt wird. Und diesmal hatte ich ja nur USB-Stick eingesteckt, worauf die Box sich irgendwann mal verabschiedete.

MfG

linuxkasten · 11 Sep 2009

Andere Frage: Brauchst du wirklich 256 MB swap?
Ich hatte bei meiner 3170 auch mal 64 MB, aber letztendlich war es bei mir (trotz diverser Daemons) Platzverschwendung, und so hab ich ihn mitllerweile auf 16 MB verkleinert, und zwar als Swapfile statt einer Partition.....Die Box braucht bei mir selten mehr als 4 mb.
Naja, vielleicht hast du einfach mehr am laufen

Silent-Tears · 11 Sep 2009

Eine Swappartition ist noch ein Stückchen schneller als ein Swapfile, einfach weil das nicht per Loopdevice gemountet wird, sondern als swap wie unterjedem Linux auch.

@herman: Ein "mkswap" bei jedem Botten zu veranstalten ist reichlich unnütz und macht noch mehr sinnfreie Schreibzugriffe auf deinem Stick.

Ein serielles Log wäre übrigens von Interesse beim Einstecken des Sticks, denn so ist es nur Rätselraten. Ich rate mal einfach, dass in deiner autorun.sh irgendwas untergebracht ist, was eigentlich auch Sachen von dem Stick braucht, somit dass du vsftpd externalisiert hast, und sich da irgendwas beisst. AbeR: Da musst du aufklären, sonst gibt es nur ein Ratespiel.

Was deine Beobachtung beim Flashen angeht, so ist es ganz normal, dass der SPeicher der Boxc eben um XMB mehr belastet wird, denn wes wird ja auch ein XMB-File in den Speicher geladen, der eigentlich ja beinahe "voll" ist. Durch den Swapspace allerdings hat dein kernel mehr Speicher zur Verfügung, und nutzt den Swpa eben auch. Logisch, ne? Und nach einem Neustart - auch nach "swapoff && swapon" ist alles wieder ausgeswapped und geht von vorne los. Da ist also kein Handlungsbedarf.
Zur Swapgrösse: Ich habe auf meiner 7170 32MB swap, auf der 7240 64MB swap, beides als Partitionen, und bei keiner der beiden wurde je die Maximalgrenze auch nur nahezu erreicht. Genutzt wird der KRam auf der 7240 gar nicht, weil die einfach genug RAM hat, und auf der 7170 wurde eldiglich beim Flashen irgendwas daovn genutzt.

hermann72pb · 11 Sep 2009

Auf der Partition mit den meisten Fehlern lag mein Userprofil für vsftp. Dort lagen auch start/stop-Skripte mit "mount -o bind" für shared folders aus dem Beispiel aus WIKI. Jetzt hab ich alle start-stop-Skripte umbenannt und.... die Box rebootet trotzdem.
Ich werde gleich SWAP deaktivieren. Mehr fällt mir da nicht mehr ein, was den Reboot beim einstecken auslösen könnte.

MfG

Silent-Tears · 11 Sep 2009

Du könntest noch alternativ den Stick formatieren und die Sachen wieder draufkopieren und gucken, was dann passiert.

hermann72pb · 11 Sep 2009

Ich bin langsam voll am Verzweifeln und werde es demnächst wohl genau so tun. Mittlerweile hab ich wirklich ALLES deaktiviert, was in irgendeiner Art und Weise was mit dem Stick zu tun hat. Die Box rebootet trotzdem. Mittlerweile habe ich Zweifel an meiner /dev/sda2 als 2GB-FAT16. Dort liegen bekannterweise Anrufbeantworter. Ich habe leider keine serielle Konsole. Aus dem letzten "top" lese ich Folgendes heraus:

Code:

Mem: 28248K used, 1980K free, 0K shrd, 1120K buff, 8896K cached
CPU:   1% usr   1% sys   0% nice  97% idle   0% io   0% irq   0% softirq
Load average: 0.71 0.30 0.16
  PID  PPID USER     STAT   VSZ %MEM %CPU COMMAND
 1313  1278 root     R     1428   5%   2% top
 1277  1179 root     S     1484   5%   1% dropbear -p 22 -R
  526     1 root     S N   8704  29%   0% ctlmgr
  547   546 root     R N   8704  29%   0% ctlmgr
  548   546 root     S N   8704  29%   0% ctlmgr
  546   526 root     S N   8704  29%   0% ctlmgr
  550   546 root     S N   8704  29%   0% ctlmgr
  549   546 root     S N   8704  29%   0% ctlmgr
  668     1 root     S <   4840  16%   0% voipd
  584     1 root     S     4828  16%   0% upnpd
  719   717 root     S     4828  16%   0% upnpd
  718   717 root     S     4828  16%   0% upnpd
  717   584 root     S     4828  16%   0% upnpd
 1744  1689 ftpuser  S N   3564  12%   0% smbd -D -s /mod/etc/smb.conf
  653     1 root     S     3540  12%   0% dsld -i -n
 1689     1 root     S N   3276  11%   0% smbd -D -s /mod/etc/smb.conf
  673     1 root     S     3168  10%   0% pbd
  680   674 root     S     3168  10%   0% pbd
  679   674 root     S     3168  10%   0% pbd
  674   673 root     S     3168  10%   0% pbd
  635     1 root     S     3016  10%   0% multid
  697     1 root     S     2840   9%   0% /usr/bin/faxd -a
 1273     1 root     S     2508   8%   0% nmbd -D -s /mod/etc/smb.conf
  544     1 root     R     2224   7%   0% wpa_authenticator
  685   526 root     S     1888   6%   0% capiotcp_server -p5031 -m99
 1076     1 root     S     1764   6%   0% /bin/ash /usr/sbin/callmonitor
 1410     1 root     S N   1652   5%   0% /bin/sh /etc/hotplug/storage add 002 /proc/bus/usb/001/002 1307 0165 1
 1411  1410 root     S N   1640   5%   0% /bin/sh /etc/hotplug/run_mount 002 /proc/bus/usb/001/002 sda
 1077  1076 root     S     1612   5%   0% logger -t callmonitor -p daemon.info
  796     1 root     S     1612   5%   0% httpd -P /var/run/webcfg.pid -p 81 -c /mod/etc/httpd.conf -h /usr/mww/ -r Freetz
 1206     1 root     S     1612   5%   0% httpd -P /var/run/webcfg-wol.pid -p 82 -c /mod/etc/httpd-wol.conf -h /mod/pkg/wol/usr/mww-wol/ -
  825     1 root     S     1608   5%   0% syslogd -L -O /var/log/syslog -b 5 -s 100
  663     1 root     S     1604   5%   0% telnetd -l /sbin/ar7login
 1278  1277 root     S     1440   5%   0% -sh
    1     0 root     S     1428   5%   0% init
 1179     1 root     S     1428   5%   0% dropbear -p 22 -R
 1276     1 root     S     1428   5%   0% init
  629     1 nobody   S     1236   4%   0% dnsmasq --pid-file=/var/run/dnsmasq/dnsmasq.pid -p 53
  690     1 root     S     1108   4%   0% /bin/run_clock -c /dev/tffs -d
  434     5 root     SW<      0   0%   0% [capi_oslib]
   70     1 root     SW       0   0%   0% [mtdblockd]
  700     1 root     RWN      0   0%   0% [kdsld_token]
    2     1 root     SWN      0   0%   0% [ksoftirqd/0]
 1359     1 root     SWN      0   0%   0% [usb-storage]
   25     1 root     SW       0   0%   0% [kswapd0]
   62     1 root     SW       0   0%   0% [pm_info]
    4     1 root     SW<      0   0%   0% [khelper]
    5     1 root     SW<      0   0%   0% [kthread]
    3     1 root     SW<      0   0%   0% [events/0]
  435     1 root     SW       0   0%   0% [capitransp]

Es rebootet also irgendwo mitten beim mounten drin. Und ich merke, dass während dieser Phase smbd und nmbd voll zugange sind. Ich sehe da sogar ein smbd von "ftpuser".
Die FAT-Partition lässt sich irgendwie unter meinem Vista nicht mounten. Unter freetz-linux konnte ich fsck für dos überreden die Partition zu checken. Irgendwas wurde dort sogar korrigiert. Scheint aber dennoch nicht zu fruchten.
Ich gebe also für heute auf und werde mal die Tage wieder versuchen dem Problem auf den Grund zu gehen. Es ist aber irgendwie schon ein seltsames Verhalten. Eigentlich darf die Box davon nicht rebooten, dass die Partitionen auf dem USB-Stick nicht "sauber" sind.

MfG

RalfFriedl · 11 Sep 2009

Was siehst Du mit smbd und nmbd? Beide haben in dem Bild 0% CPU.

Wenn Deine FAT-Partition nicht mehr in Ordnung ist, dann kopier doch mal alles, was noch zu retten ist, auf eine andere Partition und formatiere dann die FAT-Partition neu.

PS:
Ich sehe gerade, daß Silent-Tears das schon vorgeschlagen hat.

hermann72pb · 11 Sep 2009

Ich meine smbd oder nmbd kurzzeitig oben in der Topliste gesehen zu haben. Deswegen habe ich es angesprochen. Es kann aber sein, dass ich mich täusche.

Nun habe ich von meinem Stick fast alle Dateien über Linux geretet, Stick komplett neu patritioniert. Sogar die Struktur etwas abgeändert. Lediglich sda1 und sda2 als EXT2 und FAT gemacht. Alles mit "fsck -f" gecheckt. Auf sda1 und sda2 kamen die gereteten Dateien. Stick rein, und

die Box rebootet wieder!!!

Ich drehe langsam durch. Das darf nicht wahr sein!

Nun habe ich Anrufbeantworter im Verdacht. Ich lösche gleich alles von der FAT-Partition weg und probiere wieder. Ansonsten vielleicht noch mit einem anderen Stick. Es ist aber seltsam. Hat noch jemand eine Idee, warum die Box sich plötzlich ins Dauerrebot versetzt, sobald sie einen USB-Stick sieht?

Edit: Übeltäter endlich gefunden. Das war tatsächlich Anrufbeantworter. Die Datei "meta0" beinhaltete irgendein Müll. Das waren wahrscheinlich Ergebnisse meiner "Reparatur". Drinne hatte ich Texte vorgefunden, die mir zwar bekannt waren, aber die stammten von einer anderen Datei auf der gleichen Partition.
Meine Nachforschung ergab, dass "meta0" so eine Art Logbuch für AB0 darstellt. Blöderweise wird diese Datei auch nicht gesichert! Naja gut, ich hatte ja noch "meta1". Zwar passt sie nicht ganz, und ich dürfte die alten Nachrichten von AB1 hören, aber immer hin rebootet die Box nun nicht mehr.

Was lernen wir daraus?
1. Für mich war heute wirklich eine böse Überraschung alle drei mener Partitionen so "zerschossen" vorzufinden. Das schlimme daran ist, dass man gar nichts merkt, während die Partitionen vor sich vegitieren.
2. AVM kann gar nicht zuverlässige Programme schreiben. Wenn sie sich so stark auf externe Medien verlassen, dass man dadurch die Box zum Dauerrebot sehr leicht überreden kann, dann haben sie in den letzten Jahren gar nichts gelernt.
3. Man sollte sich ernsthaft überlegen, Partitionen während des Betriebes (z.B. über Nacht) regelmässig zu checken.
4. Programme und Daten möglichst trennen. Programmenpartition immer als ro mounten. Vielleicht dies irgendwie per WebIF konfigurierbar machen.

Ich hatte übrigens nur den Folgenfehler gefunden und nun endlich beseitigt. Die eigentliche Ursache für die fatale Zerstörung auf dem Stick ist mir immer noch unklar.

MfG

linuxkasten · 20 Sep 2009

In dem anderen Thread hast du geschrieben, dass man hier antworten soll.....also:
Partition als ro mounten:

#wenn sie noch nicht gemountet ist:
mount -t ext2 -r /dev/sdxX /mountpoint

Partition kurzzeitig rw und dann wieder ro:
#wenn sie bereits gemountet ist, readonly mounten:
mount -o remount -r /mountpoint
#und jetzt wieder rw:
mount -o remount -rw /mountpoint

hermann72pb · 20 Sep 2009

danke! Gerade ausprobiert und es scheint zu funktionieren, auch bei fat-Partitionen. Eigentlich wollte ich den zweiten mountpoint zum Schreiben anlegen, aber wenn es so geht, warum auch nicht.

Nun bleibt für die GUI die Frage, wie man den aktuellen Status ausliest. Ich hatte hier mal was mit sed gebastelt, was mir für jede Partition die Optionen rausfiltert:

Code:

mount | grep /dev/sd | sed -e "s/\(\/dev\/sd[^ ]*\) [^(]*(\([^)]*\))/\1 \2/"

/dev/sda1 rw,noatime,nodiratime
/dev/sda2 rw,nodiratime,fmask=0000,dmask=0000,codepage=cp437,iocharset=iso8859-1
/dev/sda5 rw,noatime,nodiratime
/dev/sda6 rw,noatime,nodiratime

Man kann es auch mountpointbezogen machen und noch dazu nur den rw/ro-Parameter mitnehmen:

Code:

mount | grep /dev/sd | sed -e "s/.* \(\/[^ ]*\) [^(]*(.*r\([o,w]\).*/\1 \2/"
/var/media/ftp/uStor01 w
/var/media/ftp/uStor02 o
/var/media/ftp/uStor05 w
/var/media/ftp/uStor06 w

Damit kann man schon was anfangen.

Edit: Dort geht es dann weiter. Ich hatte es doch von der allgemeinen Diskussion hier abgetrennt.

MfG

RalfFriedl · 21 Sep 2009

linuxkasten schrieb:
Partition kurzzeitig rw und dann wieder ro:

Code:

#wenn sie bereits gemountet ist, readonly mounten: mount -o remount -r /mountpoint #und jetzt wieder rw: mount -o remount -rw /mountpoint

Hast Du mal gelesen, das das bedeutet?

mount(8) schrieb:
-r Mount the file system read-only. A synonym is -o ro.
-w Mount the file system read/write. This is the default. A synonym is -o rw.

Mit -rw sagst Du also zunächst read-only (r) und danach read-write (w). Das 'w' überschreibt das 'r', weil es danach kommt, aber des 'r' ist widersprüchlich und unnötig.

linuxkasten · 21 Sep 2009

RalfFriedl schrieb:
Hast Du mal gelesen, das das bedeutet?

Nö, hab ich nicht.

Hab bis jetzt auch nur selten remountet, und es hat funktioniert. Natürlich ist es so sauberer und richtig.

Languages

Suche

Languages

Suche

Fehlerhafte EXT2-Partitionen auf dem USB-Stick führen zum reboot

hermann72pb

IPPF-Promi

Silent-Tears

IPPF-Promi

hermann72pb

IPPF-Promi

linuxkasten

Aktives Mitglied

Silent-Tears

IPPF-Promi

hermann72pb

IPPF-Promi

Silent-Tears

IPPF-Promi

hermann72pb

IPPF-Promi

RalfFriedl

IPPF-Urgestein

hermann72pb

IPPF-Promi

linuxkasten

Aktives Mitglied

hermann72pb

IPPF-Promi

RalfFriedl

IPPF-Urgestein

linuxkasten

Aktives Mitglied

Zurzeit aktive Besucher

Neueste Beiträge

Statistik des Forums