Leaderboard

Bonjour, On choisi en fonction de son matériel. Je recommande DS3615sx. A lire aussi:

Got a F2-220 with 4GB RAM and J1800 cpu. Had problems updating to latest release. Created a new usb using IG-88 directions (combined 24922 zImage + rd.gz plus his extra.lzma and extra2.lzma from 0.8_syno ds918+. Booted using new usb, chose to migrate, and updated to latest release. After a few reboots all is running well. Got populated /dev/dri. Many Thanks IG-88!

I suppose you were referring to the source code of the loader. In simple terms the source code is not public and never was. Only one person is responsible for creating the current loader. As for not being able to collaborate that's just non sense, sorry. Most people here started from scratch and ended up collaborating more than what they thought they could. Perhaps you should stick around see how you can help. I am not a coder myself yet I have created several tutorials, I give advise and administer the forum on a daily basis. Like everyone I am not always right but we are all here to help each other. What kind of "web stuff" do you develop?

i'm not modding the kernel source from synology, i use/add external drivers from intel, realtek ... to compile newer/better drivers so there is no "developing" the project is based on a hack that uses the original kernel and for dsm it looks like as it running on a original hardware (emulated drivers from original hardware is one part of the hack) atm there is only me trying to provide additional drivers, i have only done 4 or 5 small changes to additional drivers or the the original kernel source even as i was not around for about one year no one else did anything about the driver problems with dsm 6.2.2 even if it only was about some (small) change in kernel config to compile kernel and drivers - it a small community no need and it would take additional time to do and maintain it and i'm not a (linux) "developer" a accidentally know how to compile driver and i'm willing to invest enough time to make it useful for more people, my start point was just a missing driver button.ko for a convenient shutdown by pressing the the power button that was missing in dsm 6.0 loader, the rest is more or less the will to give something back (after using xpenology for ~2 years without participating) pity, i'm willing to do the tedious work but we will need a coder sooner or later if synology does not publish newer kernel source

ja, das klingt erst mal sehr vielversprechend in dem 2. thread kam wohl noch erschwerend hinzu das die lsi sas controller (treiber) immer alle platten die gefunden werden direkt hintereinander klatschen so das wenn eine fehlt oder (wieder) dazu kommt sich jedes mal die buchstaben der sdX devices ändern, das kann ziemlich nervig sein wenn man sich nach jedem reboot neu orientieren muss das passiert bei sata/ahci eigentlich nicht ja das sieht erst mal alles richtig aus wenn du das vor dem reboot noch mal begutachten willst dann wäre das /dev/md2 mit folgendem aktivierbar mdadm --assemble --run /dev/md2 /dev/sd[bcd]5 danach könnte man mit "cat /proc/mdstat" und "mdadm --detail /dev/md2" prüfen ob das raid soweit ok aussieht nach dem reboot kann man dann in der dsm gui einfach die platte der raid group hinzufügen oder sie als spare definieren, dann sollte sie kurz danach automatisch integriert werden (letzteres kann bei shr2/raid6 notwendig sein wenn beide redundanz platten fehlen und man nur eine zum "hinzufügen" hat)

let's see, where is my crystal ball ... mmmhh, nope cant find it atm so you might have to write more about you loader, dsm version, hardware (cpu, storage controller, nic)

die daten sind zum allergrößten teil noch da, die frage ist wie vile verlust man in kauf nehmen kann/will jede raid platte hat einen sequenz counter, im normalzustand sind die alle gleich, werden daten nicht auf die platte geschrieben weicht der ab und die platten fallen aus dem raid man kann sie mit den richtigen befehlen wieder in das raid "zwingen" aber es gehen dann eben diese nicht geschriebenen daten verloren bzw. haben falschen inhalt, was dann zu logischen fehlern in (wenigen) dateien führt, das sind evtl .nur ein paar hundert kB erst mal wichtig ist die ursache zu ermitteln, an einem instabilen system sowas reparieren zu wollen geht meist schief dann ermittelt man den sollzustand, layout der platten im mdadm raid, SHR bedeutet meist unteschiedliche platten waren in nutzung, was dann in mehreren raid sets endet die mit LVM zusammengefügt sind - SHR ist nicht so "speziell" es "nur" eine kombination auf linux standard sachen wie mdadm und lvm nach dem dokumentieren ermittelt man die sequenz nummer und schiebt grade so viele platten wieder zurück in das raid wie nötig unf nimmt die platten mit der höchsten sequenz nummer, in deinem fall würde man von den 2 "freien" platten die sequenznummer ermitteln und nur eine mit der höchsten nummer wieder zum raid hinzufügen, da die chunk size meist 64k ist kann man am unterschied der plattten die noch synchron sind und der "besten" die man noch hat den verlust ermittlen, wenn man btrfs mit checksummen hat kann man evtl. sogar rausfinden welche dateien betroffen sind lies mal hier rein und in den verlinkten englischen thread, da gab es noch bestehende hardware probleme was die reparatur (unter datenverlust) am ende doch verhindert hat ist eigentlich nicht so schwer, flyride hat das in dem englischen thread sehr gut parallel zur reparatur erklärt, kann man fast als tutorial nehmen (setzt aber ein paar kenntnisse über linux und raid/lvm voraus) https://xpenology.com/forum/topic/24767-asrock-j4105-itx-sata-controller-defekt/