DSM 4.0 Beta - Erfahrungen, Probleme, Bugs

[Trolli]

Ich denke, das sollte nach wie vor funktionieren. Zumindest hab ich noch nichts gegenteiliges gehört...

 

[BigBlue007]

Danke. Ich teste und berichte.

 

[joku]

Da mir halt leider der Vergleich zum Betrieb mit DSM 3.2 fehlt, würde ich jetzt mal ein Downgrade auf DSM 3.2 machen

schau die mal die Datei in
/etc/VERSION
und
/etc.defaults/VERSION
an, die /etc.defaults/VERSION wird geladen nach dem 2x reset
*ohne Gewehr*
Gruß Jo

 

[oetzi]

Moin moin,

nachdem das mein erster Post hier im Forum ist (bisher war ich nur sehr interessierter Leser) zunächst mal ein herzliches Grüß Gott und jetzt schon mal vielen Dank für die zahlreichen nützlichen Tipps, die ich hier bis jetzt finden konnte.

Sollte das Problem hier schon mal irgendwo diskutiert worden sein muss ich zu meiner Verteidigung sagen: ich habe ca. 1,5 Stunden lang die Suche bemüht und nix passendes gefunden. Zwar diesen Thread, aber da steht auch keine Lösung. :S

Als altes Spielkind musste ich natürlich auch die 4.0 Beta ausprobieren. Draufspielen war kein Problem. Scheint alles funktioniert zu haben. Dann fing allerdings die Thumbnail-Erzeugung neu an. Bei 40.000 Bilder wollte ich das meiner 210j (und meinen Nerven) nicht antun. Also photo-Ordner erst mal umbenannt und einen neuen angelegt.

Dann wollte ich die Fotos mit dem Foto Uploader aus dem DSAssistant neu hochladen. Das funktionierte eine Weile auch recht gut. Mittlerweile ist es aber regelmäßig so, dass die Verbindung zur DiskStation beim Upload abbricht. Mit dem DSM 3.2 hatte ich das Problem nie.

Anhang anzeigen 7521

Die Weboberfläche der PhotoStation und des DSM kann ich nach einer solchen Meldung ohne Probleme erreichen. Abhilfe für den Foto Uploader schafft dann nur, wenn ich den Client-Rechner und die DiskStation neu starten. Kann dann aber durchaus sein, dass das Problem sofort (oder nach einigen Hundert Bildern) erneut auftritt.

Nen Bug bei Synology habe ich schon aufgemacht (Bug-ID #4059). Mal sehen, was die dazu sagen.

Hier noch ein paar technische Details:
- DiskStation 210j mit DSM 4.0 Beta
- Aktueller DSAssistant (kann grad net die genaue Version sagen, da ich nicht daheim bin. Ist aber vor ca. 1 Woche runtergeladen worden)
- Gigabit-Netzwerk (JUMBO-Frame ist sowohl auf der DS, als auch auf dem Client deaktiviert)
- Client-Rechner: Windows 7 64Bit mit 12GB Ram
- Rechner ist mit der DS über eine FritzBox 6360 verbunden

Zu dem Thema /var/log/messages:
Mir ist auch aufgefallen, dass da jetzt wesentlich mehr drin steht als noch mit der 3.2er-DSM-Version. Ich war davon ausgegangen, dass sie vielleicht einfach das Log-Level in der Beta etwas hochgedreht haben. Na ja, da will ich ihnen mal net den Kopf abreißen. Immerhin ist es im Moment noch offiziell ne Beta. Da erwarte ich noch nicht, dass alles funktioniert.

So,
ich antworte mir dann mal selbst.
Problem bei mir war anscheinend, dass meine Systempartition voll war (es ist einfach keine gute Idee seinen User-Apache loggen zu lassen ). Habs festgestellt, als ich frustriert wieder nen downgrade auf die 3.2 machen wollte. Systempartition freigeräumt, alles funzt.

 

[BigBlue007]

So, ich bin inzw. auch weitergekommen. Downgrade auf 3.2 hat problemlos funktioniert. Und jetzt ist alles, was im Log bei einem Wakeup zu sehen ist, dieses:

Feb  6 19:40:59 scemd: SCEMD: disk 1 wake up from hibernation
Feb  6 19:41:17 scemd: SCEMD: disk 2 wake up from hibernation

Also eindeutig ein DSM 4 Beta - Problem. Nachtrag zum Ticket ist raus.

 

[BrokenPipe]

Hi,
ich habe auch das write-cache Problem. Im DSM werden die Haken immer wieder entfernt, also hab ich das ganze per ssh ausprobiert:

DiskStation> hdparm -W 1 /dev/sda

/dev/sda:
 setting drive write-caching to 1 (on)
 write-caching =  1 (on)
DiskStation> hdparm -W 1 /dev/sdb

/dev/sdb:
 setting drive write-caching to 1 (on)
 write-caching =  0 (off)
DiskStation> hdparm -W /dev/sda  

/dev/sda:
 write-caching =  1 (on)
DiskStation> hdparm -W /dev/sdb

/dev/sdb:
 write-caching =  0 (off)

Also bei sda konnte ich den write-cache einschalten aber bei sdb nicht und das DSM zeigt immer noch keine Haken an.

Wurde das Problem schon an Synology gemeldet?

DS211j
2x WD20EARS

 

[Matthieu]

Wurde das Problem schon an Synology gemeldet?

Jeder sollte sein Problem selbst an Synology melden, denn es können unterschiedliche Ursachen sein und mit etwas Glück kann man auch schon einen Patch testen.

MfG Matthieu

 

[Mikel]

Im Standby (nur Status-LED ist an und blinkt) meiner DS212+ läuft der Lüfter jetzt immer noch, unter Einstellungen in "Energie" hab ich "stiller Modus" und auch "niedriger Energiestatus" ausporbiert, keine Änderung. Könnte schwören, dass das unter 3.2 nicht so war, oder vertue ich mich da?

Der läuft grundsätzlich immer !

Ich habe erst jetzt im Forum danach gesucht, weils mir erst gestern aufgefallen ist.

Bei meiner 211+ war es definitiv unter der 3.2 so, dass der Lüfter nach kurzer Zeit auch ausgegangen ist, wenn die DS im Standby (incl. HDs) war.
Dies war auch im Sommer so, wenn die Raumtemperatur höher war und sollte demnach jetzt erst recht so sein.
Die Einstellung im Reiter Energie ist/war auf "niedriger Energiestatus".

Jetzt, unter der 4.0 Beta, dreht der Lüfter immer, egal welche Einstellung.
Schade, denn er ist zwar recht leise, aber vorher war es eben noch besser.

 

[Puppetmaster]

Ich habe erst jetzt im Forum danach gesucht, weils mir erst gestern aufgefallen ist.

Bei meiner 211+ war es definitiv unter der 3.2 so, dass der Lüfter nach kurzer Zeit auch ausgegangen ist, wenn die DS im Standby (incl. HDs) war.
Dies war auch im Sommer so, wenn die Raumtemperatur höher war und sollte demnach jetzt erst recht so sein.
Die Einstellung im Reiter Energie ist/war auf "niedriger Energiestatus".

Jetzt, unter der 4.0 Beta, dreht der Lüfter immer, egal welche Einstellung.
Schade, denn er ist zwar recht leise, aber vorher war es eben noch besser.

Danke für diesen Hinweis!
Irgendwer hatte hier bereits geschrieben, daß der Lüfter der DS212+ auch im StandBy dreht. Das kann ich nicht bestätigen! Mir war es von Anfang an wichtig, daß bei meiner DS212+ der Lüfter im Standby eben NICHT läuft (wozu auch? CPU-Last gleich null, Systemtemperatur laut Sensor um die 50°C - also völlig ok). Ich habe allerdings 2 2,5 Zoll Platten verbaut, die erzeugen auch wenig Abwärme.
Es ist mir im Übrigen auch noch kein Unterschied bei den 3 Energiemodi aufgefallen. Damals (DSM 3.0 ??) als es nur 2 Einstellungen '3,5 Zoll' und '2,5 Zoll' gab, da merkte man einen Unterschied. Seit es diese drei Optionen gibt, nicht mehr.

Wenn also tatsächlich auch in der Final der Lüfter ständig laufenn würde, fände ich das sehr bedauerlich. Gut, er ist nicht laut, aber man hört ihn doch. Und notwendig wird es auch nicht sein... Da ärgere ich mich bei meinem *ähem* QNAP NAS schon drüber, daß der Lüfter niemals ausgeht!

Bei meiner DS110j, bei der ich die Beta seit Erscheinen ausprobiere, geht der Lüfter übrigens auch mit Beta 4.0 aus!

Ich habe da auch noch ein nervendes Winterproblem entdeckt - allerdings noch bei DSM3.2, wird aber bei der 4.0 sicher nicht ander sein:
Wenn die DS212+ läuft, also nicht im StandBy ist, und ich mal für ein paar Minuten die Türe zum Lüften öffne, wird der Guten offenbar so kalt, daß der Lüfter ausgeht. Zumindest bekomme ich die Warntöne und je nach dem 2-8 Mails mit Lüfter angehalten/Lüfter wieder gestartet.
Da sollte vielleicht auch nochmal ein Tempeprturabgleich auf Softwareebene erfolgen, sprich: wenn Lüfter anhält, Raum-/Systemtemperatur aber < 20°C, dann ist das kein Grund zur Besorgnis!

 

[itari]

die Geschichte mit der intelligenten Temperatursteuerung solltest den Synology-Entwicklern vorschlagen, das ist ganz sicherlich ein Wunsch, den viele hier haben.

Itari

 

[Trolli]

Mir ist gerade ein Problem mit Time Backup aufgefallen. Hat jemand schonmal etwas ähnliches beobachtet?
Aus der /var/log/messages:

Feb 8 12:05:02 kernel: [324992.326368] EXT4-fs: can't allocate buddy meta groupFeb 8 12:05:02 kernel: [324992.331553] EXT4-fs (dm-1): failed to initalize mballoc (-12)
Feb 8 12:05:02 kernel: [324992.338100] EXT4-fs (dm-1): mount failed
Feb 8 12:05:02 kernel: [324992.409453] BUG: unable to handle kernel NULL pointer dereference at 00000000000001e0
Feb 8 12:05:02 kernel: [324992.409827] IP: [<ffffffff8112ea87>] ext4_clear_inode+0x17/0x40
Feb 8 12:05:02 kernel: [324992.409827] PGD 684c067 PUD 17988067 PMD 0
Feb 8 12:05:02 kernel: [324992.409827] Oops: 0000 [#1] SMP
Feb 8 12:05:02 kernel: [324992.409827] last sysfs file: /sys/block/md2/md/dev-sdc3/slot
Feb 8 12:05:02 kernel: [324992.409827] CPU 0
Feb 8 12:05:02 kernel: [324992.409827] Modules linked in: snd_pcm_oss snd_mixer_oss snd_usb_audio snd_pcm snd_timer snd_hwdep snd_usbmidi_lib snd_rawmidi snd_seq_device snd snd_page_alloc soundcore cifs udf isofs loop usbhid hid usblp usb_storage uhc
Feb 8 12:05:02 kernel: [324992.409827] Process mount (pid: 7702, threadinfo ffff880022104000, task ffff88003df26870)
Feb 8 12:05:02 kernel: [324992.409827] Stack:
Feb 8 12:05:02 kernel: [324992.409827] ffff88001252a0c0 ffffffff810b3f7f ffff88001252a0c0 ffffffff810b419c
Feb 8 12:05:02 kernel: [324992.409827] <0> ffff880019fa0ec0 ffffffff810b177d 0000000000008001 00000000ffffffff
Feb 8 12:05:02 kernel: [324992.409827] <0> ffff880022388000 ffffffff81436ca0 ffffffff813386e0 0000000000000001
Feb 8 12:05:02 kernel: [324992.409827] Call Trace:
Feb 8 12:05:02 kernel: [324992.409827] [<ffffffff810b3f7f>] ? clear_inode+0x5f/0xe0
Feb 8 12:05:02 kernel: [324992.409827] [<ffffffff810b419c>] ? generic_drop_inode+0x2c/0x60
Feb 8 12:05:02 kernel: [324992.409827] [<ffffffff810b177d>] ? shrink_dcache_for_umount_subtree+0x18d/0x260
Feb 8 12:05:02 kernel: [324992.409827] [<ffffffff810b1879>] ? shrink_dcache_for_umount+0x29/0x50
Feb 8 12:05:02 kernel: [324992.409827] [<ffffffff8109eaa5>] ? generic_shutdown_super+0x25/0x100
Feb 8 12:05:02 kernel: [324992.409827] [<ffffffff8109eba9>] ? kill_block_super+0x29/0x50
Feb 8 12:05:02 kernel: [324992.409827] [<ffffffff8112cf29>] ? ext4_kill_sb+0x9/0x30
Feb 8 12:05:02 kernel: [324992.409827] [<ffffffff8109f028>] ? deactivate_locked_super+0x58/0x80
Feb 8 12:05:02 kernel: [324992.409827] [<ffffffff8109fde1>] ? get_sb_bdev+0x191/0x1a0
Feb 8 12:05:02 kernel: [324992.409827] [<ffffffff81130b30>] ? ext4_fill_super+0x0/0x2520
Feb 8 12:05:02 kernel: [324992.409827] [<ffffffff8109f0a6>] ? vfs_kern_mount+0x56/0xf0
Feb 8 12:05:02 kernel: [324992.409827] [<ffffffff8109f1a3>] ? do_kern_mount+0x53/0x120
Feb 8 12:05:02 kernel: [324992.409827] [<ffffffff810b976f>] ? do_mount+0x4ff/0x810
Feb 8 12:05:02 kernel: [324992.409827] [<ffffffff810d9d19>] ? compat_sys_mount+0xa9/0x290
Feb 8 12:05:02 kernel: [324992.409827] [<ffffffff8102a052>] ? ia32_sysret+0x0/0x5
Feb 8 12:05:02 kernel: [324992.409827] Code: db 3b 81 48 89 ef e8 79 b2 f8 ff e9 db fb ff ff 66 66 66 90 53 48 89 fb e8 e7 12 01 00 48 8b 83 40 01 00 00 48 8b 80 88 02 00 00 <48> 8b b8 e0 01 00 00 48 85 ff 74 0d 48 8d b3 78 02 00 00 5b e9
Feb 8 12:05:02 kernel: [324992.409827] RIP [<ffffffff8112ea87>] ext4_clear_inode+0x17/0x40
Feb 8 12:05:02 kernel: [324992.409827] RSP <ffff880022105cb8>
Feb 8 12:05:02 kernel: [324992.409827] CR2: 00000000000001e0
Feb 8 12:05:02 kernel: [324992.775209] ---[ end trace b404809f1be7bc3a ]---
Feb 8 12:05:02 timebkp: [7684]BK_ERR:mount snapshot [/dev/mapper/vol1-snap0] on mount_point [/tmp/timebkp_7684/volume1] failed
Feb 8 12:05:02 kernel: [324992.910581] device-mapper: ioctl: unable to remove open device vol1-snap0
Feb 8 12:05:02 timebkp: [7684]BK_ERR:delete snapshot device vol1-snap0 failed
Feb 8 12:05:02 timebkp: [7684]BK_ERR:remove loop device /dev/loop0 fail: Device or resource busy(16) : 16(Device or resource busy)
Feb 8 12:05:02 timebkp: [7684]BK_WARN:creating snapshot of volume1 failed
Feb 8 12:05:02 timebkp: [7684]BK_WARN:no snapshot has been created

 

[itari]

@trolli,

kannst du den Fehler reproduzieren? und tritt er auch nach einem Neustart noch auf?

Itari

 

[Trolli]

Ist jetzt zum ersten Mal aufgetreten. Ich werde das weiter beobachten und berichten...

 

[rauppe31]

Hab jetzt auch mal in meine Log-Datei geschaut.
Ich habe dort auch komische Einträge von Time Backup entdeckt:

Feb 8 12:00:27 timebkp: [15614]BK_ERR:div trap
Feb 8 12:00:32 timebkp: [15614]BK_ERR:div trap
Feb 8 12:00:33 timebkp: [15614]BK_ERR:div trap
Feb 8 12:00:44 timebkp: [15614]BK_ERR:div trap
Feb 8 12:00:45 timebkp: [15614]BK_ERR:div trap
Feb 8 12:00:46 timebkp: [15614]BK_ERR:div trap
Feb 8 12:00:47 timebkp: [15614]BK_ERR:div trap
Feb 8 12:00:48 timebkp: [15614]BK_ERR:div trap
Feb 8 12:00:49 timebkp: [15614]BK_ERR:div trap
Feb 8 12:00:50 timebkp: [15614]BK_ERR:div trap
Feb 8 12:00:53 timebkp: [15614]BK_ERR:div trap
Feb 8 12:00:54 timebkp: [15614]BK_ERR:div trap
Feb 8 12:00:55 timebkp: [15614]BK_ERR:div trap
Feb 8 12:00:56 timebkp: [15614]BK_ERR:div trap
Feb 8 12:00:57 timebkp: [15614]BK_ERR:div trap
Feb 8 12:01:04 timebkp: [15614]BK_ERR:div trap
Feb 8 12:01:05 timebkp: [15614]BK_ERR:div trap
Feb 8 12:01:08 timebkp: [15614]BK_ERR:div trap
Feb 8 12:01:09 timebkp: [15614]BK_ERR:div trap
Feb 8 12:01:10 timebkp: [15614]BK_ERR:div trap
Feb 8 12:01:14 timebkp: [15614]BK_ERR:div trap
Feb 8 12:01:15 timebkp: [15614]BK_ERR:div trap
Feb 8 12:01:16 timebkp: [15614]BK_ERR:div trap
Feb 8 12:01:18 timebkp: [15614]BK_ERR:div trap
Feb 8 12:01:20 timebkp: [15614]BK_ERR:div trap
Feb 8 12:01:21 timebkp: [15614]BK_ERR:div trap
Feb 8 12:01:22 timebkp: [15614]BK_ERR:div trap

Das passiert jedes mal, wenn Time Backup sich startet.
Jemand eine Idee, was das sein könnte?

 

[Trolli]

Die Einträge hab ich auch - ich hab das mal als 'normal' angesehen. Aber was damit gemeint ist, weiß ich nicht wirklich...

 

[trox]

Hallo, habe eben dieses Mail von meiner DS erhalten...

The hard disk 4 on DiskStation had an I/O error, but it is working properly now after several retries. It might have been caused by bad sectors. If this error occurs again, please back up your data and run the S.M.A.R.T. test on your hard drive to examine the hard drive status.

Im Dmesg-Log steht folgendes:

[19441.017284] ata4.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x6 frozen
[19441.024346] ata4.00: failed command: READ FPDMA QUEUED
[19441.029497] ata4.00: cmd 60/48:00:00:b3:ba/00:00:85:00:00/40 tag 0 ncq 36864 in
[19441.029502] res 40/00:00:00:fb:00/00:00:00:00:00/a0 Emask 0x4 (timeout)
[19441.044197] ata4.00: status: { DRDY }
[19441.047865] ata4: hard resetting link
[19441.507325] ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[19441.557376] ata4.00: configured for UDMA/133
[19441.561653] ata4.00: device reported invalid CHS sector 0
[19441.567064] sd 3:0:0:0: [sdd] Result: hostbyte=0x00 driverbyte=0x08
[19441.573338] sd 3:0:0:0: [sdd] Sense Key : 0xb [current] [descriptor]
[19441.579711] Descriptor sense data with sense descriptors (in hex):
[19441.585891] 72 0b 00 00 00 00 00 0c 00 0a 80 00 00 00 00 00
[19441.592317] 00 00 00 00
[19441.595562] sd 3:0:0:0: [sdd] ASC=0x0 ASCQ=0x0
[19441.600012] sd 3:0:0:0: [sdd] CDB: cdb[0]=0x28: 28 00 85 ba b3 00 00 00 48 00
[19441.607203] end_request: I/O error, dev sdd, sector 2243605248
[19441.613044] read error, md2, sdd3 index [3], sector 6702498048 [raid5_align_endio]
[19441.620619] read error, md2, sdd3 index [3], sector 6702498056 [raid5_align_endio]
[19441.628191] read error, md2, sdd3 index [3], sector 6702498064 [raid5_align_endio]
[19441.635776] ata4: EH complete
[19441.775250] read error corrected, md2, sdd3 index [3], sector 2243605256 [raid5_end_read_request]
[19441.784151] raid5:md2: read error corrected (8 sectors at 2234168064 on sdd3)
[19441.791298] read error corrected, md2, sdd3 index [3], sector 2243605264 [raid5_end_read_request]
[19441.800169] raid5:md2: read error corrected (8 sectors at 2234168072 on sdd3)
[19441.807306] read error corrected, md2, sdd3 index [3], sector 2243605272 [raid5_end_read_request]
[19441.816177] raid5:md2: read error corrected (8 sectors at 2234168080 on sdd3)

Ein kurzer SMART Test zeigt den Status normal an. Current-Pending-Sector-Count und Reallocated-Sector-Count zeigen beide 0 an.
Werde morgen ein Downgrade auf DSM 3.2 durchführen, keine Lust irgendwelche Dateien zu vom Backup restoren zu müssen.
Habe eigentlich nur wegen dem ungelösten Kopierfehler "First copy stops" * von DSM 3.2 auf 4 updated.
* http://forum.synology.com/enu/viewtopic.php?f=187&t=41044

 

[BigBlue007]

Wie weiter oben schon mehrfach berichtet und IMHO inzw. auch mit einiger Sicherheit bestätigt, handelt es sich hierbei um einen Bug in DSM 4.0. Der Fehler ist nach einem Downgrade auf 3.2 weg. Ich habe das Problem bereits gemeldet, andere sicher auch schon, aber es sollte eigentlich JEDER sein Problem individuell melden, schon allein, damit die sehen, dass es wirklich ein Problem in der Fläche und nicht nur bei 2 Leuten ist.

 

[trox]

Hi, habe meins auch schon gemeldet. Gruss

#3954
Since the DSM 4.0 update, I have kernel-errormessages like this:
"ata3.00: device reported invalid CHS sector 0"
"ata3.00: failed command: READ FPDMA QUEUED"
This seems to be kernel related, not hardware-fault.

 

[goetz]

Hallo,
BUG!
Wenn im VPN Center OpenVPN und/oder PPTP aktiviert ist/sind und man den HotSpot einschaltet verschwinden die NAT Regeln für VPN, somit ist nur noch die DS per VPN erreichbar, das restliche lokale Netz nicht.
Vorher, nur VPN

DS411plusII> iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
MASQUERADE  all  --  10.8.0.0/24          anywhere
MASQUERADE  all  --  10.0.0.0/24          anywhere

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

nach Aktivierung des HotSpot

DS411plusII> iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
MASQUERADE  all  --  10.1.14.0/23         anywhere
MASQUERADE  all  --  10.1.14.0/23         anywhere

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Andersherum funktioniert es, also HotSpot ein und dann VPN einschalten.
Report ist raus.

Gruß Götz

 

[Trolli]

@trolli,

kannst du den Fehler reproduzieren? und tritt er auch nach einem Neustart noch auf?

Itari

Gestern Abend ist Time Backup dann ohne Fehler durchgelaufen - heute morgen wieder das gleiche Problem. Auch nach einem Neustart konnte ich keine manuelle Time Backup Sicherung durchführen...