DSM 4.1 - 2647 - Erfahrungen, Probleme, Bugs

[amarthius]

Geht eigentlich bei euch der "Sortieren nach"-Button im Paketzentrum? Er hat bei mir noch nie funktioniert (IE und Chrome).

 

[Puppetmaster]

Geht eigentlich bei euch der "Sortieren nach"-Button im Paketzentrum? Er hat bei mir noch nie funktioniert (IE und Chrome).

Ja, der geht bei mir (firefox), allerdings auch nur im Reiter "Verfügbar". Bei den anderen Reitern ist der Button ausgegraut.
Sinnstiftend ist der Button allerdings nicht, du kannst nur nach 'Name' und 'Beliebtheit' sortieren.

 

[amarthius]

Ich kann ja nicht nicht mal sehen was es als Auswahl gibt =/

 

[Puppetmaster]

Ich kann ja nicht nicht mal sehen was es als Auswahl gibt =/

Merkwürdig. Aber damit du es auch mal gesehen hast.
Bitteschön:

 

[amarthius]

Hab dem nicht so viel Beachtung geschenkt. Die Funktion gibts nur bei den Synology-Paketen. Nicht, aber bei Installiert und weitere Paketquellen..

Hab immer so Funktionen gesucht nach Status sortieren, Aktualisierung und ähnlichem.

Danke

 

[aj69]

Moin,

gibt eigentlich was neues zum Thema hibernation?
Auch nach dem editieren der S23ntpd.sh funktionierts bei mir nicht.
Die Platten gehen schlafen, wachen aber gleich wieder auf.
Das ist auf meiner DS411j so seit dem Update auf 4.0 auf 4.1.
Gibt es da jetzt ein patch?
Wenn ich ne sicher downgrade möglichkeit hätte wäre ich auch schon froh :-(

Danke

 

[maekk]

Hallo,
Ich kriege daheim ganz schön Mecker, dass unser schöner gemeinsamer caldav nicht mehr geht. Gibt's dazu etwas neues?

Gruß
maekk

 

[Omega01]

DS211j ist nach dem Update nicht mehr erreichbar.
Zumindest nicht über den Browser oder SMB.

Pings an die IP kommen allerdings zurück.

Neustart ändert leider nichts.

Hat jemand eine Idee?

 

[Ap0phis]

Frag einfach mal den Status deiner DS mit dem Synology-Assistant ab.

 

[Omega01]

Restted und DSM neu installiert - war ohnehin nötig.
Schrecksekunde überstanden, vielen Dank.

 

[gixgax75]

Moin!!

Weiß jemand, warum die Festplatten der DS211j starten, wenn ich einen PC/Laptop bzw. Receiver anschalte?
Es erfolgt dabei noch kein Zugriff auf irgendwelche Files.


Bei der 1922'er Firmware, auf die ich jetzt zurück bin, laufen sie nicht an, wenn ein Gerät angeschaltet wird.
Erst wenn ich auf die Diskstation zugreife.
Sonst bleiben sie aus.

Danke schon mal im Voraus.

Mfg gixgax

 

[Frogman]

Ich wollte Euch einmal kurz eine Info geben über ein etwas merkwürdiges Phänomen mit der Zeitsynchronisierung und dem Hibernate, welches ich gerade beobachte.
Für meine DS111 habe ich mir letzte Woche eine SSD geholt (m4 256GB) und damit neu das DSM4.1-2647 aufgesetzt. Vorher lief dort eine Samsung-Platte, worauf jungfräulich DSM4.0-2228 installiert wurde mit einem späteren Update auf die 4.1-2647.

Auf der Samsung-Platte hatte ich unter 4.0 eine rc.local mit einer ntpdate-Synchronisation zum Start, was tadellos lief (ergänzt um ein ntpdate per Cron einmal am Tag). Nach dem Update auf die Version 4.1 funktionierte das immer noch, was aber nicht mehr funktionierte, was der Hibernate-Zustand - offensichtlich verursacht durch den ständig gestarteten ntpd (was Benares ja herausgearbeitet hatte). Nach dem Deaktivieren des ntpd über das Editieren der S23ntp.sh lief dann alles wunderbar (Zeitserver war nicht aktiviert, ntpdate wurde über die rc.local beim Start und per Cron korrekt aufgerufen).
Nun wollte ich das Ganze mit der SSD neu aufsetzen - natürlich gleich mit der 4.1. Alles ging ruckzuck, wobei ich gleich zufällig etwas bemerkte: der Hibernate funktionierte problemlos OHNE die Änderung an der S23ntp.sh, d.h. mit laufendem ntpd. Was dagegen nicht funktionierte, war das ntpdate über die rc.local - es will einfach keine Synchronisierung klappen, nach einer längeren Zeit von ca. 10 Minuten kommt jedes Mal eine Fehlermeldung "could not set time...blabla". Das ntpdate über einen Cron funktioniert dagegen normal, ebenso das händische Aufrufen in der Shell.

Neugierig geworden - und um den Unterschied FP/SSD ausschließen zu können - wiederholte ich das ganze Spielchen nochmals mit der Samsung: die 4.1 jungfräulich aufgespielt zeigte sich das gleiche Verhalten wie bei der SSD, d.h. Hibernate funktioniert OHNE das Deaktivieren des ntpd, das ntpdate über die rc.local geht nicht, über Cron und per Hand geht es dagegen.
Dann nochmals den langen Weg mit der Samsung: 4.0 installiert, eingerichtet mit ntpdate über rc.local und Cron - alles lief wie zuvor. Dann das Update auf die 4.1 - und ebenso wieder die gleichen Probleme wie oben beschrieben.

Zusammenfassend scheint es offenbar so zu sein (zumindest mit der DS111), dass abhängig davon, ob die die 4.1-2647 jungfräulich oder über ein vorhandenes 4.0-2228 installiert wird,

1. der Hibernate-Zustand mit laufendem ntpd erreicht wird oder nicht
2. ein ntpdate über eine rc.local bzw. Cron funktioniert oder nicht.

Die Logs dazu habe ich mal dem Support zusammengeschnürt, bin gespannt, was die dort herauslesen können.

 

[Benares]

Hallo Frogman,

ich hab inzwischen noch folgendes herausgefunden:
Mit der 4.1-2647 (im Gegensatz zur 4.1-2636) funktioniert das Hibernate auch bei laufendem ntpd, wenn er richtig konfiguriert ist. Man muss dafür nochmal in die NTP-Einstellungen gehen, eine Dummy-Änderung vornehmen, speicher, dann wieder zurückändern und wieder erneut speichern. Erst danach steht in der /etc/ntpconf folgendes drin:

restrict default noquery notrust nomodify
restrict -6 default noquery notrust nomodify
restrict 127.0.0.1
restrict -6 ::1
restrict 192.168.0.1
server 192.168.0.1 prefer

(192.168.0.1 ist mein Router, den ich als NTP-Server eingetragen hab)
Davor war da nur eine Zeile drin (weiss nicht mehr welche). Da wird beim Firmware-Update wohl was nicht richtig migriert.

Bei laufendem ntpd geht aber der Befehl "/usr/sbin/ntpdate -b 192.168.0.1" nicht mehr, weil der Port durch den ntpd belegt ist, somit ist auch der cron-Job in /etc/crontab Unsinn, ich hab ihn auskommentiert.

Den einmaligen NTP-Abgleich beim Booten mach ich mit einem eigenen Script /usr/syno/etc/rc.d/S22ntpdate.sh kurz bevor der ntpd startet:

#!/bin/sh
# S22ntpdate.sh
#
# ntpdate beim Start der DS ausfuehren
#
# 17.04.2010 gm
# Installation: cp S22ntpdate.sh /usr/syno/etc/rc.d
#

case "$1" in

stop)
        ;;

start)
        /usr/sbin/ntpdate -b 192.168.0.1
        ;;

restart)
        $0 stop
        $0 start
        ;;
*)
        echo "usage: $0 { start | stop | restart}" >&2
        exit 1
        ;;

esac

Als letzten Schritt solltest du noch die Datei /etc/syslog.deny prüfen, ob zumindest die debug und info Meldung gefiltert werden. Bei mir sieht es dort so aus (war bereits der Default):

# These priorities in this config file are not logged
# refer to syslog.h

#alert
#crit
debug
#emerg
#err
info
notice

# Always keep these setting , as these are obselete
# refer to syslog.h
error
none
warn
panic

Damit läuft es bei mir nun super. Nur noch einen Wakeup pro Tag für den DDNS-Abgleich nach der Zwangstrennung.

Gruß Benares

 

[Frogman]

Hi Benares,
das konnte ich jetzt auch nachvollziehen (außerdem sind die Rechte für ntp.conf bei einer frischen Installation nur 644 und nicht 755).
Bei der Beschränkung "notrust" wäre ich allerdings skeptisch... gemäß den Bescheibungen für Versionen ab 4.2 (was hier zutrifft) hieße das, man muß auf beiden Seiten eine gültige kryptografische Authentifizierung etabliert haben, damit die Packets nicht ignoriert werden.
Meine ntp.conf habe ich auch ein wenig frisiert, sie sieht jetzt so aus:

restrict default noquery nomodify
restrict -6 default noquery nomodify
restrict 127.0.0.1
restrict -6 ::1
server 127.127.1.0
fudge 127.127.1.0 stratum 12
server 0.de.pool.ntp.org
server 1.de.pool.ntp.org
server 2.de.pool.ntp.org
server 3.de.pool.ntp.org

Hinweis: die IP 127.127.1.0 stellt für den ntp die lokale Systemzeit dar, d.h. diese wird als Fallback genommen, wenn kein Zeitserver kontaktiert werden kann. Die Ergänzung eines stratum (das ist so etwas wie ein Qualitätsmaß eines Zeitservers) dient dazu, dass im Regelfall die Zeit des Zeitservers verwendet wird, es sei denn, sein stratum ist schlechter als 12, dann wird sein Signal verworfen und die lokale Zeit beibehalten.

 

[Benares]

Mit den Rechten hat das denke ich nichts zu tun.

Mit den Möglichkeiten der ntp.conf hab ich mich noch nicht intensiv beschäftigt. Ich denke, die Zeilen mit -6 haben was mit IPV6 zu tun.
Wieso benutzt du aber 4 Zeilen bei "server ..." anstatt einer mit "server de.pool.ntp.org prefer"? Das ist doch der Sinn eines Pools, da sich die Adressen schonmal ändern könnten.

C:\>nslookup de.pool.ntp.org
...
Name:    de.pool.ntp.org
Addresses:  212.18.3.18, 87.139.126.233, 217.144.143.83, 88.198.244.104

Edit:
Ich hab die Beschreibung mal überflogen. Meines Erachtens könnte notrust beim default ruhig drin bleiben. Ein "restrict <IP>"-Eintrag überschreibt ja den default. Mit "server 127.127.1.0" machst du m.W. auch die lokale Uhr zum Server, das ist sicherlich die ungenauste Quelle. Mir erscheint daher das Original plausibler zu sein, in deinem Fall also mit de.pool.ntp.org anstatt 192.168.0.1, also

restrict default noquery notrust nomodify
restrict -6 default noquery notrust nomodify
restrict 127.0.0.1
restrict -6 ::1
restrict de.pool.ntp.org
server de.pool.ntp.org prefer

Gruß Benares

 

[Frogman]

Hier findet man den Hinweis. Beim Eintrag von de.pool.ntp.org wird nur ein Server abgefragt (genauer gesagt einer der vier, deren IP's Du dort ja zurückbekommst, denn Anfragen auf den Pool werden über Lastverteilung auf 4 aufgeteilt). Trägst Du alle separat ein, werden alle abgefragt und gegeneinander validiert (d.h. Server, die eine große Abweichung von mindestens zwei anderen haben, werden verworfen). Damit ist sichergestellt, dass es auch bei Zeitservern mit einem stratum >1 nicht zu falschen Einstellungen kommt, weil zufällig der betreffende Server (wenn man eben nur einen abfragt) eine zu große Abweichung zum Zeitnormal aus Braunschweig hat.

 

[Benares]

Mmh, das hab ich noch nicht ganz verstanden. Zuerst dachte ich 0.de.pool.ntp.org u.s.w wären die einzelnen Member des Pools, aber es sind wohl wiederum Pools.

C:\>nslookup 0.de.pool.ntp.org
...
Name:    0.de.pool.ntp.org
Addresses:  141.30.228.4, 87.139.126.233, 80.237.238.143, 88.198.36.57

Na ja, was solls, es funktioniert ja, und auf die Microsekunde genau kommt es bei einem NAS ja auch nicht an.

Gruß Benares

 

[Frogman]

Edit:
Ich hab die Beschreibung mal überflogen. Meines Erachtens könnte notrust beim default ruhig drin bleiben. Ein "restrict <IP>"-Eintrag überschreibt ja den default. Mit "server 127.127.1.0" machst du m.W. auch die lokale Uhr zum Server, das ist sicherlich die ungenauste Quelle. Mir erscheint daher das Original plausibler zu sein, in deinem Fall also mit de.pool.ntp.org anstatt 192.168.0.1, also

restrict default noquery notrust nomodify
restrict -6 default noquery notrust nomodify
restrict 127.0.0.1
restrict -6 ::1
restrict de.pool.ntp.org
server de.pool.ntp.org prefer

Gruß Benares

Naja, mit dem stratum von 12 wird die lokale Uhr ja auch sehr niedrig priorisiert - doch das hat den Vorteil, dass bei Netzwerkproblemen nicht auf einen Timeout gewartet werden muß, sondern der Server sich gegen sich selbst synchronisiert und die Abfragen dann zeitig wiederholen kann.
Und prefer macht nur Sinn, wenn Du auch mehrere Server angibst.

Edit: ja, die x.de.pool.ntp.org sind nur 4 Ausgänge einer Lastverteilung, d.h. Unterpools sozusagen.

 

[Frogman]

Noch etwas, was mit bei Verwendung der SSD im Vergleich zu einer Festplatte aufgefallen ist:
nach einem Neustart sieht das Log mit einer FP ungefähr so aus

Oct 21 12:20:37 syslogd started: BusyBox v1.16.1
Oct 21 12:20:37 kernel: [ 0.000000] CPU: Feroceon 88FR131 [56251311] revision 1 (ARMv5TE), cr=00053977
Oct 21 12:20:37 kernel: [ 0.000000] CPU: VIVT data cache, VIVT instruction cache
Oct 21 12:20:37 kernel: [ 0.000000] Machine: Synology 6282 board
Oct 21 12:20:37 kernel: [ 0.000000] Using UBoot passing parameters structure
Oct 21 12:20:37 kernel: [ 0.000000] Sys Clk = 200000000, Tclk = 166666667
Oct 21 12:20:37 kernel: [ 0.000000] Synology Board ID: 27
Oct 21 12:20:37 kernel: [ 0.000000] Memory policy: ECC disabled, Data cache writeback
Oct 21 12:20:37 kernel: [ 0.000000] Built 1 zonelists in Zone order, mobility grouping off. Total pages: 130048
Oct 21 12:20:37 kernel: [ 0.000000] Synology Hareware Version: DS212pv20-j
Oct 21 12:20:37 kernel: [ 0.000000] Internal HD num: 2
Oct 21 12:20:37 kernel: [ 0.000000] Internal netif num: 1
Oct 21 12:20:37 kernel: [ 0.000000] Esata chip use 7042: 1
Oct 21 12:20:37 kernel: [ 0.000000] Console: colour dummy device 80x30
Oct 21 12:20:37 kernel: [ 0.250000] Mount-cache hash table entries: 512
Oct 21 12:20:37 kernel: [ 0.420000]
Oct 21 12:20:37 kernel: [ 0.420000] CPU Interface
...

Mit der SSD sieht's dagegen so aus:

Oct 21 12:20:10 syslogd started: BusyBox v1.16.1
Oct 21 12:20:10 kernel: [ 10.150000] correction with 0x03
Oct 21 12:20:10 kernel: [ 10.250000] Brand: Synology
Oct 21 12:20:10 kernel: [ 10.250000] Model: DS-111
...

Irgendwie verschluckt der 'ne ganze Menge... es läuft aber auch alles...
Hat da jemand eine Idee?

 

[Benares]

Geloggt werden erst die Meldung ab dem Start des syslogd, die Meldungen davor gehen verloren.
Evtl. bootet die Kiste von SSD so schnell, dass sich da zeitlich was verschiebt.

Gruß Benares