Synology DS718+ pada

Zpráva

#1 Příspěvek od **rnbw** » 04 úno 2022, 22:45

Mam tu Synology DS718+ so zahadnym problemom.

Zapnem bez disku, normalne to nabootuje do instalacneho modu. Vlozim disk, vytvori si systemove particie, stiahne si to z webu DSM a nainstaluje. Po restarte to takmer cele nabootuje, ale potom spadne. Niekedy sa to dostane az po pipnutie, ale vacsinou nie.

Mam pripojenu seriovu konzolu - vidim, ako sa spusti GRUB (je tam x86 CPU - Celeron J3455) a bootuje Linux. Chyba v momente padu je vzdy ina - napr. "unable to handle kernel NULL pointer dereference", ci "Bad page map in process" alebo aj "invalid opcode".

Vyzeralo to ako vadna RAM. Je tam 2GB PC3L SODIMM. Vymenil som ju, ale problem zostal

Co s tym moze byt? Skusal som aj starsiu verziu DSM 6.2 - pada to rovnako. Napajanie CPU vyzera OK aj na osciloskope.

xsc · #2 Příspěvek od **xsc** » 04 úno 2022, 23:00

Nebude spíš problém s tím řadičem disků? Pokud si pamatuju, tak na téhle Intelí platformě je nějaká chyba, takže po nějakém čase umřou.

#3 Příspěvek od **rnbw** » 04 úno 2022, 23:34

Nie su tam ziadne SATA chyby.
Tato generacia CPU vraj moze mat problem s LPC, RTC a SD interface.

Skusim tam nejako dostat memtest86+ a spustit. Mal by podporovat aj seriovu konzolu.

#4 Příspěvek od **rnbw** » 05 úno 2022, 13:40

Zabil by som tie hovada, ktore zoberu Linux, ale musia ho za kazdu cenu nejako skurvit. Vratane formatu dat na diskoch.

Vyzera to ako bezny mdraid:

Kód: Vybrat vše

# fdisk -l /dev/sdb
Disk /dev/sdb: 74.51 GiB, 80000000000 bytes, 156250000 sectors
Disk model: Hitachi HDS72168
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x574cde87

Device     Boot   Start     End Sectors  Size Id Type
/dev/sdb1          2048 4982527 4980480  2.4G fd Linux raid autodetect
/dev/sdb2       4982528 9176831 4194304    2G fd Linux raid autodetect

Lenze to nefunguje:

Kód: Vybrat vše

# mdadm -Asf
mdadm: No arrays found in config file or automatically
# mdadm --assemble /dev/md0 /dev/sdb1
mdadm: no recogniseable superblock on /dev/sdb1
mdadm: /dev/sdb1 has no superblock - assembly aborted
# mdadm --assemble /dev/md0 /dev/sdb2
mdadm: no recogniseable superblock on /dev/sdb2
mdadm: /dev/sdb2 has no superblock - assembly aborted
# blkid /dev/sdb1 /dev/sdb2
/dev/sdb1: UUID="32d4fbe6-7dae-66a6-3017-a5a8c86610be" TYPE="linux_raid_member" PARTUUID="574cde87-01"
/dev/sdb2: UUID="39e2a1c0-91d5-b8e5-3017-a5a8c86610be" TYPE="linux_raid_member" PARTUUID="574cde87-02"

Aha, oni do particii typu RAID nasrali priamo data? Alebo pouzili nejaky neznamy format superbloku (to je teraz jedno, kedze som tam mal len jeden disk).

Kód: Vybrat vše

# file -s /dev/sdb1
/dev/sdb1: Linux rev 1.0 ext4 filesystem data, UUID=6cddcdc5-a51b-41ba-b3a5-4c2a5d01ce2d, volume name "1.44.1-42218" (needs journal recovery) (extents) (64bit) (large files) (huge files)
# file -s /dev/sdb2
/dev/sdb2: Linux swap file, 4k page size, little endian, version 1, size 524271 pages, 0 bad pages, no label, UUID=5dab8c2d-eb5e-41cb-b473-8c6c9e199f1e
# mount /dev/sdb1 /mnt/ -t ext4
# ls -la /mnt
total 96
drwxr-xr-x 23 root root 4096 Jan  1  2000 .
drwxr-xr-x 24 root root 4096 Oct 23 20:14 ..
lrwxrwxrwx  1 root root    7 Feb  4 19:11 bin -> usr/bin
drwx------  2 root root 4096 Feb  4 19:13 config
drwxr-xr-x  3 root root 4096 Feb  4 19:11 dev
drwxr-xr-x 45 root root 4096 Jan  1  2000 etc
drwxr-xr-x 42 root root 4096 Feb  4 19:12 etc.defaults
drwxr-xr-x  2 root root 4096 Oct 18 15:17 initrd
lrwxrwxrwx  1 root root    7 Feb  4 19:11 lib -> usr/lib
lrwxrwxrwx  1 root root    9 Feb  4 19:11 lib32 -> usr/lib32
lrwxrwxrwx  1 root root    7 Feb  4 19:11 lib64 -> usr/lib
drwxr-xr-x  3 root root 4096 Jan  1  2000 .log.junior
drwx------  2 root root 4096 Oct 18 15:17 lost+found
drwxr-xr-x  2 root root 4096 Oct 18 15:17 mnt
drwxr-xr-x  2 root root 4096 Feb  4 19:12 .old_patch_info
drwxr-xr-x  2 root root 4096 Oct 18 15:17 proc
-rw-------  1 root root 1024 Jan  1  2000 .rnd
drwx------  2 root root 4096 Feb  4 19:11 root
drwxr-xr-x  8 root root 4096 Feb  4 19:12 run
lrwxrwxrwx  1 root root    8 Feb  4 19:11 sbin -> usr/sbin
drwxr-xr-x  3 root root 4096 Feb  4 19:09 .syno
drwxr-xr-x  2 root root 4096 Feb  4 19:09 .SynoUpgradePackages
dr-xr-xr-x  2 root root 4096 Oct 18 15:17 sys
drwxr-xr-x  2 root root 4096 Feb  4 19:13 .system_info
drwxrwxrwx  2 root root 4096 Jan  1  2000 tmp
drwxr-xr-x 12 root root 4096 Jan 12 09:37 usr
drwxr-xr-x 15 root root 4096 Feb  4 19:13 var
drwxr-xr-x 12 root root 4096 Feb  4 19:11 var.defaults
drwxrwxrwx  2 root root 4096 Oct 18 15:17 volume1

RAM som zatial otestoval v notebooku a je dobra.

matahari · #5 Příspěvek od **matahari** » 05 úno 2022, 14:39

Jen použili ID 86 místo 83 (což není košér), protože se počítá s více disky a mirroringem, což jsi zjistil, až si ten disk namountoval v PC, kde ten druhý partition je swapka.

#6 Příspěvek od **rnbw** » 05 úno 2022, 17:51

Lenze ten RAID tam nejaky je, akurat nestandardny. Vypis zo Synology nabootovaneho len do getty.target (symlink /lib/systemd/system/default.target -> syno-bootup-done.target som zmenil na getty.target):

Kód: Vybrat vše

# dmesg | grep md
[    0.000000] Command line: root=/dev/md0 earlyprintk=apl console=ttyS2,115200n8 ihd_num=2 netif_num=2 HddHotplug=1 SataPortMap=21 syno_hw_version=DS718+ vender_format_version=2 syno_hdd_detect=18,179,176,175 syno_hdd_enable=21,20,19,9 syno_usb_vbus_gpio=13@0000:00:15.0@3 sn=xxx macs=yyy,zzz
[    0.000000] Kernel command line: root=/dev/md0 earlyprintk=apl console=ttyS2,115200n8 ihd_num=2 netif_num=2 HddHotplug=1 SataPortMap=21 syno_hw_version=DS718+ vender_format_version=2 syno_hdd_detect=18,179,176,175 syno_hdd_enable=21,20,19,9 syno_usb_vbus_gpio=13@0000:00:15.0@3 sn=xxx macs=yyy,zzz
[   10.611840] md: raid1 personality registered for level 1
[   11.478841] md: md0 stopped.
[   11.479712] md: bind<sda1>
[   11.485940] md/raid1:md0: active with 1 out of 2 mirrors
[   11.501099] md0: detected capacity change from 0 to 2549940224
...

Kód: Vybrat vše

# cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sda1[0]
      2490176 blocks [2/1] [U_]

unused devices: <none>

Kazdopadne to je teraz jedno. Idem zistovat, co musim spustit, aby to spadlo.

#7 Příspěvek od **rnbw** » 06 úno 2022, 00:20

Spadne to po spusteni /usr/syno/bin/scemd (z scemd.service).
Ked sa ale spusti samostatne, nerobi nic - zjavne caka na nieco z syno-bootup-done.service. Takze ked spustim "systemctl start syno-bootup-done.service" a nasledne /usr/syno/bin/scemd, spadne to.

Nie je tam strace, tak ho tam nakopirujem a skusim pokracovat

#8 Příspěvek od **rnbw** » 14 úno 2022, 23:42

Zrazu to zacalo fungovat

Tak som pustil 4x (lebo to ma 4 jadra) nekonecnu slucku "while true; do echo -n; done" a o chvilu to bolo zase v prdeli.

Asi to bude na reflow CPU, pripadne na vyhodenie.

#9 Příspěvek od **rnbw** » 15 úno 2022, 21:00

Reflow nepomohol, seriem na to.

eleferner · #10 Příspěvek od **eleferner** » 26 úno 2022, 13:26

xsc píše:Nebude spíš problém s tím řadičem disků? Pokud si pamatuju, tak na téhle Intelí platformě je nějaká chyba, takže po nějakém čase umřou.

Tohle byl problem pouze u NASu, ktere v sobe mely procesor z rady Atom C2xxx (Avoton). Sam jsem to jednou resil, u nekterych NASu to jde opravit pripajenim jednoho odporu. Jinak seznam procesoru v Synology NASech je zde, DS178+ se to netyka

https://kb.synology.com/cs-cz/DSM/tutor ... y_NAS_have:

#11 Příspěvek od **rnbw** » 02 črc 2022, 13:22

Teraz tu mam QNAP TS-251+ s tym nechvalne znamym Celeronom J1900. Po zapnuti ostali svietit len LED USB a HDD, nebootoval. Na pine LPC_CLK som nameral 2,3V. Vrazil som tam odpor 100R na zem, napatie kleslo na 1,5V a ozilo to.

#12 Příspěvek od **rnbw** » 02 črc 2022, 18:04

Testujem to a zistujem, ze v zatazi vypadava druhy disk. Ked som disky navzajom prehodil, stale vypadava druhy. Zistil som, ze napajanie SATA1 je priamo, ale napajanie SATA2 je spinane dvojitym FETom Q4 (NTMD6P02) na backplane. Meral som teda napatia za FETom - v zatazi zacne klesat 5V, az sa disk zastavi (a nasledne znovu rozbieha).

Problem je v budeni FETu, ktore je neskutocne 🤐 riesene - cez odpor 100K. Napatie na G teda chodi podla teploty. Po chvili behu to lezie az k 4V (proti zemi), takze Vgs je len okolo -1V. Pred odporom je to vporiadku (0,5V proti zemi).

Ze by sa konstrukter obaval odpalenia FETu (jeho maximalne Vgs je 12V), tak tam vrazil velky odpor?

BTW. Seagate IronWolf ma pri seeku zvuk ako 5,25" MFM disk ST-225

#13 Příspěvek od **rnbw** » 02 črc 2022, 20:33

Vymenil som odpor R70 (100K) za 1K, problem vyrieseny.