Synology dotarło do mnie prawie całkiem martwe. Prawie, ponieważ linux podnosił się w połowie. Niestety nie zapisałem, jakim dokładnie błędem sypał, ale był to błąd krytyczny z dumpem stacka, za każdym razem w tym samym miejscu. Wylutowałem flash, ponieważ za cholerę TFTP nie chciał współpracować z moją siecią (nie mam pojęcia dlaczego, nie raz korzystałem z TFTP na routerach Linksysa i nigdy nie miałem problemów; w tym przypadku plik przesyłał się w 2/3 i transmisja umierała dając timeout) i zaprogramowałem od nowa korzystając z opisu dostępnego tutaj: https://forum.synology.com/enu/viewtopic.php?t=84141 (strona ta teraz nie istnieje, ale jej kopię można przeczytać pod: https://community.synology.com/enu/forum/17/post/69287). Przy programowaniu używałem RT809H, nie było żadnych błędów, weryfikacja była poprawna. Zapisałem sobie wcześniej jaki jest flash map mojego urządzenia:

[    8.679917] 0x000000000000-0x0000000d0000 : "RedBoot"
[    8.685769] 0x0000000d0000-0x0000003d0000 : "zImage"
[    8.691474] 0x0000003d0000-0x0000007d0000 : "rd.gz"
[    8.697123] 0x0000007d0000-0x0000007e0000 : "vendor"
[    8.729017] 0x0000007e0000-0x0000007f0000 : "RedBoot Config"
[    8.735593] 0x0000007f0000-0x000000800000 : "FIS directory"

Po kilku poleceniach dd, odbudowie obszaru vendor i flashowaniu Synology ożyło, radośnie pikło i było już dostępne w sieci pod adresem xxx:5000.
Przy instalacji DSM frontend krzyczy takim błędem: Instalacja pliku nie powiodła się. Prawdopodobnie plik jest uszkodzony (13).

Przy budowaniu wsadu do flasha korzystałem z plików z archiwum dostępnych pod adresem: https://global.download.synolo…n=6.2.2&build number=24922

czyli z najnowszewgo oprogramowania. Wrzucałem też starsze oprogramowanie w wersji 5.1, ale pojawia się ten sam błąd.

JSON, który jest wysyłany do przeglądarki w czasie błędu wygląda tak:

{
  data: {},
  errinfo: {
    key: "err_patch",
    line: 13,
    sec: "wizard",
    success: false
  }
}

Przy próbie instalacji DSM przez Synology Assistant dostaję błąd: Błąd serwera. (Kod błędu:18).

Przy instalacji DSM w konsoli pojawia się:

[  358.671039] EXT4-fs (md0): mounted filesystem with ordered data mode. Opts:
[  358.842312] md0: detected capacity change from 2549940224 to 0
[  358.848131] md: md0: set sdd1 to auto_remap [0]
[  358.852647] md: md0 stopped.
[  358.855526] md: unbind<sdd1>
[  358.866462] md: export_rdev(sdd1)
[  358.918196] md1: detected capacity change from 2147418112 to 0
[  358.924074] md: md1: set sdd2 to auto_remap [0]
[  358.928583] md: md1 stopped.
[  358.931464] md: unbind<sdd2>
[  358.950331] md: export_rdev(sdd2)
[  362.285392] md: bind<sdd1>
[  362.288500] md/raid1:md0: active with 1 out of 4 mirrors
[  362.309016] md0: detected capacity change from 0 to 2549940224
[  365.356418] md: bind<sdd2>
[  365.359527] md/raid1:md1: active with 1 out of 4 mirrors
[  365.396061] md1: detected capacity change from 0 to 2147418112
[  365.406724]  md1: unknown partition table
[  365.453041]  md0: unknown partition table
[  366.547617] EXT4-fs (md0): barriers disabled
[  366.561146] EXT4-fs (md0): mounted filesystem with ordered data mode. Opts:

Dodam, że wymieniałem dysk na inny i ciągle synology sypie błędem 13/18 przy instalacji DSM. Kontaktowałem się z supportem, ale ten powiedział mi tylko, że jedyne co mogą doradzić to to, że z chęcią mi pomogą… wybrać nowy sprzęt, bo ten już nie jest na gwarancji… Brak słów. Nawet nie odpowiedzieli, co oznaczają te numery błędów.

Po kilku dniach natrafiłem na dość jednoznacznie wskazującą stronę w pomocy Synology, że winą błędu 13 może być walnięta pamięć:

https://www.synology.com/en-gl…memory test on my Synology NAS

Dodam tylko, że test pamięci odpalany w ten sposób może być tylko i wyłącznie wtedy, kiedy DSM jest już zainstalowany, czyli nie w moim przypadku.

Kupiłem nowe kości RAM i wziąłem się za przelutowanie BGA. Niestety po wymianie wszystkich kości na nowe problem nadal występuje, więc jestem pewny, że zonk leży po stronie FLASHa. Podejrzewam, że procedura opisana tutaj: https://forum.synology.com/enu/viewtopic.php?t=84141 jest poprawna tylko i wyłącznie dla procesorów ARM, a nie dla Inteli i dla Intela potrzebna jest jakaś dodatkowa konfiguracja w jakichś regionach flasha (RedBoot Config?), o której autor w w/w linku nie wspomina.

Pomierzyłem wszystkie napięcia, które mogłem i wszystko wydaje się być w porządku.

Po rozłożeniu rąk sprzęt trafił do mojej piwnicy w oczekiwaniu na lepsze czasy. Po roku całkowicie o nim zapomniałem. Dzisiaj, tj. 04.11.2021 do warsztatu na wymianę wentylatorów trafiło Synology DS415play. Skojarzyłem, że mam ten sprzęt w piwnicy i z ciekawości zgrałem całą zawartość kości BIOS działającego egzemplarza do mojego, półmartwego sprzętu. I wiecie co? Moje Synology również ożyło.

W warsztacie NASy od tej firmy miałem dwa razy – oba egzemplarze były na prockach ARM. Aż nie chce mi się wierzyć, że po takim szmacie czasu mam w warsztacie identyczny egzemplarz.

Dla potomnych zostawię tutaj opis usterki error 13/18 dla Synology DS415play:

• uszkodzona/wyzerowana konfiguracja BIOSu,
• wyczerpana bateria podtrzymująca BIOS,
• walnięta pamięć RAM.

Pełny dump kości FLASH spakowany ZIPem można ściągnąć stąd: https://redliquid.pl/wp-content/uploads/2021/11/synology415play_flash_dump.zip