IG-88

i'd suggest a jmb585 based card in the pcie 16x slot (that has pcie 3.0, the other slots seem to be 2.0) https://xpenology.com/forum/topic/35882-new-sataahci-cards-with-more-then-4-ports-and-no-sata-multiplexer/ i guess so, not much choice for >6 onboard, maybe a used system is a option 88SE9128, sees extremly old silicon, if anything then use 88se9235 two pcie 2.0 lanes and 4 ports, if you just want to use two atm there is no bandwidth problem at all (pci4 4x slot with pcie 2.0 on you board) if you use 3617 as base you could also use a lsi sas controller that has 8 ports and with its 8 lanes (16x slot) you could even add some ssd's if you want

maybe this one? https://xpenology.com/forum/topic/28321-driver-extension-jun-103b104b-for-dsm623-for-918-3615xs-3617xs/ but thats specific for scsi/sas controller when using disk hibernation on 918+ the newly compiled driver (no smart, no sn) does not have this problem but makes disk handling more or less impossible as you cant identify disks properly in the gui and cant user smart data to determine the disks condition

if you look at my screenshots (they where intended to give a little guidance, 3rd picture) there is filesystem and there should be your btrfs you can mount with omv you usually dont do things on the command line, its intended to be used in the web gui after mounting it you can create a share under smb/cifs and acceess it the way you most likely do (there is also nfs and something for apple, OMV has online help and even a 161 pages documentation, openmediavault-readthedocs-io-en-stable.pdf) AAAAND? what was the result, maybe it was not both 6.2.3? when starting the loader it will check the version of the kernel files on the loader (zImage and rd.gz - so they need to be from dsm 6.2.3) and it will check VERSION on disk in the how to thread for downgrading 6.2.4 a user commented he just deleted the VERSION files (both) and was able to reinstall 6.2.3 i guess you can try that too if you where able to mount the system partition why do you want to do this? thats, your data (raid5) seems to be ok, your problem with not starting is about the system partition (1st partiton on every drive as raid1) but if you insist, "raid verwaltung", click on the raid5 and click "löschen", that should delete your raid5

thats just normal SATA3 no nvme is pcie and if you bring that into connectot for hdd's its called U.2 the m.2 slot can have more types of connections usable for devices then just pcie https://en.wikipedia.org/wiki/M.2#Form_factors_and_keying if you have a sata ssd and m.2 with m or b+m key then there might be sata on the connector too and you could get it to a normal sata connector by a adapter (link above) or you use the pcie to to do the same as with a normal pcie slot and a sata controller, the sata controller is just smaller and more fragile the small housing and the power supply can be a problem as you not just need a m.2 card with a sata connector on it you also need sata cable, power cable and room for a 2nd disk and all that without blocking the airflow to much usually you think about the system design before you buy one, having just one hdd aka no redundancy is not suggested but if you have 2nd nuc and mirror you data in (more or less) realtime then you might be ok with just one disk, might be a better solution then going to far out of the systems intended design

thats what backup is for and the scale depends on then work done and the kind of data (juggling 8k videos needs more space then a photoshop project or some office documents in most cases the really important data is just e few TB and the daily amount is not that much have the data on your computer, backup that to nas (daily) and then backup the nas (weekly) its also possible to use a usb hdd for backup of important data, it does not have to be a 2nd nas you can read on the internet about recovering btrfs and we have some cases here in the forum (2-3?) you can search for i had that myself last year and even after trying to repair, the data last written where damaged or gone and the file system seemed beyond repair to me if you have all the time to learn everything about btrfs and enough disk space to keep the old malfunctioning btrfs - but thats usually not the case, business continuity plan is also about letting go at some point and continue you can try to involve data recovery specialists like kroll ontrack but i guess the money that would take is beyond what you can afford, data recovery is often compromising too, time and money are often the limit its more important to find the source of the problem

like this https://geizhals.de/?cat=hdssd&xf=4832_4 and then take the exact product code, but there only seem to be max 2TB for sata one a other way is to use a (mechanical) adapter to get the sata connector from the m.2 https://www.amazon.com/SATA-NGFF-Adapter-Power-Cable/dp/B01FE8NKC2/ or use a m.2 card with pcie connected sata chip like asm1061 or similar and use a normal sata 2.5" ssd

i was more thinking of buying a used board like from ebay or a company selling used hardware when looking for using a pcie card that is a possible solution (one of the adapters with a 25cm cable https://www.amazon.com/ADT-Link-Riser-Gen3-0-PCI-Express-Extension/dp/B07Z4QR598/ the flex cable gives some freedom to place the card in the housing, there are m.2 adapters with a pcie 4x slot soldered to it but they will give you some headaches about mechanical problems (space the pcie card takes and stability of the thin board) sounds like the only map the sata port to m.2 when using sata on m.2, so no 3rd port over the sata connection of m.2 918+ as it could use hardware transcoding of the igpu either by a m.2 card with 2 or 4 ports (the 5port did not work for me so i'm sceptical to use that one) a less head producing chip like asm1061 or a marvell might be ok on a m.2 board i cant remember having seen a m.2 e key sata card so best chance is to look for a card for the normal m.2 slot

no, that one is a addition for special cpu's that would be unsupported by the driver but still using the same gen 9.5 gpu like coffee lake its meant to be copied directly to disk, not on the loader - as your cpu is older you wont need that no, the extra/extra2 does not contain i915 anymore as the new driver that comes with 6.2.3 work the same way as jun's driver was before also its not that easy to copy something into extra/extra2.lzma (7zip can be used to unpack but can not modify it), i do it the same way jun did it within linux with cpio

check the logs in /var/log when the self healing of btrfs fails its a sign of other trouble like ram, cable or controller problems use you backup and offload whats not in the backup , repairing a btrfs is usually not a long term solution locate the (hardware?) problem, fix it, recreate the volume with backup and offloaded data

beside that the mac might not be related to your problem, you would shutdown dsm, remove the usb and edit the grub.cfg in the way that mac and number of nic's match the old one and then restart dsm with then modded usb serial and mac can be changed at any time, dsm itself should be no problem, things like that can happen to a regular dsm system when a hardware fails and the disks are put into a replacement unit

you did not post any logs, in baremetal systems I'd expect to find things before the cash happend it might be essential to find out how this happened or you might see the same in a foreseeable future again as its a vm check if there is caching active and if there are problems in that area (crashes where cache content was lost) some people use pci passthrough of the controller or raw mapping of drives that would prevent any host related cache problems

if you recreated the loader and along with it the grub.cfg your system might have a different mac address now also possible that you ssh key of dsm changed, depends on what exactly was done i'm not familiar with rclone and not sure that i get it correctly, i would need more information about what you try to do with it and how its supposed to work

yes and no, just one cpu core is little odd but even under best conditions, 918+ is limited to 8 threads and with HT active thats 4 real cores and 4 HT cores your best shot to get the most out of the system as baremetal is 3617, that has 16 threads and you would need to disable HT or you end with 8 real cores and 8 HT cores (one HT core about 20-25% of a real core) not sure why its that kind of cpu but if you had vm's in mind then consider a hypervisor esxi or qemu/kvm like proxmox and use dsm in a vm the limits are documented here https://xpenology.com/forum/topic/13333-tutorialreference-6x-loaders-and-platforms/

the log is clear, if using 6.2.3 you cant use jun's old extra/extra2 as synology implemented a new i915 (more or less the same version level as jun's) and made modification to the kernel for this backport, rendering jun's driver useless the new driver works fine but only if jun's driver is not present and the new extra/extra2 takes care of this (no i915 driver in extra/extra2 and if old driver is present it gets deleted) either you did not have 6.2.3 before the update to 6.2.4 or you forgot that you changed the extra/extra2 there is no way using 6.2.3 and hardware transcoding with jun's old driver present

thats probably a driver problem, check if the new 0.13.3 extra/extra2 is an the loader, if you use jun's default its preventing the use of the new i915 driver that comes with 6.2.3 https://xpenology.com/forum/topic/28321-driver-extension-jun-103b104b-for-dsm623-for-918-3615xs-3617xs/ you can check /var/log/dmesg for messages about i915 and you should at least see the pci device id 8086:191D in dmesg

ant that is working without any added drivers? the spec for that board is realtek 8105 (100Mbit nic)and there is no driver for that in jun's base set (no r8101.ko) but maybe you used a pci nic already because with just 10 megabyte per second its not going to be very useful as a NAS what dsm version did you try to install? it would need to use 6.2.0 (23739) or 6.2.3 (25426) to match the drivers in the loader yes, serial port (you board at least has one), null-modem cable and serial console like putty maybe your monitor is to slow when switching resolution does not matter 1st option is default, 2nd is reinstalling for factory defaults and 3rd is for esxi, so no need to the grub menu atm

6.2.2 is a terrible choice as its drivers are incompatible to the initial 6.2(.0) and the last working 6.2.3 i guess i did miss the part where i wrote about the 2 nic limit in 1.04b 918+ https://xpenology.com/forum/topic/21663-driver-extension-jun-103b104b-for-dsm622-for-3615xs-3617xs-918/ "... !!! still network limit in 1.04b loader for 918+ !!! atm 918+ has a limit of 2 nic's (as the original hardware) If there are more than 2 nic's present and you can't find your system in network then you will have to try after boot witch nic is "active" (not necessarily the onboard) or remove additional nic's and look for this after installation You can change the synoinfo.conf after install to support more then 2 nic's (with 3615/17 it was 8 and keep in mind when doing a major update it will be reset to 2 and you will have manually change this again, same as when you change for more disk as there are in jun's default setting) - more info's are already in the old thread about 918+ DSM 6.2.(0) and here https://xpenology.com/forum/topic/12679-progress-of-62-loader/?do=findComment&comment=92682 ..." the one i tested did not work stable even when equipped with a heat sink, also its very finicky when it comes to the mechanical side, needs support from below or you break the card (its extremely thin, you cant just plugin in cables with the card installed or you will break it) and with the force sata cables employing on the card it needs a good cable support taking off force as much as possible) beside this i don't thing the card would fit in the place the mini-itx board can offer i wrote about the m.2 card and some other cards here https://xpenology.com/forum/topic/35882-new-sataahci-cards-with-more-then-4-ports-and-no-sata-multiplexer/ i also tested two m.2 to pcie 4x adapter, only the one with the shorter cable seemed to work properly and there also was a lot of strain to the m.2 slot, not so sure if i would use that in a system with real data whats wrong with the pcie 4x slot you have?, a pcie card with a jmb585 would be ok you could even us bigger 8x cards as the slot has a open end whats with the four 1GBit nic's? there a usb3 5GBit nic's too and best might be just using a 10G nic i haven't seen 10g nic's for m.2 but there are at least 2xRJ45 1G nic's https://www.delock.de/produkte/S_63425/merkmale.html https://www.delock.de/produkte/S_62754/merkmale.html the whole system design seems off, would be much easier to replace the board with a mATX one having 6xsata and more pcie slots, would make a more stable system with a more predictable performance

04:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID SAS-3 3008 [Fury] (rev 02) Subsystem: Dell PERC H330 Adapter Kernel driver in use: megaraid_sas Kernel modules: megaraid_sas 1000:005F MegaRAID SAS-3 3008 [Fury] that driver is for raid mode so it still has the IR firmware and you use a hardware raid raid mode is only supported by additional drivers and not that good with that not to old cpu you would be able to use 1.04b 918+ and the megaraid driver from the newer 4.4 kernel would support the 1000:005F but there are some problems with lsi sas on that one related to disk hibernation https://xpenology.com/forum/topic/28321-driver-extension-jun-103b104b-for-dsm623-for-918-3615xs-3617xs/ i'd suggest flashing IT firmware to it and use 3617, the lsi sas driver in there are from synology and are native to that 3617 unit, they should work best https://forums.servethehome.com/index.php?threads/flash-crossflash-dell-h330-raid-card-to-hba330-12gbps-hba-it-firmware.25498/ you would need to offload all data and install new that way you took the wrong start by using a raid mode controller, dsm in its core is completely about single disks and software raid with 6.x and its way of using synologys kernel we are much more restricted and with just me making drivers and being unable to change code of kernel drivers its hard to have newer lsi drivers (synology isn't offering source code for the drivers they use in 3617, with code they tempered with we might be able to do a megaraid_sas driver that works properly but for as it is we don't have that) when using a hacked appliance as we do here its much easier to bend in the way the system is implying or choose another OS so its more like IT firmware or using (maybe) Open Media Vault

"Sudo before 1.9.5p2 has a Heap-based Buffer Overflow, allowing privilege escalation to root via "sudoedit -s" and a command-line argument that ends with a single backslash character." take sudo binarys from 6.2.4 and copy them to 6.2.3 or compile new version from source (https://www.sudo.ws/stable.html) in the build enviroment used for packages and driver if you figure out what cve it is you could help yourself too (cisco talos has a lists, you would need to compare with already mentioned and fixed stuff, or just wait for synology to be more precise or nudge them to give more information) i'd say if that is important for you start a initiative for delivering and maintaining 6.2.3 security updates, i'm sure you will find some people willing to help in at least deliver information and ideas, getting people to do actual work consistently will be much harder so you should keep planning to do the compiling and base testing yourself a good amount of security fixes might be possible by backporting and compiling things and by splitting things in more simple tasks it would be possible to find one person doing things once or twice if it hits the sweet spot of feeling confident (like comparing and adapting php code for someone doing that kind of stuff for a living) no (easy to handle) security updates from now on and that goes for functional fixes like in btrfs too but we knew that all along and the "peace" lasted just longer because synology did not made progress with 7.0 as they planned under normal conditions we would have seen this situation much earlier, from 6.0 to 6.2 they had 1 year for a new version so the expectation would have been q2/2019 for 7.0 - we are in luck (kind of) it took 2 years longer and we had a nice worry free time (not entirely, but thats just because of laziness in the xpe community) looks like it for now until we know what the errors on the serial console are about (they are the same as in 7.0 preview and 6.2.4 comes with the same kernel version as 6.2.3 so its not a mismatch in kernel, seems to be something different and if taking it worst case its a new protection, but might be less then that) if you want to play a little (test installation) you can update to 6.2.4 and when the boot stops, switch off, replace zImage on the loader with the one from 6.2.3u3 and start booting again, that will install 6.2.4 but you will end with a not entirely working system, the packages don't start, network can't be configured in the gui, ... also the driver in rd.gz are still from 6.2.4 and there might be problems with them too i don't know if its possible to replace the *.ko files with older ones in rd.gz or take the one from 6.2.3 and replace the VERSION file but i guess there is a protection against tempering zImage and rd.gz - might be a thing to look into if we still have that situation for longer, atm i have enough other things to to feel free to poke around with a partly running 6.2.4 :-))) dsm failing on updates is not new, normal with major updates (6.0, 6.1, 6.2) as they usually come with a newer kernel versions making at least drivers incompatible and it seemed with every of them they changed or added protection a example for minor updates breaking things ? how about 6.2.1/6.2.2 (even if that one seemed to hit us accidentally as it seemed to address pcie power management driver problems and synology addressed that in changing the kernel config and later on fixed it properly - at least that's my theory) and as flyride already pointed out its just one update - if you want to count it extremely properly then its 3, because 25556 was replaced silently after 2 weeks with new files of the same version number lets start with "open sourcers" - no we are not, we dont build our own version from source, we use synology's stuff, not just the files (<cough> - quick connect - i don't but some do) on the other side synology does not comply with GPL and other licenses they use to create DSM, there are lots of examples and the most obvious is they NEVER release kernel source when they release a new dsm updates or versions (you can check immediately by looking for the source of 6.2.4) - even when poked for years they did not change, its not that they forgot it once or twice, its there strategy and only legal trouble seems to be the one thing that bothers them (they don't seem grateful to the thousands of people and work hours others did and don't want to be a part of it or add something, just use it to make profit) i tend to say freeloaders, and synology could be much more hostile if they wanted to, i can imagine a lot of easy to do things to curb xpe users, maybe that changes now with 6.2.4/7.0 , i guess the two years extra for 7.0 also include plans to get rid of freeloaders its also a question if its worth the effort to use dsm anymore, there are alternatives that improved over the years and docker makes extensions more universal so the 3rd party packages of dsm are not that interesting anymore (and are fading), when dsm 7.0 really is unable to load the older spk's i guess a lot of (xpe) people will stay way from it for longer then some expect i maintain the alternative of using open medial vault, if dsm breaks i can boot up omv from a disk or usb and have network access to my files and if synology gets nasty i will just switch to omv (btrfs and SHR are no problem, just work when starting omv) https://xpenology.com/forum/topic/42793-hp-gen8-dsm-623-25426-update-3-failed/ its still a nice thing that you can switch from an dsm unit to any other linux without offloading all data, also makes recovery possible if things go wrong having the maintained security updates might matter for some people if the make dsm accessible over internet (like photo station or nextcloud) i'm more on the side of using vpn to access dsm, makes a much smaller attack surface but will also shut out less IT centered people like family member's we will see what happens when dsm 7 is out for 1-3 month and i'm not even sure if 7.0 will really have something to offer, i haven't seen anything that triggers reflexes to make it a must have (at least for me)

cpu is haswell or better so even 918+ would be possible H300? - not found H310/H330 maybe? or H7xx (the H7xx models are mentioned in dell's specs for the T430) the important thing would be the lsi sas chip its based on not sure what list you checked but its usually about the original lsi models or the chips used, there is a good amount of oem types from ever server vendor so its really combersome to have a complete list if you have 5.2 running you can list the devices with driver and pci id "lspci -k" in general its suggested and supported to have the controller in IT mode (HBA mode) where you have just plain single disks and not raid capability's as dsm makes its own software raid in general i'd say use 3617, it comes with newer drivers from synology then 3615

if you have omv up and running you can also do the same as with a recovery linux, you can login by ssh in background, mount the dsm system's raid1 volume and check if it was a 6.2.4 update - only difference is you have more time as you already have a nas running to access your files (you still need to mount the file system and crate a smb/cifs share but thats pretty self explanatory in omv) https://xpenology.com/forum/topic/42765-how-to-undo-a-unfinished-update-623-to-624-no-boot-after-1st-step-of-update/ you would just look for the update files and check the two "VERSION" files its also possible to have a look to the files on the 2nd partition of the loader, the file size of rd.gz and zImage should make it possible to determine the dsm version an the loader (and its also possible to extract the rd.gz and check the VERSION file in there)

that one is a compile parameter of the kernel and the kernel cant be changed as we don't have all source (it was easier to circumvent the protections and make it look like its running on a legit hardware then reverse engineering all the missing parts) even if you ask more often, the answer is still the same https://xpenology.com/forum/topic/42407-only-16-threads-on-ds3617xs-with-e5-2678v3/?do=findComment&comment=198992

https://xpenology.com/forum/topic/28183-running-623-on-esxi-synoboot-is-broken-fix-available/

the intention here is to have a running omv installation on a media (can be a separate disk, or a usb flash drive), add the dsm disks and boot that omv up as tested over 2 years ago it still works that way dsm usb boot drive and the dsm disks disconnected installed the recent omv5 (usul, kernel 5.x) to a usb (had one usb containing the iso transferred with rufus and a 2nd as destination), using a ssd or even hdd might be much faster but the usb is easier to handle and cheaper (updating took ages, i guess the iops of the usb is just to low, so if it has to be fast to setup choose a sata disk) after finishing the omv installation, updating it (all pretty much standard as omv's own resources suggest it) and testing it by login into the web gui i shut it down, connected the dsm disks and booted, omv web gui showed the raid5 data volume i had created for testing and i was able to mount it, with the smb/cifs share of omv i was able to access the data over network, successful fallback test for dsm - btrfs is nor problem with omv it just works after shutting it down i booted with the dsm boot driver and dsm came up again and there are no complains about the raid5 either in dsm or in omv to complete the test i created a SHR1 with 2x500GB and 1x128GB, resulting in a raid5 and a raid 1 "glued together" by lvm omv recognized the raids and volumes and showed a mountable volume (the shr1 volume) only smaller problem was that dsm created a label containing a space and omv complained about that and did not mount it seems to be a problem with a debian package the are using and as long as its not fixed upstream in debian its not going to workj in omv but when looking at the label its nothing specific, just a date and time and version number to make it unique i renamed the label, kept the date and time and removed the version number that was separated by the space (but any label will do) btrfs filesystem label /dev/mapper/vg1-volume_1 2021.04.10-14:32:17 after that i was able to mount the shr1 volume with the web gui and use it the normal way after shutting down omv i reconnected the dsm usb drive and booted dsm again, no problems with the SHR1 volume so omv is still a easy to handle fallback when dsm craps out, SHR or btrfs is no problem (same as tested over 2 years ago) i will keep the ready to boot usb with osm for testing, its nice to have (same as the system rescuecd usb boot media)

das ist 6.2.4 und da wird (in englisch) doch recht auffälig gewarnt wenn man sich im forum anmeldet 6.2.3 + update3 ist der stand den du nutzen kannst (aka v25426) https://archive.synology.com/download/Os/DSM/6.2.3-25426 https://archive.synology.com/download/Os/DSM/6.2.3-25426-3