IG-88

i'm puzzled how you came from a clean btrfs file system you could mount (and presumably read) to you would have been able to copy your data to a backup location after mounting volume1, you still had two valid disks and thats all you need if you have a one disk redundancy like shr1

that might be enough if you want to test the loader (does it boot, is it found in network) but as soon as you want to install the usb vid/pid in grub.cfg needs to match to the usb flash driver you are using to boot give/precise more information! there are three DSM 6 versions like 6.0, 6.1, 6.2 each with its own loader for 3615 whats the hardware you are using (mainboard, cpu, network card, storage controller) did you already read this? https://xpenology.com/forum/topic/13333-tutorialreference-6x-loaders-and-platforms/ https://xpenology.com/forum/topic/7973-tutorial-installmigrate-dsm-52-to-61x-juns-loader/

i would not say that a bobcat core from 2011 is "newer" hardware the amd minimum is "rumored" to be piledriver and thats from 2012, so seems very possible that the cpu in question is no 1.04b 918+ material

if you want to know 1.04b 918+ is even possible you would need to be more precise about the cpu thats the thing to start with https://xpenology.com/forum/topic/13333-tutorialreference-6x-loaders-and-platforms/ the thing about mbr is more does it boot or not, if you try a hp desktop with the normal gpt version its not booting at all and thats the point where you need mbr if the normal version worked then the difference in success was not about mbr or gpt 1.03b cant do clean uefi, it needs csm/legacy mode and you also need to use the non uefi usb boot device (that migh only be visible after booting once with csm on just try the normal 1.03b version and make sure to have csm on and the right boot device

works on my system (not SHR, just plain raid6, so no lvm2) btrfs device stat /dev/md2 [/dev/md2].write_io_errs 0 [/dev/md2].read_io_errs 0 [/dev/md2].flush_io_errs 0 [/dev/md2].corruption_errs 0 [/dev/md2].generation_errs 0 try it with /dev/vg1/volume_1 (logical volume) there are a threads about checking in repairing btrfs here in the forum and you can also use a search engine to find more about it, i dont have a tested workflow for recovering a btrfs file system, maybe @flyride has good advice how to proceed https://xpenology.com/forum/topic/30702-btrfs-volume-crashed-storage-pool-ok/#comment-151129

your system does not need and support mbr version of the loader? needed often for HP desktop systems, what hardware are you trying to get up and running? used the mbr loader on my hp desktops the last 2 weeks to test 3615 and 3617 drivers, no problems (used Win32DiskImager 1.0)

driver liste here https://xpenology.com/forum/topic/12859-driver-extension-jun-103a2dsm62x-for-ds918/ say's its sky2.ko as driver, alle the drivers are still there in the current versions of extra.lzma for 6.2.3 realtek 8111(8168 is also no problem 2nd controller beside chipsets sata is JMB36X and thats supposed to be ahci (should not be set to raid mode) chipset also needs to be set to ahci (no raid, no ide) cpu is no problem but you have to use 1.03b 3615 or 3617, 1.04b 918+ need at least 4th gen haswell cpu its documented her in the tutorial section https://xpenology.com/forum/topic/13333-tutorialreference-6x-loaders-and-platforms/ you did not read the faq? https://xpenology.com/forum/topic/9394-installation-faq/?do=findComment&comment=81094 so shr and 3615/17 is no problem even if that would be reset on a update it would still be working, only effect without the setting is that you cant create a shr, under the surface its working all the time and support is prsent, just switched off in gui by default so you are more or less done installing, just use the 3617 you have and change synoinfo.conf after installing (if a volume was already created just delete it and create ne one with shr)

also if you are done with backup and can reboot the system you should check the RAM for errors (memtest from a bootable live/recovery linux)

sudo btrfs device stat /dev/vg1 what does this return

i would not be so fast assuming anything like that, a simple write process should not do any damage to the file system you can already start looking into /var/log/ for clues what went wrong, you know roughly date and time so you might be able put things together from different logs proceeding with repair or restore will only make sense if you can pin the reason or you might end up with the same problem in a few days start with disk.log, kernel.log, messages, dmesg

thanks 1st one looks interesting as its all hotswap but placing the psu and board on top will be to much trouble as the psu will be more noisy and my two ahci controllers will be a pain and it would need a extremely flat cooling solution, but looks like good solution for embedded cpu boards with 12 sata and 10G nic already onboard i guess the 2nd one will fit my needs, found it on amazon under different brands now, with 4HE it could even hold more drives (but have not spotted that one as 4HE) edit: that might be the 4HE version https://www.amazon.de/Holzrahmen-INDUST-4U-energysaving-Tiefe-380/dp/B00GQYO8OI/

i'm not a expert on this, just done that once, as you are unmounting the volume in the process make sure you finished the backup sudo syno_poweroff_task -d sudo unmount /volume1 sudo btrfs check --readonly -p /dev/vg1

you would need to have a look to the log files in /var/log/ but dsm usually schedules a check (scrubbing) oneth a month btrfs has some redundancy in itself, if thats broken you should offload as much as you can and should not write to the data volume maybe look up a btrfs file check that does not correct/repairs anything to know if there is a problem with the file system as long as you dont know what caused the problem you should assume the worst and backup the files

as synology just released the kernel source for 6.2.3 i'm back on square one with the new drivers, i will need to reconfigure the build environment, test it and redo some additional kernel patches for certain hardware (alx "killer" nic's, mvsas)

i's suggest the same as the dsm does, backup as long as you still have access, atm you might not need a recovery procedure it would be good to know in whats state the file system is and how it came to this to prevent is happening again but thats 2nd 1st priority are offloading the data asap if the disks, raid and volumes are intact then there might be damage in the btrfs system and if its self repair cant do the job then there might be problems beyond repair (i had that once when "experimenting" with ssd write cache combined with controller problems - ended up in deleting the volume and recreating it from backup)

ok, if you dont want/need dsm to be working and just want to get access to the data i'd suggest two options 1. use a normal or recover linux and assemble raid and lvm so you can mount the volume https://xpenology.com/forum/topic/7004-tutorial-how-to-access-dsms-data-system-partitions/ 2. install open media vault aka ovm (to a different media, dsm drives not connected) and after having omv running, shut down, connect all the dsm drives and boot up omv, in theory omv should detect the data partitions of the dsm data volume (3rd partitions on each disk, 1st and 2nd are dsm system raid1 and linux swap also raid1) https://www.openmediavault.org why/how is that working? dsm runs not from usb, there is just the kernl for start boot process, all the dsm system is a raid1 volume over all disk and there is swap as a 2nd partitions, also raid1, on every disks, the "volume" where user data are stored is always after these two partitons and when only installing dsm fresh (without any automatic creation of a data volume) there would only be two partitions on every disks, the data "volume" is then a independent created raid depending on the users choice and that is the one you are after if the disks where different size and SHR was used for the creation the layout of partitons and lvm can be more complicated but as long as nothing is damaged a normal linux with mdadm and lvm should be able to detect that, SHR is just a clever automatic way of using standard linux tools to get things done, what synologys SHR does can also be done manually on every linux by using mdadm and lvm

synology released the kernel source for 6.2.3 in the last few days (until now we had only 6.2.2) https://sourceforge.net/projects/dsgpl/files/Synology NAS GPL Source/25426branch/ looks like even libhydrogen is now part of the release (was missing earlier source releases)

i assumed you would know how to prepare the loader if you had dsm 6.0 or 6.1 before you would be able to do the same with a newer version of the loader beside the tutorial here in the forum you could also use a youtube tutorial about installing dsm 6.2.3 also you did not give any information about your hardware and the loader/dsm you used before there might be other options like going back to the version you had before

usually synology suggests a update to the recent version and thats 6.2.3, if you started with 6.1 and loader 1.02b you would need a newer loader 1.03b that would need to be prepared in the same way as 6.1 loader 1.02b (grub.cfg, usb vid/pid)

linux is very different from windows when it comes to drivers, you would need to compile your own driver from the source, you cant just use a (binary) driver

try the version the loader was made for (6.0.2) https://global.download.synology.com/download/DSM/release/6.0.2/8451/DSM_DS3615xs_8451.pat maybe do a test install with your new usb loader and a single empty disk, if that works out, use the usb with your 5.2 disks (if you got 6.02 installed you could pretty much do the same steps with loader 1.02b or 1.03b and try to install dsm 6.1 or 6.2) there is a warning in the 6.0.2 tutorial and its kind of prominent

anyone knowing a case thats not higher then ~4HE (19cm) and max. 40 cm depth that can handle 12 disks i use a silverstone SST-GD09 that i customized to fit 12 vertical 3.5" hdd's with an micro atx board that has only slightly more depth then mini itx i did see some rackmount units with 38-40cm but non where you could fit 12 disks ootb (either fixed mounted internal or hot plug), units with 12 x hot plug are usually 55-66 cm in depth the thing that came near it was a silverstone RM41-506 (but it has 44.6 cm depth), with 2 x FS305 it could hold 14 disks and 10 would be hot plug https://www.silverstonetek.com/product.php?pid=887&bno=0&tb=43&area=en

its not a mismatch of usb vid/pid, that just throws a mount failed on the serial console and dsm does not start at all i guess taking a new usb and redoing the loader from scratch cant do anything wrong if dsm does not start it can be checked in network (ip address), as the loader comes with 6.2.0 and there is a newer kernel (dsm system) on the disk it should offer recovery/repair and doing so will copy the newer kernel back to the loader (only takes less then a minute) and it should do a reboot, after that dsm should start again (if a extended extra.lzma was used it should also be copied to the new usb - and no files should be used from the old loader)

if looking for a hardware its good to check dmesg log for drivers loading and for pci vid/pid there are drivers for lsi sas cards in ir mode (megaraid) the only thing you dont see in that case is the disk, the driver will detect the hardware

:-))), and again https://xpenology.com/forum/topic/8057-physical-drive-limits-of-an-emulated-synology-machine/?do=findComment&comment=122819