Hallo zusammen,
ich habe jetzt lange genug hier im Forum gestöbert, google bemüht etc. etc. und bin trotzdem zu keine Lösung gekommen, deswegen hoffe ich jetzt, dass hier jemand ist, der mir weiterhelfen kann.
Habe heute morgen meine DS412+ auf DSM 5.0 geupdatet.
Das lief so glatt und super, dass ich mir dachte: "Jetzt aktualisiere ich die DS212+, in deren Netz ich einen VPN-Tunnel habe, gleich noch mit."
Gesagt, getan, und damit ging der Ärger los. Update verlief fehlerfrei, ich kann in den Logs keine Indizien für einen schwerwiegenden Fehler entdecken:
Nach dem Reboot ließ er mich dann schonmal nicht ins Admin-Interface, und zeigte nach der Eingabe von user/pw, dass das Interface "vorbereitet" würde, ich solle mich doch bitte später anmelden.
Also habe ich mich mit SSH (root) auf der Kommandozeile eingeloggt, und mit "top" nachgesehen, was er denn so treibt.
Da ist mir zunächst der Prozess "scemd" durch seine 100% CPU-Last aufgefallen( außerdem die Prozesse "md2_resync" und "md2_raid1", die hin und wieder mit 10-20% CPU-Last nach oben kommen) und dann ist das NAS auch schon zum 1. Mal abgeschmiert und war nicht mehr erreichbar.
Nach wenigen Minuten hat sich dasselbe Spiel wiederholt, interessante Feststellung nebenbei:
Sobald scemd seine Arbeit gemacht hat und die CPU-Last fällt, kommt es praktisch sofort zum Absturz.
Folglich ist es wohl irgendetwas, dass damit in Zusammenhang steht, vielleicht irgendwas, was unmittelbar danach ausgeführt wird.
Nach ein paar Runden habe ich scemd zum 1. Mal beherzt mit "kill" abgeschossen, was unmittelbar zum Absturz geführt hat.
Bei einem weiteren Versuch habe ich es dann tatsächlich geschafft, mich anzumelden, bevor der Absturz kam.
Diese Session scheint durch alle Abstürze hinweg offen zu bleiben, was mich sehr verwundet hat. Seitdem kann ich das Interface immer 2-3 Minuten nutzen...
Das Kuriose: ALLE DIENSTE FUNKTIONIEREN (natürlich nur in der kurzen Zeit bis zum Absturz)!
SSH, Samba, das Admin-Inferface, alles überhaupt kein Thema...
Die Dateien sind auch alle da, ich vermisse eigentlich nichts außer ein stabiles System.
ich habe jetzt lange genug hier im Forum gestöbert, google bemüht etc. etc. und bin trotzdem zu keine Lösung gekommen, deswegen hoffe ich jetzt, dass hier jemand ist, der mir weiterhelfen kann.
Habe heute morgen meine DS412+ auf DSM 5.0 geupdatet.
Das lief so glatt und super, dass ich mir dachte: "Jetzt aktualisiere ich die DS212+, in deren Netz ich einen VPN-Tunnel habe, gleich noch mit."
Gesagt, getan, und damit ging der Ärger los. Update verlief fehlerfrei, ich kann in den Logs keine Indizien für einen schwerwiegenden Fehler entdecken:
Code:
Mar 13 09:53:05 FCG_SERVER upgrade.cgi: UnpackFirmware: Clean //upd@te.pat...
Mar 13 09:53:10 FCG_SERVER upgrade.cgi: upgrade.cpp:(1033): Verify checksum of [//upd@te]...
Mar 13 09:53:12 FCG_SERVER upgrade.cgi: upgrade.cpp:(1040): Pass checksum of //upd@te...
Mar 13 09:53:12 FCG_SERVER upgrade.cgi: upgrade.cpp:1022 Executing [//upd@te/updater -v / -x > /dev/null 2>&1]
Mar 13 09:53:12 FCG_SERVER updater: updater.c:4890 Start of the updater...
Mar 13 09:53:12 FCG_SERVER updater: updater.c:5020 This is junior, gszDevMtdPartition=[/dev/mtd5]
Mar 13 09:53:12 FCG_SERVER updater: updater.c:2378 orgBuildNumber = 3827, newBuildNumber=4458
Mar 13 09:53:12 FCG_SERVER updater: updater.c:2466 [CheckPackageSize] Find [1] internal volume, external volume count= [0]
Mar 13 09:53:12 FCG_SERVER updater: updater.c:2483 CheckPackageSize, err=0
Mar 13 09:53:12 FCG_SERVER updater: updater.c:3128 SYNORedBootUpdCheckAndApply(3128): Skip bootloader update, no uboot_do_upd.sh exists
Mar 13 09:53:12 FCG_SERVER updater: updater.c:5342 number of partitions = [6]
Mar 13 09:53:12 FCG_SERVER updater: updater.c:5347 [RedBoot] 0xF8000000 0x00080000 0x00072A14
Mar 13 09:53:12 FCG_SERVER updater: updater.c:5347 [zImage] 0xF8080000 0x00200000 0x0017F95C
Mar 13 09:53:12 FCG_SERVER updater: updater.c:5347 [rd.gz] 0xF8280000 0x00140000 0x000E4275
Mar 13 09:53:12 FCG_SERVER updater: updater.c:5347 [vendor] 0xF83C0000 0x00010000 0x00010000
Mar 13 09:53:12 FCG_SERVER updater: updater.c:5347 [RedBoot Config] 0xF83D0000 0x00020000 0x00020000
Mar 13 09:53:12 FCG_SERVER updater: updater.c:5347 [FIS directory] 0xF83F0000 0x00010000 0x00000600
Mar 13 09:53:12 FCG_SERVER updater: flashsize = 0x00400000, eraseblock = 0x00010000
Mar 13 09:53:12 FCG_SERVER updater: UPDTInitPatchInfo(3254): file [RedBoot.msys] not included in the patch package
Mar 13 09:53:12 FCG_SERVER updater: PATCHINFO: part[RedBoot] file[RedBoot.msys] start = [0xF8000000] size[0x524288] datalen=[0x00072A14] nblock[0] balance[0] fneedupdate[0]
Mar 13 09:53:12 FCG_SERVER updater: PATCHINFO: part[zImage] file[zImage] start = [0xF8080000] size[0x2097152] datalen=[0x001967D0] nblock[26] balance[6] fneedupdate[1]
Mar 13 09:53:12 FCG_SERVER updater: PATCHINFO: part[rd.gz] file[rd.bin] start = [0xF8280000] size[0x1310720] datalen=[0x000F2175] nblock[16] balance[4] fneedupdate[1]
Mar 13 09:53:12 FCG_SERVER updater: UPDTInitPatchInfo(3254): file [vendor] not included in the patch package
Mar 13 09:53:12 FCG_SERVER updater: PATCHINFO: part[vendor] file[vendor] start = [0xF83C0000] size[0x65536] datalen=[0x00010000] nblock[0] balance[0] fneedupdate[0]
Mar 13 09:53:12 FCG_SERVER updater: UPDTInitPatchInfo(3254): file [RedBoot Config] not included in the patch package
Mar 13 09:53:12 FCG_SERVER updater: PATCHINFO: part[RedBoot Config] file[RedBoot Config] start = [0xF83D0000] size[0x131072] datalen=[0x00020000] nblock[0] balance[0] fneedupdate[0]
Mar 13 09:53:12 FCG_SERVER updater: UPDTInitPatchInfo(3254): file [FIS Directory] not included in the patch package
Mar 13 09:53:12 FCG_SERVER updater: PATCHINFO: part[FIS Directory] file[FIS Directory] start = [0xF83F0000] size[0x65536] datalen=[0x00000600] nblock[0] balance[0] fneedupdate[0]
Mar 13 09:53:12 FCG_SERVER updater: szCmd=[/bin/rm -rf /upd@te/b@ckup; /bin/mkdir -p /upd@te/b@ckup]
Mar 13 09:53:12 FCG_SERVER updater: UPDTBackupOldPartition(3349): command=[/bin/dd if="/dev/mtd0" of="/upd@te/b@ckup/mtd_RedBoot" bs=16384]
Mar 13 09:53:13 FCG_SERVER updater: UPDTBackupOldPartition(3349): command=[/bin/dd if="/dev/mtd1" of="/upd@te/b@ckup/mtd_zImage" bs=16384]
Mar 13 09:53:14 FCG_SERVER updater: UPDTBackupOldPartition(3349): command=[/bin/dd if="/dev/mtd2" of="/upd@te/b@ckup/mtd_rd.gz" bs=16384]
Mar 13 09:53:15 FCG_SERVER updater: UPDTBackupOldPartition(3349): command=[/bin/dd if="/dev/mtd3" of="/upd@te/b@ckup/mtd_vendor" bs=16384]
Mar 13 09:53:15 FCG_SERVER updater: UPDTBackupOldPartition(3349): command=[/bin/dd if="/dev/mtd4" of="/upd@te/b@ckup/mtd_RedBoot Config" bs=16384]
Mar 13 09:53:15 FCG_SERVER updater: UPDTBackupOldPartition(3349): command=[/bin/dd if="/dev/mtd5" of="/upd@te/b@ckup/mtd_FIS directory" bs=16384]
Mar 13 09:53:15 FCG_SERVER updater: UPDTDoPatch: skip updating [RedBoot]
Mar 13 09:53:15 FCG_SERVER updater: updater.c:3450(UPDTDoPatch) Try to Erase MTD Partition(/dev/mtd1), [0/3]...
Mar 13 09:53:40 FCG_SERVER updater: updater.c:3461(UPDTDoPatch) Try to Write MTD Partition(/dev/mtd1), [0/3]...
Mar 13 09:53:46 FCG_SERVER updater: updater.c:3467(UPDTDoPatch) Try to Verify MTD Partition(/dev/mtd1), [0/3]...
Mar 13 09:53:49 FCG_SERVER updater: UPDTDoPatch: Finish updating [zImage]
Mar 13 09:53:49 FCG_SERVER updater: updater.c:3450(UPDTDoPatch) Try to Erase MTD Partition(/dev/mtd2), [0/3]...
Mar 13 09:54:05 FCG_SERVER updater: updater.c:3461(UPDTDoPatch) Try to Write MTD Partition(/dev/mtd2), [0/3]...
Mar 13 09:54:10 FCG_SERVER updater: updater.c:3467(UPDTDoPatch) Try to Verify MTD Partition(/dev/mtd2), [0/3]...
Mar 13 09:54:12 FCG_SERVER updater: UPDTDoPatch: Finish updating [rd.gz]
Mar 13 09:54:12 FCG_SERVER updater: UPDTDoPatch: skip updating [vendor]
Mar 13 09:54:12 FCG_SERVER updater: UPDTDoPatch: skip updating [RedBoot Config]
Mar 13 09:54:12 FCG_SERVER updater: UPDTDoPatch: skip updating [FIS Directory]
Mar 13 09:54:12 FCG_SERVER updater: updater.c:4410 Decompress hda1.tgz to SynoUpgrade.tar
Mar 13 09:54:46 FCG_SERVER updater: updater.c:4212 successfully backup image for System Migration in path (/tmpRoot/.syno/patch).
Mar 13 09:54:46 FCG_SERVER updater: libconfigupdate.c:98 Original info before upgrade, dsmversion: 3827, smallfixnumber: 0, event: all
Mar 13 09:54:46 FCG_SERVER updater: updater_lib.c:144 UpdateUnlinkManUtil, err: 0
Mar 13 09:54:46 FCG_SERVER updater: updater_lib.c:160 UpdateUnlinkOldPHPConf, err: 0
Mar 13 09:54:46 FCG_SERVER updater: updater_lib.c:183 UpdateCrondConf
Mar 13 09:54:46 FCG_SERVER updater: update zoneinfo: Amsterdam
Mar 13 09:54:46 FCG_SERVER updater: libconfigupdate.c:28 update config for version: 4000
usw. usw.
Mar 13 09:55:01 FCG_SERVER updater: libconfigupdate.c:28 update config for version: 4432
Mar 13 09:55:01 FCG_SERVER updater: service_conf_ports_set.c:95 Configure file (/usr/syno/etc/services.d/versionbkp_server.sc) does not exist![0x0D00 string_sep_pair.c:54]
Mar 13 09:55:01 FCG_SERVER updater: updater_lib.c:5979 failed to change port for img backup [No such file or directory][0x0D00 string_sep_pair.c:54]
Mar 13 09:55:01 FCG_SERVER updater: libconfigupdate.c:28 update config for version: 4436
usw. usw.
Mar 13 09:55:01 FCG_SERVER updater: libconfigupdate.c:28 update config for version: 4456
Mar 13 09:55:01 FCG_SERVER updater: updater.c:5414 Congratulation!! The update has been completed!!
Mar 13 09:55:31 FCG_SERVER upgrade.cgi: upgrade.cpp:492 Reboot system
Nach dem Reboot ließ er mich dann schonmal nicht ins Admin-Interface, und zeigte nach der Eingabe von user/pw, dass das Interface "vorbereitet" würde, ich solle mich doch bitte später anmelden.
Also habe ich mich mit SSH (root) auf der Kommandozeile eingeloggt, und mit "top" nachgesehen, was er denn so treibt.
Da ist mir zunächst der Prozess "scemd" durch seine 100% CPU-Last aufgefallen( außerdem die Prozesse "md2_resync" und "md2_raid1", die hin und wieder mit 10-20% CPU-Last nach oben kommen) und dann ist das NAS auch schon zum 1. Mal abgeschmiert und war nicht mehr erreichbar.
Nach wenigen Minuten hat sich dasselbe Spiel wiederholt, interessante Feststellung nebenbei:
Sobald scemd seine Arbeit gemacht hat und die CPU-Last fällt, kommt es praktisch sofort zum Absturz.
Folglich ist es wohl irgendetwas, dass damit in Zusammenhang steht, vielleicht irgendwas, was unmittelbar danach ausgeführt wird.
Nach ein paar Runden habe ich scemd zum 1. Mal beherzt mit "kill" abgeschossen, was unmittelbar zum Absturz geführt hat.
Bei einem weiteren Versuch habe ich es dann tatsächlich geschafft, mich anzumelden, bevor der Absturz kam.
Diese Session scheint durch alle Abstürze hinweg offen zu bleiben, was mich sehr verwundet hat. Seitdem kann ich das Interface immer 2-3 Minuten nutzen...
Das Kuriose: ALLE DIENSTE FUNKTIONIEREN (natürlich nur in der kurzen Zeit bis zum Absturz)!
SSH, Samba, das Admin-Inferface, alles überhaupt kein Thema...
Die Dateien sind auch alle da, ich vermisse eigentlich nichts außer ein stabiles System.