j-Serie DS 108j - boot-log o.ä. gesucht

Alle Geräte der Einsteiger j-Serie (Junior). Geräte für Privatanwender bis hin zu kleinen Firmen.
Status
Für weitere Antworten geschlossen.

Harry_Hirsch

Benutzer
Mitglied seit
29. Sep 2008
Beiträge
53
Punkte für Reaktionen
0
Punkte
6
Hallo zusammen,

wo in der Unendlichkeit der ganzen Linux-Systemverzeichnisse finde ich auf meiner DS 108j die log-Datei, in der der Bootvorgang mitgeschrieben wird (sollte meines Wissens nach automatisch bei Linux erfolgen). Meine DS bootet ziemlich lahm (Neustart aus dem Manager heraus angestossen) und da würde mich mal interessieren, wer da auf die Bremse getreten hat bzw. tritt. Gibt es da vielleicht noch eine andere Analysemöglichkeit als besagtes log-file?

Thx.

Harry_Hirsch
 

itari

Benutzer
Mitglied seit
15. Mai 2008
Beiträge
21.900
Punkte für Reaktionen
14
Punkte
0
Das Kommando: dmesg

und ansonsten stehen die Logs im /var/log-Verzeichnis, insbesondere messages

itari
 

Harry_Hirsch

Benutzer
Mitglied seit
29. Sep 2008
Beiträge
53
Punkte für Reaktionen
0
Punkte
6
log-files

Hi itari,

danke für die Tipps. Mein UNIX/Linux-Wissen ist leider ein bisschen eingestaubt und kommt erst laaangsam wieder zutage...will sagen, da hätte ich auch selber drauf kommen können. :)

Bevor ich heute/morgen Abend nun dazu komme, mir die log-files bzw. Systemmeldungen mal zu Gemüte zu führen...gibt es bekannte "Bremsklötze" bzw. worauf sollte ich auchten? Vielleicht hat da ja schon mal jemand Erfahrungen gesammelt...

H_H
 

Harry_Hirsch

Benutzer
Mitglied seit
29. Sep 2008
Beiträge
53
Punkte für Reaktionen
0
Punkte
6
Die Zeit läuft...

So,

habe gerade mal meine DS angeworfen und hinterher die message-Datei ausgelesen. Eingeschaltet habe ich sie um 19:41:56 und der letzte Eintrag war um 19:53:33. Das ist echt eine lage boot-Zeit, oder? Der "message" kann man entnehmen, dass die 1TB wohl einem e2fsck unterzogen wurden...das erklärt die lange Bootzeit, oder? Ich habe jedoch den Eindruck, dass das Checken des filesystems bei jedem zweiten Bootvorgang stattfindet!?!? Ich das normal? Ist das notwendig?

Danke schon mal für die Hinweise...

H_H
 

itari

Benutzer
Mitglied seit
15. Mai 2008
Beiträge
21.900
Punkte für Reaktionen
14
Punkte
0
Meist wird der fsck nur dann ausgeführt, wenn man das Kistchen nicht sauer herunterfährt.

Ich hatte das Problem auch mal eine Zeit lang. Probier abwechselnd mal mit dem Power-Knopf und mal mit dem Disk Station Manager herunterzufahren und starte dann danach wieder. So nach 2-3 müsste es mit dem fsck aufhören und auch in Zukunft bleiben lassen, es sei denn du ziehst den Stecker. :D

itari
 

Harry_Hirsch

Benutzer
Mitglied seit
29. Sep 2008
Beiträge
53
Punkte für Reaktionen
0
Punkte
6
Reboot tut gut !?!?

Hi itari,

das Runterfahren geht super fix (gibt es einen Unterschied zwischen Runterfahren per "Knopfdruck" und aus dem Manager heraus? Beides löst doch linuxintern sowas wie "init 6" oder "shutdown -h now" aus, oder gibt solches und solches Runterfahren?
Ich habe nun zum zweiten Mal gebootet (erstes Mal mit dem Manager runtergefahren, zweites Mal per Knopf) und sowohl beim ersten als auch beim zweiten Mal wurde fsck bemüht, weil der "max. mount-count" erreicht war...kein Steckerziehen o.ä.! In welcher config steht denn drin, in welchen Abständen fsck sich die Platte anschauen soll? Ich versuche es jetzt ein drittes Mal (Aller guten Dinge...).

H_H
 

itari

Benutzer
Mitglied seit
15. Mai 2008
Beiträge
21.900
Punkte für Reaktionen
14
Punkte
0
Ja, wenn dem allem so wäre. Da läuft ne BusyBox und außerdem selbstgestricktes Zeugs in der /etc/rc ab. Es scheint so als läuft der fsck nicht richtig durch, denn sonst wäre der max. mount-count weg.

itari
 

Harry_Hirsch

Benutzer
Mitglied seit
29. Sep 2008
Beiträge
53
Punkte für Reaktionen
0
Punkte
6
max. mount-count

"Watt nu?" sprach Zeus, "Die Götter sind besoffen und der Olymp ist vollgekotzt!"

Was kann ich nun zwecks Abhilfe tun? fsck läuft ja durch (dauert so 10 Minuten) und dann läuft die Kiste. Solange die DS läuft ist's also kein Problem, aber wehe man (=ich) muss rebooten...dann dauerts....grrrr...das soll so nicht sein. Das soll wieder weggehen!!! :rolleyes:

H_H
 

itari

Benutzer
Mitglied seit
15. Mai 2008
Beiträge
21.900
Punkte für Reaktionen
14
Punkte
0
"Watt nu?" sprach Zeus, "Die Götter sind besoffen und der Olymp ist vollgekotzt!"

Was kann ich nun zwecks Abhilfe tun? fsck läuft ja durch (dauert so 10 Minuten) und dann läuft die Kiste. Solange die DS läuft ist's also kein Problem, aber wehe man (=ich) muss rebooten...dann dauerts....grrrr...das soll so nicht sein. Das soll wieder weggehen!!! :rolleyes:

H_H

Versteh ich, war bei mir ja auch die Panik. Ich bin das irgendwie los geworden, hab allerdings auch immer noch max-mount-counts, die nicht schön sind. Vielleicht guckst hier noch mal rein.

itari
 

Harry_Hirsch

Benutzer
Mitglied seit
29. Sep 2008
Beiträge
53
Punkte für Reaktionen
0
Punkte
6
Ich werd' noch zum Checker...

Vielleicht guckst hier noch mal rein.

itari

Danke für den Tipp, werde ich mir dann ggfs. morgen mal zur Brust nehmen. Ich werde berichten, ob's was gebracht hat...

Guts Nächtle...

H_H
 

QTip

Super-Moderator
Teammitglied
Mitglied seit
04. Sep 2008
Beiträge
2.341
Punkte für Reaktionen
13
Punkte
84
Die mount-counts und weitere Einstellungen für fsck kannst mit tune2fs durchführen.

z.B. mit tune2fs -c 30 -i 180d /dev/sdXY sagst fschk, dass es alle 30 Mounts ein Check durchführen soll, spätestens aber nach 180 Tagen. Für /dev/sdXY dann deine Device für die entspechende Platte.

Mit tune2fs -c 0 -i 0 /dev/sdXY schaltet man die automatische Überprüfung vollständig ab, nicht sehr ratsam.
 

Harry_Hirsch

Benutzer
Mitglied seit
29. Sep 2008
Beiträge
53
Punkte für Reaktionen
0
Punkte
6
fsck-Problem lösen

Hallo QTip,

das werde ich dann heute Abend direkt mal ausprobieren, danke für den Tipp. Eine Frage hätte ich dennoch...die Platte (/dev/hda) ist ja in verschiedene Partitionen aufgeteilte - mindestens drei, wenn ich das richtig sehe (swap, "system" und volume1). Muss ich nun für alle drei Partitionen seperat die "counts" festlegen oder reicht die Angabe des tatsächlichen physikalischen Laufwerkes (also in meinem Falle /dev/hda)? Sollten alle Partitionen seperat betrachtet werdenb müssen, so kann ich die swap-Partition doch sicherlich außen vor lassen, oder?

Danke schon mal für die weiteren Hinweise...

H_H
 

itari

Benutzer
Mitglied seit
15. Mai 2008
Beiträge
21.900
Punkte für Reaktionen
14
Punkte
0
Alle 3 Partitionen sind eigenständige Einheiten. Für die swap brauchst das in der Regel nicht, weil das kein Dateisystem drauf ist. Das Programm tune2fs kann nur mit Dateisystem arbeiten und die sind auf der System-Partition / und der /volume1 vorhanden. (Natürlich auch bei deinen externen Platten oder wenn durch verschiedene Dateisystem auf deinen 4 bis 5 Platten hast).

itari
 

Harry_Hirsch

Benutzer
Mitglied seit
29. Sep 2008
Beiträge
53
Punkte für Reaktionen
0
Punkte
6
Was ist, was wird...

Aaaalso...ich habe mal mit tunefs auf /dev/hda1+3 folgende Optionen gesetzt (wie vorgeschlagen):

- 1 Check alle 30 Bootvorgänge
- Check spätestens nach 180 Tagen

darüber hinaus habe ich

- den mount-Zähler auf 1 gesetzt

Nach einem Reboot hat's dann wieder verdächtig gedauert...es hat sich folglich nix geändert. Ich habe nun dem link von itari folgend die /etc/rc editiert und lasse nun zwangsweise über hda1+3 e2fsck drüberlaufen und dieses auch wie beschrieben protokollieren. Mal sehen, ob das was bringt.

Versuch macht kluch!

Ich werde vom Ergebnis berichten...die Hoffnung stirbt zuletzt.

H_H

P.S.: Habt ihr Erfahrungen mit der Reaktionszeit des Synology-Supports gemacht? Ich habe dort am WE mal eine Anfrage platziert, bis dato aber noch nix gehört, außer der automatischen E-Mail, dass meine Anfrage eingegangen sei.
 

itari

Benutzer
Mitglied seit
15. Mai 2008
Beiträge
21.900
Punkte für Reaktionen
14
Punkte
0
Habt ihr Erfahrungen mit der Reaktionszeit des Synology-Supports gemacht? Ich habe dort am WE mal eine Anfrage platziert, bis dato aber noch nix gehört, außer der automatischen E-Mail, dass meine Anfrage eingegangen sei.

Kleiner 1 Stunde, direkt vom Support-Mitarbeiter. Kann aber sein das die intern gerade ihr Rechenzentrum umstellen, weil es gestern immer wieder Zeiten gab, wo man den Synology-Web-Server nicht erreichen konnte.

itari
 

Harry_Hirsch

Benutzer
Mitglied seit
29. Sep 2008
Beiträge
53
Punkte für Reaktionen
0
Punkte
6
Watt nu???

So, habe gerade mit modifizierter /etc/rc gebootet...hier die /tmp/boot.log

Tue Oct 14 22:46:50 CEST 2008
e2fsck -pf /dev/hda1 1.39-May082008: 8017/311296 files (0.1% non-contiguous), 76836/622510 blocks
e2fsck -nv /dev/hda1 1.39-May082008: is cleanly umounted, 8017/311296 files, 76836/622510 blocks

e2fsck -p /dev/hda3 1.39-May082008: is cleanly umounted, 57484/121716736 files, 49898167/243404831 blocks
(check after next mount)
e2fsck -nv /dev/hda3 1.39-May082008: is cleanly umounted, 57484/121716736 files, 49898167/243404831 blocks
(check after next mount)

Ich habe dann ein e2fsck -nv /dev/hda3 hinterhergeschoben, ohne vorheriges umount. Erste interessante Erkenntnis: Obwohl ich mit tunefs den mount-count auf 1 gesetzt hatte, wird nun gemeldet, dass 1685 Tage lang kein check mehr durchgeführt wurde...4,6 Jahre...hmmm...wie lange gibt es die DS 108j doch gleich auf dem Markt? Und täusche ich mich, oder habe ich das Ding noch keine 4 Wochen...wo kommen dann die 1685 Tage her???

So nun kommt zu div. inodes die folgende Meldung:

Inode xy has INDEX_FL flag set on filesystemwithout htree support.
Clear HTree index? no


...mal sehen, was noch passiert...wart...wart...wart...es kommen noch ein paar anderen Meldungen...
Das Warten hat ein Ende, hier die Zusammenfassung:

57482 inodes used (0.05%)
1337 non-contiguous inodes (2.3%)
# of inodes with ind/dind/tind blocks: 34874/12797/1
49898166 blocks used (20.50%)
0 bad blocks
2 large files

50824 regular files
5599 directories
0 character device files
0 block device files
0 fifos
2746 links
1050 symbolic links (1050 fast symbolic links)
0 sockets


Na, dann mache ich mal 'n reboot und harre der Dinge, die da jetzt passieren werden...und wieder heißt es warten. Endlich fertig gebootet und ein Blick in die /var/log/message zeigt: Da hat sich nix geändert. ;-( So, nun seid ihr wieder dran. Wie kann ich die offensichtlichen filesystem-Fehler auf volume1, also /dev/hda3 beheben, ohne die Daten zu zerschießen?

CU

H_H
 

itari

Benutzer
Mitglied seit
15. Mai 2008
Beiträge
21.900
Punkte für Reaktionen
14
Punkte
0
Warum meinst, habe ich das mit dem fsck in der /etc/rc gemacht und protokollieren lassen?

Weil wenn ein ext3-Filesystem gemoutet ist, das ext3-Transaktions-Protokoll gefahren wird und der fsck, der ohne Protokoll direkt auf den Superblock des Dateisystems zugreift, nicht mehr die 'ganze Realität' sieht. Deswegen gibts dann immer Abweichungen usw. usw. usw. (hab ich an anderer Stelle schon mal in aller Ausführlichkeit berichtet).

Ähnlich ergeht es auch dem tune2fs ... Kannst so viel einstellen wie du willst, du bekommst immer was anderes angezeigt und die Effekte beim Starten sind auch nicht so, wie sie sein sollten. Warum? Auch dass hab ich schon erklärt, weil in der /etc/rc nicht das normale Zeugs drin steht, was man erwarten würde ...

Also: Solange der in der /etc/rc gestartete e2fsck -pf /dev/hda1 bzw .3 bzw /dev/sda1 bzw. 3 gelaufen ist und anschließen, das 'clearly unmounted' kommt, hast alles dir nur Mögliche getan. Mehr geht nicht. Und solange 'clearly unmounted' kommt, ist zunächst mal die Welt in Ordnung.

Solange es keinen 'single user' (init s) mode auf der DS gibt, um die Dateisysteme zu richten, wirst kaum Chancen haben, mehr zu machen.

itari
 

Harry_Hirsch

Benutzer
Mitglied seit
29. Sep 2008
Beiträge
53
Punkte für Reaktionen
0
Punkte
6
Die Hoffnung stirbt zuletzt...

Hi itari,

deine zahlreichen postings habe ich im Forum gelesen und dort auch den einen oder anderen hilfreicen Hinweis für mich abgezweigt. Mittlerweile hat sich der Support gemeldet und erfragt nähere Informationen, die ich dann aber erst heute Abend beisteuern kann. Mal sehen, was von denen dann kommt. Ich spiele mittlerweile ernsthaft mit dem Gedanken, die DS nochmal komplett aufzusetzen, also die Platte zu formatieren...zumindest den Datenbereich, der ja offensichtlich Probleme bereitet. Das sollte möglich sein, oder? Aber ich warte jetzt erstmal die Hilfe des supports ab. Dann kann ich ja immer noch tabula-rasa machen. Die rd. 12 Minuten Bootvorgang nerven echt...

Ich bleibeam Ball und werde berichten...

H_H
 

Harry_Hirsch

Benutzer
Mitglied seit
29. Sep 2008
Beiträge
53
Punkte für Reaktionen
0
Punkte
6
debug-info

Hi,

so! Zu Hause vor dem PC sitzend bin ich nun den Anweisungen des supports gefolgt...


[...]
The engineer needs more information about the booting procedure. Please refer to the following document to save and send us the kernel to seek the possible cause. We will give more advices after diagnosing the log:

ftp://on-line:online_user@ftp.synology.com/on-line/Document/How to get the kernel log_Ajax UI.doc


If you have further questions or suggestions, please feel free to contact Synology support again. [...]


...habe mich also am DS Manager angemeldet und dann die Adresse um ?debug=1 ergänzt. Das lieferte nun eine Datei, die ich abspeichern konnte (msg.tar.gz) und da scheint wohl ein kernel-log-file drin zu stecken. Hat das einer von euch schon mal ausgewertet?

H_H
 

Harry_Hirsch

Benutzer
Mitglied seit
29. Sep 2008
Beiträge
53
Punkte für Reaktionen
0
Punkte
6
Zwischenbericht

Hi folks,

das Zusenden der log-Datei hat zwar geklappt, die notwendigen Erkenntnisse konnte der Support daraus leider nicht ziehen. Nun habe ich dem Support (wohl oder übel) die Tore geöffnet und mittlerweile wurde eine debug-routine auf die DS gepackt, welche dann wohl den Bootvorgang etc. genau "ausschnüffelt", um hinter des Pudels Kern zu kommen. Der Zeitversatz von 7 Stunden erleichtert die Sache nicht unbegingt...

Ich werde weiter berichten, sobald es neue Erkenntnisse gibt.

CU

H_H
 
Status
Für weitere Antworten geschlossen.
 

Kaffeautomat

Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.

Als Dankeschön schalten wir deinen Account werbefrei.

:coffee:

Hier gehts zum Kaffeeautomat