+-Serie 415+ fährt nach zeitgesteuertem Ausschalten nicht mehr hoch

[Hafer]

Moin zusammen,

die 415+ fährt manuell ganz ohne Probleme herunter und nach Einschalten durch Knopfdruck auch wieder hoch. Auch das zeitgesteuerte Herunterfahren klappt ohne Probleme. Das zeitgesteuerte Hochfahren hingegen führt dazu, dass die 415+ bei blauem LED-Dauerfeuer im Bootprozess hängen bleibt. Die Festplatten scheinen dabei nicht aktiviert zu werden, sie stehen still. (Sehr) langes Warten ändert daran nichts. Erst das 5 - 6 sekündige Drücken des Einschaltknopfes führt zu einem ganz normalen Bootprozess. Weiß jemand Rat?

Gruß Hafer

PS: Die Einstellungen aus der Systemsteuerung:

 

[Frogman]

Kannst Du einmal die Datei /var/log/messages hier posten?

Deine Bilder sind übrigens viel zu klein - darauf kann man nicht wirklich etwas erkennen!

 

[Hafer]

oops, die Bilder zeigen eigentlich nur, dass um 23:00 Uhr herunter-, und um 07:00 Uhr heraufgefahren werden soll (erstes Bild) und dass die Festplatten nach 20min in den (erweiterten) Ruhemodus geschickt werden (zweites Bild).

Anbei ein Ausschnitt aus /var/log/messages beginnend kurz vor 23:00 Uhr. Um 07:00 schaltete die 415+ tatsächlich ein, bootete aber nicht, bis ich -- wie oben beschrieben -- um 09:07 Uhr nachgeholfen habe.

Gruß Hafer

Oct 10 22:49:25 PapaDS415 hotplugd: ##### ACTION:remove
Oct 10 22:49:25 PapaDS415 hotplugd: DEVICE:/proc/bus/usb/003/002
Oct 10 22:49:25 PapaDS415 hotplugd: DEVPATH:3-2:1.0
Oct 10 22:49:25 PapaDS415 hotplugd: SUBSYSTEM:usb
Oct 10 22:49:25 PapaDS415 hotplugd: INTERFACE:8/6/80
Oct 10 22:49:25 PapaDS415 hotplugd: ##### ACTION:remove
Oct 10 22:49:25 PapaDS415 hotplugd: DEVICE:/proc/bus/usb/003/002
Oct 10 22:49:25 PapaDS415 hotplugd: DEVPATH:3-2
Oct 10 22:49:25 PapaDS415 hotplugd: SUBSYSTEM:usb
Oct 10 23:00:01 PapaDS415 kernel: [56604.956181] init: crond main process (5194) killed by TERM signal
Oct 10 23:00:01 PapaDS415 syno_poweroff_task: System is going to poweroff.
Oct 10 23:00:01 PapaDS415 kernel: [56605.015571] init: sshd main process (5361) terminated with status 255
Oct 10 23:00:01 PapaDS415 kernel: [56605.152293] init: smbd main process (11154) killed by TERM signal
Oct 10 23:00:05 PapaDS415 synoaudiod: synoaudiod.cpp:1647 synoaudiod exit
Oct 10 23:00:07 PapaDS415 findhostd: findhostd.c:114(FHOSTDProcessNameGet) open [/proc/1232/cmdline] fail2)[No such file or directory]
Oct 10 23:00:07 PapaDS415 findhostd: findhostd.c:64(FHOSTDExit) exit on signal[15]
Oct 10 23:00:07 PapaDS415 root: /usr/syno/etc/rc.d/S98findhostd.sh stop findhostd
killall: synolunbkp: no process killed
Oct 10 23:00:14 PapaDS415 synorelayd[11101]: synorelayd.cpp:932 get sigterm, logout
Oct 10 23:00:15 PapaDS415 synorelayd[11101]: synorelayd.cpp:1342 stoped
Oct 10 23:00:19 PapaDS415 synocheckshare: synocheck

 

[Hafer]

Meine Güte. Das glaubt mir hier keiner - Meine Router stürzt ab, wenn ich den message-log hier hochladen will

Wie auch immer: http://pastebin.com/Fuc2da5B

Gruß Hafer

 

[Frogman]

Anbei ein Ausschnitt aus /var/log/messages beginnend kurz vor 23:00 Uhr. Um 07:00 schaltete die 415+ tatsächlich ein, bootete aber nicht, bis ich -- wie oben beschrieben -- um 09:07 Uhr nachgeholfen habe.

Mmh, sehe ich nicht...

Oct 10 23:00:01 PapaDS415 kernel: [56604.956181] init: crond main process (5194) killed by TERM signal
Oct 10 23:00:01 PapaDS415 syno_poweroff_task: System is going to poweroff.
Oct 10 23:00:01 PapaDS415 kernel: [56605.015571] init: sshd main process (5361) terminated with status 255
Oct 10 23:00:01 PapaDS415 kernel: [56605.152293] init: smbd main process (11154) killed by TERM signal
Oct 10 23:00:05 PapaDS415 synoaudiod: synoaudiod.cpp:1647 synoaudiod exit
Oct 10 23:00:07 PapaDS415 findhostd: findhostd.c:114(FHOSTDProcessNameGet) open [/proc/1232/cmdline] fail:(2)[No such file or directory]
Oct 10 23:00:07 PapaDS415 findhostd: findhostd.c:64(FHOSTDExit) exit on signal[15]
Oct 10 23:00:07 PapaDS415 root: /usr/syno/etc/rc.d/S98findhostd.sh stop findhostd
killall: synolunbkp: no process killed
Oct 10 23:00:14 PapaDS415 synorelayd[11101]: synorelayd.cpp:932 get sigterm, logout
Oct 10 23:00:15 PapaDS415 synorelayd[11101]: synorelayd.cpp:1342 stoped
Oct 10 23:00:19 PapaDS415 synocheckshare: synocheckshare_vol_unmount.c:147 Unmount Share [INTERNAL] [/dev/mapper/vol1-origin] [/volume1]
Oct 10 23:00:20 PapaDS415 kernel: [56623.810969] md: md2: set sdb5 to auto_remap [0]
Oct 10 23:00:20 PapaDS415 kernel: [56623.816038] md: md2: set sdc5 to auto_remap [0]
Oct 10 23:00:20 PapaDS415 kernel: [56623.821104] md: md2: set sda5 to auto_remap [0]
Oct 11 09:07:45 PapaDS415 kernel: [    0.000000]  SMBIOS=0x7ed06000  ACPI 2.0=0x7f7fe014
Oct 11 09:07:45 PapaDS415 kernel: [    0.000000] Kernel-defined memdesc doesn't match the one from EFI!
Oct 11 09:07:45 PapaDS415 kernel: [    0.000000] ACPI: RSDP 000000007f7fe014 00024 (v02 INSYDE)
Oct 11 09:07:45 PapaDS415 kernel: [    0.000000] ACPI: XSDT 000000007f7fe120 0009C (v01 INSYDE MOHOPEAK 00000001      01000013)
Oct 11 09:07:45 PapaDS415 kernel: [    0.000000] ACPI: FACP 000000007f7f9000 0010C (v05 INSYDE MOHOPEAK 00000001 ACPI 00040000)
Oct 11 09:07:45 PapaDS415 kernel: [    0.000000] ACPI Warning: FADT (revision 5) is longer than ACPI 2.0 version, truncating length 268 to 244 (20110623/tbfadt-288)

Ich sehe gestern Abend um 23 Uhr das Ausschalten (rot) und heute früh gegen 9:07 Uhr das Starten (blau). Um 7:00 Uhr gab's nix...

 

[Hafer]

Das genau ist das Problem. Der Bootprozess klemmt wohl so früh, dass noch nix in die logs geschrieben wird (oder werden kann). Um 07:00 Uhr hat sich das Gerät eingeschaltet, aber die Platten nicht angeworfen und stattdessen die blaue Blinkorgie gestartet ...

Gruß
Hafer

 

[lefou]

Hallo,

ich habe das selbe Problem.. auch bei einer 415+

Shutdown ist 04:00 Uhr, aufwachen sollte sie um 16:00Uhr.

Hier das Logfile. Der Start um 17:05Uhr wurde von mir manuell angestoßen.

Oct 13 04:00:01 NetSpace kernel: [27248.521631] init: crond main process (5212) killed by TERM signal
Oct 13 04:00:01 NetSpace syno_poweroff_task: System is going to poweroff.
(...)
Oct 13 04:00:23 NetSpace kernel: [27270.759234] md: md2: set sda3 to auto_remap [0]
Oct 13 04:00:23 NetSpace kernel: [27270.764301] md: md2: set sdd3 to auto_remap [0]
Oct 13 04:00:23 NetSpace kernel: [27270.769365] md: md2: set sdc3 to auto_remap [0]
Oct 13 04:00:23 NetSpace kernel: [27270.774429] md: md2: set sdb3 to auto_remap [0]
Oct 13 17:05:10 NetSpace kernel: [    0.000000]  SMBIOS=0x7ed06000  ACPI 2.0=0x7f7fe014 
Oct 13 17:05:10 NetSpace kernel: [    0.000000] Kernel-defined memdesc doesn't match the one from EFI!
Oct 13 17:05:10 NetSpace kernel: [    0.000000] ACPI: RSDP 000000007f7fe014 00024 (v02 INSYDE)
Oct 13 17:05:10 NetSpace kernel: [    0.000000] ACPI: XSDT 000000007f7fe120 0009C (v01 INSYDE MOHOPEAK 00000001      01000013)
Oct 13 17:05:10 NetSpace kernel: [    0.000000] ACPI: FACP 000000007f7f9000 0010C (v05 INSYDE MOHOPEAK 00000001 ACPI 00040000)
Oct 13 17:05:10 NetSpace kernel: [    0.000000] ACPI Warning: FADT (revision 5) is longer than ACPI 2.0 version, truncating length 268 to 244 (20110623/tbfadt-288)

Auch bei mir hat die Syno blau geblinkt als ich nach Hause gekommen bin...

 

[dil88]

Ihr solltet beide ein Ticket beim Support aufmachen (Formuliar hier).

 

[lefou]

erledigt. Ich berichte dann, sobald ich eine Antwort habe.

Danke für den Link

 

[Hafer]

Done. Bin gespannt.

Gruß Hafer

 

[Hafer]

Und das ist die total befriedigende Antwort vom Support:

Sehr geehrter Kunde,

leider haben Sie Community-Pakete installiert, die zu dem von Ihnen
beschriebenen Verhalten führen können.
Sie haben nun zwei Möglichkeiten.

Möglichkeit 1:
Sie wenden sich zwecks Support an die Ersteller der Community-Pakete und
fragen dort auf eventuell bekanntes Verhalten und einem Lösungsansatz.

Möglichkeit 2:
Ein Reset des Systems.
- Backup Ihrer Daten
- Löschen der Volumes
- Zurücksetzten der DiskStation wie in Punkt 3 dieser Anleitung
beschrieben: http://www.synology.com/de-de/support/tutorials/493#t3
- Neuinstallation des DSM
- Erstellen eines neuen Volumes
- Wiederherstellung des Backups

Sollten Sie noch Fragen haben können Sie sich gerne jederzeit an uns wenden.

Formal korrekt beantwortet, denn iPKG könnte ja vielleicht wirklich etwas damit zu tun haben, wer will das ausschließen?
Liest sich in diesem Zusammenhang aber für mich wie: "Wenn Sie Community Pakete einspielen, erlischt unser Support".

Da mir aber nichts anderes übrig bleibt, der Aufforderung zu folgen, eine Frage: Liegen Anteile des Systems auf dem Volume?

Gruß Hafer

 

[dil88]

Es ist in der Praxis auch so, aber wie würdest Du es an Synologys Stelle machen? Mit ipkg kann man eine Menge machen, da wird es für jeden Hersteller schwierig, den Support-Aufwand in Grenzen zu halten.

 

[lefou]

hm... ich hab noch keine Antwort erhalten, vllt liegt es daran, dass ich meine Anfrage in Englisch geschrieben habe und die Anfrage in den USA bearbeitet wird...

Ich hab' zwar auch ipkg installiert, bin aber der Meinung das nach der Support-Anfrage getan zu haben...

Mal schauen.
Ich habe das Problem übrigens nicht nur bei automatischem Runterfahren, bei manuellem Runterfahren tritt das selbe Problem auf.

Ich kann zwar Synology verstehen, dass sie auf das Community-Package verweisen, allerdings nicht, was ipkg damit zu tun hat dass es beim zweiten boot-Versuch funktioniert...

 

[dil88]

Es hat vermutlich gar nichts damit zu tun. Aber es wird genug Support-Anfragen bei Synology geben, wo es doch damit etwas zu tun hat. Und deshalb blocken sie das ab, was ich durchaus verstehen kann.

 

[Hafer]

Meine Support-Anfrage war ebenfalls in Englisch gehalten, die Antwort hingegen in Deutsch (s.o.).

Trotz Gemaule habe ich nun getan, was der Support von mir verlangt hat (mit der Ausnahme, dass ich die Volumes nicht gelöscht habe) und habe um 19:40 Zeuge eines erfolgreichen automatischen shutdowns, sowie um 19:50 eines erfolgreichen startups werden dürfen. Erster Test bestanden. Generalprobe heute Nacht um 23:00 Uhr.

Gruß Hafer

 

[Hafer]

Tja, Generalprobe leider nicht bestanden. Heute kein automatisches Hochfahren, sondern Hängenbleiben, wie in #1 beschrieben.

Gruß Hafer

 

[TheTwist76]

Hi zusammen,

seit Montag gibt es auf dem Synology Server ein neues Verzeichnis einer neuen DSM 5.0 Version (4528).
MD5 (DSM_DS415+_4528.pat) = 956010c1d63891ab358c04f21673832c

Da normalerweise die Verzeichnisse nachdem die Checksum Datei abgelegt wurde recht schnell gefüllt werden dauer dieses mal etwas länger. Entweder habe Sie im letzten Moment noch Probleme festgestellt oder aber Euer Problem wird noch gefixt.
Wir werde es wohl abwarten müssen.

@Hafer - Hast Du die Support Anfrage erneut geöffnet? Da bei dir das Problem weiterhin existiert.

Viele Grüße
TheTwist

 

[Hafer]

Yes!

Gruß Hafer

 

[TheTwist76]

seit Montag gibt es auf dem Synology Server ein neues Verzeichnis einer neuen DSM 5.0 Version (4528).
MD5 (DSM_DS415+_4528.pat) = 956010c1d63891ab358c04f21673832c

Da normalerweise die Verzeichnisse nachdem die Checksum Datei abgelegt wurde recht schnell gefüllt werden dauer dieses mal etwas länger. Entweder habe Sie im letzten Moment noch Probleme festgestellt oder aber Euer Problem wird noch gefixt.
Wir werde es wohl abwarten müssen.

TheTwist

tja seit heute ist das Verzeichnis mit der Version DSM 5.0 4528 (DSM_DS415+_4528.pat) wieder verschwunden. Hatten wohl doch noch Probleme mit der Version.

Viele Grüße
TS

 

[jan_9999]

Hallo zusammen,

endlich bin ich hier fündig geworden. Ich habe mit meiner DS415+ selbiges Problem, und zwar nach JEDEM Shut Down sowohl automatisch als auch manuell. Hochfahren, warten, ....., ausschalten an der Powertaste, nochmaliges anschalten. Erst dann höre ich meine 4 Platten hochdrehen. So wie sich das hier darstellt, bin ich dieser Situation wohl oder übel ausgeliefert? Ich habe übrigens DSM 5 stock OHNE jedwede weitere Software laufen...
Dann warte ich mal mit ab oder schicke diese Woche das Teil zurück.

Gruß
Jan