IG-88

maybe the hardware does not support 7.x or there are some older packages that do not run with 7.x, also often a case of not sink time if its not needed (dont fix things that are not broken) as 6.2 is still under official support including photo station until the end of the month https://www.synology.com/en-global/products/status/eol-dsm62

es gibt da auch ein oder zwei deutsche threads wo raids wiederhergestellt wurden aber do habe ich auf anhieb nichts parat aber du kannst dir mal diese hier ansehen im ein gefühl dafür zu bekommen wie es weiter gehen würde https://xpenology.com/forum/topic/59547-volume-crashed-after-reboot/ https://xpenology.com/forum/topic/63132-volume-lost/ https://xpenology.com/forum/topic/52941-degraded-volume-cant-replace-disk-volume-crashed-ext4-shr/ hier noch etwas das in deutsch war https://xpenology.com/forum/topic/25841-volume-crahsed https://xpenology.com/forum/topic/24767-asrock-j4105-itx-sata-controller-defekt/

also mal so grundlegend müsste man erst die raid's rekonstruieren bzw. zum laufen bringen und dann die richtige anordung in dem lvm rekonstuieren wenn du initial mit 6x 20TB und 1x 18TB als shr2 begonnen hast dann war es 7 x 18TB als raid6 + 6 x 2TB als raid6 90TB + 8 TB bzw. muss man ja in "echten TB rechnen wenn man deine zahl unten mit 89.11TiB sieht also 7 x 16.37 als raid6 + 6 x 1.82 als raid6 (je zwei disks abziehen wegen der redundanz, das ergibt die nutzkapazität) 81.85TiB + 7.28 TiB = 89.13 TiB (ein paar kleine rundungsfehler aber man sieht die zahl stimmt mit dem lvm überein) der lvm zustand ist also noch wie vor der erweiterng (was ja auch passt, wenn es beim raid erweitern schief geht passiert der folgende schritt nicht mehr bei dem dann das 3. neue raid volume zum lvm adiert würde) das mit dem btrf wäre nebensache da das filesystem dann noch on top auf dem lvm kommt, filesystem ist also auch immer noch die alten 89,11 TiB wenn du eine 24TB disk in dem szenario hinzufügst dann würden 16.37TiB dem ersten raid6 zugeschlagen und 1.82TiB dem zweiten raid hinzugefügt, der rest der platte (4TB von 24TB) wären ungenutzt geblieben du suchst also den status von zwei mdadm raid's (es gibt da auch noch zwei raid1 mdadm raids für system und swap die kein lvm bilden und das DSM system darstellen) das wäre noch einigermaßen normal da eine hinzugefügte platte am anfang immer je eine system und swap raid1 partition bekommt die dem mdadm raid1 für system und swap hinzugefügt wird, das papssiert noch vor der raid erweiterung für die daten volumes und war bereits abgeschlossen als die sache später schief ging, das globale raid1 für system und swap vermissen nur eine raid platte und das wird gemeldet, stört nicht und kann man erst mal ignorieren, was dich interessiert ist der zustand der beiden mdadm raid6 also erst mal rausfinden was so los ist mit den mdadm raids (die sachen müssen in der regel als sudo ausgeführt werden) cat /proc/mdstat mdadm --examine --scan mdadm --detail --scan --verbose erst wen man hier bei den raid's klarheit hat und lesbare raid's hat (die notfalls auch degraded sein können) kann man mit dem lvm weiter machen mal so als marschrichtung: 1. klären warum das system einfach so ausgegangen ist, wenn dir das beim raid recovery wieder passiert wird es unter umständen noch schlimmer (aber zumindest wird es nicht besser und man muss von vorn anfangen und verliert evtl. mehr daten) 2. für die raids gibt es einen zähler an dem man sehen kann welche disks welchen stand in sachen raid aktualität hat, ist eine disk "älter" als die anderen ist sie nicht gültig und gibt es keinen cahce/puffer der diese daten noch hat ...und sind mehr als zwei platten ungültig wird das raid nicht mehr von allein starten da shr2 gleich 2 dedundante platten bedeutet also raid6 und wenn diesem mdadm raid6 mehr als 2 platten "fehlen" hält es erst mal an und fragt nach der alles weiß und sich auskennt (sysop aka root user der alles richten kann und muss) prizipiell kann man platten eines raid von hand zwingen zusammen zu laufen auch wenn sie nicht den gleichen stand haben aber das bedeutet immer das daten verlustig gegangen sind und das muss später das dateisystem ausbaden (datein mit fehlerhaften inhalten oder auch fehlerhafte strukturen im dateisystem) wenn du hier im forum nach infos suchst dann bist du an den stellen gut aufgehoben wo flyride an der reperatur dran war, da gibts was zu sehen und zu lernen gibt es etwas in /etc/lvm/backup/vg1 ?

beschädigter loader wäre die vermutung und ich hätte zum arc laoder geraten https://auxxxilium.tech (arpl wird seit fats 1.5 jahren nicht mehr weiter entwickelt) man kann theoretisch vom alten loader auch sachen aus dem xml file holen (SN usw.) aber in der regel lohnt das nicht und wenn man schon dabei ist kann man sich auch überlgen ob was andres als 3622 etwas bringt, der wiki zum arc laoder lohnt einen blick

versuch doch mal eine 2. netzwerkkarte reinzustecken und beide am switch zur fritzbox (in dem fall vermutlich der dhcp server) eine neue karte (deren treiber vorhanden ist) du kannst auch im loader in die config oberfläche booten, da du scheinabt tinycore hast könntest du dort mal schauen was du da an hardware siehst und ob das system in diesem linux eine netzwerkadresse bekommt ober mal ein andere boot stick mit einem recovery linux und schauen ob da netzwerk funktioniert du hast ja nicht so viel geschrieben was du schon alles probiert hast um andere fehler auszuschließen generell lohnt es sich auch mal auf die led's der netzwerkkarte zu schauen

i'd suggest you try arc loader (and read the wiki there) it should provide alll you need to get a 10th en intel cpu with intel qick sync running https://github.com/AuxXxilium afair an 0x9BC8 device id is not going to work ootb with kernel 4 i915 drivers provided by synology ist need a patched driver (crude version where one pcie id is changed from one persent to 9BC8 like 9BC2 to 9BC8) or a kernel 5.x based dsm model like epyc7002 where a newer i915 driver ist present by default and imho a 10th gen gpu should wot ootb with the default driver (the should als be a i915 driver for up to 13th gen for that model)

das meint hardware raid conteroller (dafür ist DSM an sich so nicht gemacht da man dort eigentlich jede platre einzelen verwaltet und mit software raid arbeitet) und eher die SAS controller wie die beleibten lsi/broadcom HBA's (die mit der nicht raid firmware wo jede platte einzeln verwaltet wird bei den gemini lake systemen hat man ohnehin nur pcie 2.0 und wenige pcie lanes, da trifft man vermutlich selten solche 8/16 port controller an kommt darauf an was an controller verwendet wird reine sata/ahci wäre es fast egal, das läuft mit allen dsm modellen aber wenn man sas controler benutzt dann muss man wenn man als cpu wirklich gemini lake hat spielt auch der max. core count der modelle keine rolle, die paar core's können alle über den daumen haben die DT (device tree) modelle keinen support für raid/scsi/sas hba's/controller, der 3622 ist ein klassisches non DT model und würde auch damit umgehen können man ist aber nicht total fix wenn man erst mal eins hat, man kann im loader auch später das model wecseln und dann ein cross upgrade von dsm machen um, dabei wird so ziemlich alles übernommen, so lange die controller funktionieren und nacher alle platten anspechbar sind sollte das gehen kann man auch testen, ,mit einem test usb stick und zwei leeren platten eine platte am internen ahci controlelr und eine am zusätzlichen controller, mit einer config beginnen (3622) dsm installieren, 2. platte prüfen (dsm system wird automatisch installiert und man kann wenn man will ein volume auf der 2. platte anlegen (es raucht aber das man sie unter hdd/ssd sieht) danach im loader auf das neu modell wechseln und dsm erneut für dieses modell als upgrade installieren lassen, danach sollte auch die 2. platte wieder zu sehen sein wenn das so geht sollte es auch mit andern platten gehen die man an den controllern hat für so einen test kann man einfach alle produktiven platten aklememn den produktiven usb stick abziehen und mit einem set aus usb und 2 leeren platten testen, geht also alles mit der echten hardware mit der ma arbeitet ohne das man sein daten oder die laufrnde installation gefährdet in den meisten fällen ist die 3622 ok, man nutzt unter umständen nicht alles möglichkeiten die man mit der hardware hätte aber für einen reinen nas betrieb ohn sonder locken ist die immer gut (so wie früher die 3615 und 3617) amd cpu's sind eigentlich nut ein thema wenn es um vmm (virtuelle kvm basierte sachen) geht, wenn man das nicht braucht kann man ignorieren das man einen amd cpu hat und wenn man das nutzen will muss es als modell die r1000 / v1000 oder epyc7002 sein (letztere hat den moderneren unterbau mit kernel 5.x und wenier cpu core limits) die faq und der wiki zum arc loader sind sehr gut und es lohnt sich mal 1h damit zu verbringen (wie viel man da rauslesen kann hängt auch von den allgemeinen erfahrungen im computer bereich ab, wer da schon 20 jahre dabei ist wird eher mit den anmerungen klarkommen als jemand der wenig hintergrund hat - aber da gibt es ja hier das forum, wenn es unklar ist kann man fragen und beim arc hat es auch einen discord (was nicht men ding ist aber wer will findet da sischer auch hilfe)

not really needed as long as you don't plan to max out to 100m especially 2.5GBase-T is ok with Cat 5e https://en.wikipedia.org/wiki/2.5GBASE-T_and_5GBASE-T but it does not hurt to have new and better cables and that's just 50 bugs and still fan-less , looks like there is some new and useful stuff around (had not looked lately as i already have what i needed) looks like you already have all planed the right way,the two 10G sfp+ ports might be useful later, i guess the jump from 1G to 2.5G might more cost effective then doing all with 10G now, in most home use cases 10G is not really needed and more of a "why not if i can do it"

thats a normal realtek r8125 based card, should be no problem with rp based loaders for dsm 7.x intel based 2.5G based cards (driver igc.ko) where a problem in the beginning because it was only supported in kernel 5.x and intel did not deliver a driver for older kernels there is a backported driver now but as the driver code is continued in kernel 5.x by intel its not guaranteed how much of that ends in the driver you will be using in kernel 4.x based dsm versions (atm only sa6400 is kernel 5.x based, so pretty much every dsm version uses the backported intel igc driver) it also depends how you connect things, if the switch (usually in between components connected to a network) does not support more the 1G you can't use the 2.5G its also possible to directly connect cards without a switch but these cases usually need some manual network settings to work and are not as universal as using it with a switch alternatives are older 10G cards like mellanox sfp+ cards (cheap as the more expansive 2.5G cards) or cards that support rj45 based speeds like 1G, 2.5G, 5G and 10G, these are way more expansive and usually produce a good amount of heat (thats true for the older 10G cards like the mellanox too) when "investing" in a new switch and cards it might be interesting to look for 10G cards and switches with sfp+, leaves way more headroom for the next years maybe look for switches from mikrotik or qnap that come with sfp+ (and some are available fan-less) might cost a 80-130 bugs more over all but will pay off as network cards and switches will often be used over 2 or 3 gens of computer hardware

all recent loaders for 7.x are based on rp aka red pill (based on TTG's original redpill-load project), you might be using tcrp, like tiny core red pill (tiny core would be the system used to configure the laoder before booting dsm mode to install or run dsm) in theory yes when using the same sn and mac's but in real life i my experience (arpl to arc) was that i had to reinstall dsm and even with the same sn/mac it behaved like a new installed different system, like i hat to make a complete new hyperbackup because the old backup was not recognized as matching to the arc reinstalled system) (my 2nd system needed to add 2nd nic so there was a "slight" different update changing from the state it had with arpl, same result as with the 1st system, it was a new/different one in regard of dsm's internal view) in your case it would be no problem i guess, you could use the new usb drive with the arc loader and boot you original disks, that way the update will use all you settings even when dsm is reinstalled there would be no need to match to you old sn/mac, that kind of update is within synology's normal operations for dsm and would happen when your original hardware gets replaced, like in warranty case, wjth a new of the same model, the "old" HDD's would contain dsm with old sn/mac and the new hardware would have a new sn/mac in its usb DOM you can find a synology kb about that i guess even on model change (like 3617 to 3622) the settings would still be there as synology also supports that scenario (can be checked in synology's kb, there is a list and conditions for that - and from experience that will work with even more models and older dsm versions then what synology guarantees), the thing not supported is a model change from one with arm cpu to one with x64 cpu but as long as its with x64 it will cover most cases

da fehlen ein paar sachen, welches dsm modell und welche cpu vorher drin war aber ich würde vermuten das es ein dsm modell was das im grinial eine intel cpu hat und du hattest vorher eine intel cpu? der dsm kernel ist jeweils für die cpu "optimiert", sieht man am jeweiligen namen von "Package Arch" in diesem link (in den meisten fällen sieht man das auch in den *.pat dateien https://kb.synology.com/en-global/DSM/tutorial/What_kind_of_CPU_does_my_NAS_have sol lange man kein intel qsv oder vmm nutzt kann man in der regel ein dsm modell das für intel gedacht ist auch mit amd nutzen sollte man vmm nutzen wollen ist ein modell wechsel (in loader) nötig, dann instaliert man ein cross update bei dem die dsm einstellungen übernommen werden r1000,v1000 und Epyc7002 sind amd, letztere hat sogar einen 5er kernel (ob man das dann in der performance merkt ist mir nicht bekannt, kann aber in sachen ootb treiber vorteile bringenm wobei es in den aktuellen loadern wir arc jede menge zusätzliche treiber gibt, selbst der igc 2.5G intel treiber wurde auf kernel 4.x als backport gebaut obwohl das intel nicht liefert/unterstützt)

laut wiki unterstützt arc loader es als cache auf allen aber mit einer ist es dann nur eine lese cache und der ist in den meisten fällen im heimbereich eher nicht so sinnvoll einbinden also data volume ist aber teilweise möglich, da kann es zumindest für bestimmte sachen (vm's docker) einiges bringen https://github.com/AuxXxilium/AuxXxilium/wiki/Arc:-Loader-Addons ... nvmecache: Allow the User to create NVMe Cache on DS918+, DS419+, DS719+, DS1019+, DS1621xs+ and RS1619xs+ nvmevolume: Allow the User to create NVMe Storage Volume nvmesystem: Allow the User to create NVMe Storage Volume on SA6400 (Support NVMe only, but need 2 NVMe Disks) ...

es gab zwar mal ende 2020 etwas als spk (auf für dsm 7.0) aber selbst wenn das liefer wäre es wohl viel zu alt als docker container? "Setup WireGuard On A Synology NAS Running DSM 7.2 Using Container Manager" https://www.youtube.com/watch?v=v0Z1m658Xe8 oder https://www.dev-insider.de/wireguard-als-docker-container-installieren-a-5161a6ee3a93fe54352086cf4e50c02c/

you can take what its written in the arc wiki The DSM kernel is only compatible with SATA Controller, not HBA/Raid/etc. For Device-Tree Models (DT) SATA Controller are working, HBA/Raid Controller are in experimental Stage. For nonDT Models, other Type of Controller (like HBA/Raid/SCSI Controller) may work. there are driver for the older ata mode satra stuff, might work but only on non DT (devicetree) models like 3615/17 most simple und universal solution is to disable onboard old piix ata stuff if its nor working as ahci and add ahci sata cards, most only use two pcie lanes and if its just pcie 2.0 then it can limit the possible performance it there are to many drives on these two lanes (pcie 2.0 = 500 MByte/s per pcie lane, good old hdd's can't do much above 250MByte/s except where the tiny hdd cache is in use), ahci controllers are more universal as they are supported in all synology kernels where hba's are limited to some models if there are enough pcie slots the ahci cards (2,4,5,6 ports) are a good option asm1166 can be a problem as they present 32 ports to the system and only have 6 ports, can get messy with the numbering of drives (but afaik will work anyway) i prefer(ed) jmb585 based cars with 2 ports (pcie 1x slot) and 5 ports in pcie 4x/8x/16x slots past because my recent setup uses 5 bigger disks and can work with the 6 onboard sata (but if i need to i would reuse my jmb585 cards again and backup system with older drives still uses jmb585) you can read some about that stuff here (its no faq its just a timeline kind of collection about things) https://xpenology.com/forum/topic/35882-new-sataahci-cards-with-more-then-4-ports-and-no-sata-multiplexer/ also there might be some cards that use pcie multiplexer chips in a useful way but they will be more expansive for the 10-12 sata ports and might do some fake stuff, so its always good to know what the chips on the card are supposed to do and what they really can do by the specs of the chip)

check the links in the 1st post 1st 3615 was still working (test to read as link) but some one had replaced it with a zippyshare that was expired already, i reinserted the link as the text was (pixeldrain link) 2nd 3615 was still working (at least the pixeldrain) i removed all non working link and checked the one already there