IG-88

https://xpenology.com/forum/topic/32867-sata-and-sas-config-commands-in-grubcfg-and-what-they-do/ vor allem der 2. lin (gugu...) config SYNO_SATA_REMAP, also sata_remap= das dann als kernel parameter beim boot mit gegeben wird aber mal davon abgesehen ichich so meine zweifel das du eine syno geeignete 10 port karte hast, das mir den zusätzlichen ports klingt verdächtig nach asm1166 und der hat nur 6 "echte" ports und alles was über sata multiplier läuft funktioniert nicht in dsm rein theoretisch könnte es eine karte mit 10 ports geben die über einen pcie multiplexer zwei jmb585 mit je 2xpcie in einem pcie4x slot optimal betreibt aber das wäre teuer und bisher habe ich das noch nicht gesehen also schreib mal genau was für eine karte das ist, sonst versenkst du zeit und kannst sie am ende nicht mit den ports nutzen die du brauchst es lassen sich bei solchen karten immer die echten ports und der 1. port des mulitplier chips nutzen so das sie für dsm wenigstens mit der port anzahl der verbauten chips nutzbar sind echt unschön wäre ein asm1062 (2 ports) und an jedem port ein 1 zu 5 multipliert, was dann auch 10 ports sind von denen man aber nur 2 nutzen könnte und aucßerdem ist der asm1063 nur pcie 2.0 mit einer lane, sindsind dann max. 500MB/s (also selbst wenn der multiplier gehen würde müsste sich die 10 platten das teilen)

i might add that checking firmware with asm1166 is possible/suggested https://docs.phil-barker.com/posts/upgrading-ASM1166-firmware-for-unraid/ https://www.silverstonetek.com.tw/downloads/Software/ECS06 firmware for Intel 600series chipset.rar my asm1166 was a older one and i updated it last week - but its still only used for messing around, i still have jmb582/585 in my system i use with xpenology i did see a problem like this with my card (32 ports recognized) https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259705 i haven't checked yet if that is gone now

moving disk to a different unit and upgrading dsm is also a supported scenario (like having a ds3615 with dsm 6.2.4 and moving to a ds3622 with the disks if you already have a ready made working usb for the new system with the right dsm type and network settings (mac) you can just move the disks, boot with the new loader usb (for dsm 7.1) and look what is suggested, as the loader (like the usb dom in a original new syno system) is already 7.1 it will mount the old system, recognize the older dsm version and will suggest a upgrade (along with the change to a different "hardware", there is a list of "official" paths in syno's KB but if you already come from a dsm6 xpenology afaik there is no limit of what your destination system can be, you can choose whatever the dsm7 loader offers (that limit is mostly relevant when coming from original units that are ARM based) migrating like that keeps all things like 2GB size of system partition (if you set up a new system on empty disks the "new" default size is 8GB for the dsm system raid1 on every disk in the system) or the file system of the data partition(s), like ext vs btrfs), btrfs is already needed for some things (VMM as example), not much known about the new 8GB system size (i guess that might get important in 5+ years?) there might also be some "misses" with packages as dsm7 uses a different way but by now most 3rd party packages are available and you would have to deal with that anyway even when setting up a fresh 7.1 system if you dont have new disks and a backup then moving disks is the easiest way with nearly no offline time and if things are not the way you like it you can still reset dsm to defaults or even delete everything and start over with empty disks and setup from scratch

schau dir die logs an, evtl. kann man da etwas sehen außerdem wäre zu hinterfragen ob es wirklich das system steht oder du nur nicht mehr über netzwerk dran kommst falls du irgendwas mit power schedule aktiv hast abschalten, bei hdd hibernation auch alles abschalten ich würde einen extra usb stick und einzelplatte nehmen und mal mit dem gleichen system (1621?) eine frische installtion mit defaults versuchen, wenn sich das reproduzieren lässt mal auf 3622 wechseln und sehen oh es da auch passiert, von usb booten und ein hardware stress test programm 1-2 tage laufen lassen um zu sehen ob es da etwas gibt wenn der ram 2 riegel sind dann mal nur mit einem versuchen und dann den anderen, netzteil wechseln wenn möglich (wenn man eins hat sind das nur ein paar handgriffe)

if there is no pci device present (in the vm) then there will be no driver loaded (and there will be no try to even load a firmware you would need the real thing in the vm to test that ... well there is a working driver for 10th gen igpu in the loader, i guess its source is the folowing thread and even in a hypervisor/VM enviroment is possible https://xpenology.com/forum/topic/59909-i915ko-backported-driver-for-intel-10th-gen-ds918-ver-701-up3/?do=findComment&comment=325293

??? they? synology vm? you lost me here

copied the file from the loader (arpl.img open with 7zip on windows) \arpl.img\2.img\modules\firmware.tgz copied that file to a share on the server and in the console extracted it and copied it files to the right place you need more rights to do it so do a "sudo su" after login on the console (be careful you can mess up the system when doing the wrong things - its "you asked for it you got it") go into the directory where the firmware file is (usually /volume1 and then in directory named a s the share, check with ls that ) and then: tar -xf firmware.tgz --directory /lib/firmware after that you can check again ls /lib/firmware/i915 reboot and check again if there is something in /dev/dri ls /dev/dri if the driver is loaded properly then there should be something like: card0 renderD128

thats just the files dsm has by default for 918+ and 920+ aka apollolake and geminilake, pretty sure a 10th gen cpu will not work with just these two files, the driver will not load properly without the firmware files if the firmware repository from the loader (fiemware.tgz) would be present then there should be more (the files i listed above) works on my system (admin user), maybe just try "dmesg" to see the whole log if you see it you can scroll backwards in the console window

some system from synology come with atlantic (aquantia) driver, usually units with a ope pcie slot, synology switched/added a AQC10x card to its line (maybe replacing the old tehuti card), somewhere in 6.2.2/6.2.3 it came into 36xx images (918+ does not come with this driver) and with 3622 7.x there are even two drivers (atlantic.ko and atlantic_v2.ko) one is v2.4.3.0 (old) the other is v.2.4.14.0, i dont know how they handle this in DSM, maybe there are some checks that prevent the correct driver to load? maybe check the log with dmesg for "atlantic" with this: dmesg |grep atlantic you should at least find something about loading the driver, maybe we will see if its the new or old driver thats loaded you can also try to load the newer driver manually insmod /lib/modules/atlantic_v2.ko and then check again mit dmesg to see what log entry it generates btw there is a atlantic driver added in arpl lately (two days) and its to expect to be in the next release https://github.com/fbelavenuto/arpl-modules/commit/1eccba34dbf1c631153e942acfcdae2d0e729026 its v2.5.5,

try dmesg |grep i915 and whats with the ls for the firmware files?

i only tested the latest 1.1beta2 and dva1622, that's why i described what to do you could also check the log with dmesg dmesg |grep drm might look like this if working [ 30.331911] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 30.339387] [drm] Driver supports precise vblank timestamp query. [ 30.358388] [drm] Finished loading DMC firmware i915/kbl_dmc_ver1_04.bin (v1.4) [ 30.628711] [drm] failed to retrieve link info, disabling eDP [ 30.637839] [drm] Initialized i915 1.6.0 20171222 for 0000:00:02.0 on minor 0 [ 30.706925] [drm] Cannot find any crtc or sizes [ 30.711895] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device [ 48.565878] VFS: opened file in mnt_point: (/dev), file: (/dri/card0), comm: (drm_tool) [ 48.616606] VFS: opened file in mnt_point: (/dev), file: (/dri/card0), comm: (drm_tool) [ 48.974574] VFS: opened file in mnt_point: (/dev), file: (/dri/card0), comm: (drm_tool) just check the firmware files like this ls /lib/firmware/i915 it should look like this if all the firmware is present bxt_dmc_ver1_07.bin glk_dmc_ver1_04.bin kbl_dmc_ver1_04.bin rkl_dmc_ver2_03.bin skl_dmc_ver1_26.bin cnl_dmc_ver1_07.bin kbl_dmc_ver1_01.bin rkl_dmc_ver2_02.bin skl_dmc_ver1_23.bin skl_dmc_ver1_27.bin thats a "lower" tier, pretty sure this should work with the 10th gen i915 driver addon

driver for this is most likely r8152.ko (realrek usb 2.5G nic) if there is no driver in the loader already you can try add it as package (arpl should have one afaik) https://github.com/bb-qq/r8152 there is also a 2.5/5G usb driver (aquantia chip) but i guess your adapter is cheaper and only 2.5G so i'd guess its realtek https://github.com/bb-qq/aqc111 you can check about the hardware with lsusb and with the vendor- und product-id its safe to assume what hardware is used there is a addon in the loader for 10th gen, afaik no need for for any parameters check if there is the needed firmware in /lib/firmware/i915 (on my dva1622 install with the latest loader it was missing, only the fw for apollolake/geminilake from dsm itself present) it would also be good to mention what 10th gen cpu it is as there a a lot of different gpu types in there if its working you would see devices when checking with "ls /dev/dri"

usually up to 24 war the way to go with the "old" style of disk handling try to make it 24 and no esata and no usb an look for the outcome it might also be possible to do disk remapping with syno's kernel parameters but that's going to be a lot of try an error to get it right esataportcfg="0x0" maxdisks="20" internalportcfg="0xfffff" usbportcfg="0x0" (or usbportcfg="0x300000" that way you dont have to touch the 6 ports on the main board (in that situation its best to disable the whole onboard sata part if possible, so look fot data controller disable in bios, if there is some stuff about sigle ports ignore it, look for disabling all ports at once)

Hi IG-88, thanks for the tests. What is the correct rtl8168h-2.fw file? after extracting and copying your firmware.tgz from the loader manually on the right place the file fw file for the realtek was present and i did not see the message anymore, that was the1st hint that something was off (the loader did not use its firmware files when installing) the problem about the wrong files war with the bnx2x driver but there might be other hidden problems like that if the *.ko files are not checked for the right dependencies to firmware (easiest way is still to just have them all for the driver that is used but that might take some additional megabytes for the firmware.tgz) we has similar things before, like jun's extra.lzma not having not all firmware files for tg3.ko resulting in most dell servers to have problems with not working nic's (not found in network after boot), same driver with hpe servers usually worked kernel.org drivers usually have separate firmware files, drivers from vendors often have them integrated as extra files in some *.h files and are build into the *.ko when creating the driver nastiest one was tehuti, the driver itself references to all firmware files (checks if present when compiling and only activation that part if the file is present) but every oem only packs its own firmware files when providing a driver source for its card, so it need some kind of collection to have all needed parts (firmware files) to support all possible hardware versions of a card - one reason to like kernel.org drivers, much cleaner and predictable in that way, you can check the *.ko with modinfo in will see what fw files are needed (but different fw files depending on the driver version in the kernel, i've seen two types of mismatch one is of different hardware in the same card (like different phy's on a nic) on 2nd like seen with the bnx2x where it needs the right (older) version of the fw files to match the older driver in kernel 4.x

asm1166 in general works (two pcie lanes with up to pcie 3.0 so max. ~2000MB/s for all ports) but it "only" provides 6 sata ports and the card does have two connectors usually used for 4 sata ports each and it has 8 led's for disk activity, so it will be two ports "made up" by sata multiplier chip not mentioned in the description you would not be able to use 8 ports with dsm, just 6 but it would not hurt and you could still use it late with another os then syno's dsm and use the other two ports too (performance will be lesser on these ports as they are "shared"

Test with dva1622 - arpl 1.1. beta2 system was 8th gen intel cpu on a gigabyte b360m-hd3 (the usual realtek onboard nic) with a added 2port 10G broadcom nic (bnx2x driver) 2 x sata 525GB ssd , 2 x sata 256GB ssd -r8169 driver, nic working but fw error seen, dmesg: r8169 0000:02:00.0 eth2: unable to load firmware patch rtl_nic/rtl8168h-2.fw (-11), solved by manual copy of firmware tgz from loader ->no fw files after setup of loader in dsm system /lib/firmware (just a small bug? but will effect lot of other things like intel qsv probleme too) -bnx2x, nic not working, dmesg: bnx2x: [bnx2x_init_firmware:13421(eth0)]Can't load firmware file bnx2x/bnx2x-e2-7.12.30.0.fw the default fw files from arpl (copied manually to /lib/firmware) di not fix that after copying my old 6.2.3 fw files (or whats in bnx2x in firmware repository on kernel.org) it works as expected, the firmware files in the firmware.tgz where 7.13 and thats not what the driver need, in theory it can be checked with modinfo (but is also possible to look near "vermagic" with a editor so see that information too) in general its not enough to just copy the latest firmware files from kernel.org as it depends on the driver and drives from "older" kernels like 4.x need older firmware files then kernel 5.x drivers, there is no fixed rule, it needs to be checked or just all firmware files for that hardware to make sure it will work -tehuti 10G nic (just used shortly as the 10G braodcom did not work) has no driver, on 6.2.3 it was ok with the original syno driver from 918+ tn40xx.ko, but 2nd tehuti card i own i know has a different phy and did need a better/newer driver to work so it needs a better driver in general for all tehuti based cards to work (had that in 6.2.3 extra.lzma and it was mostly about getting exotic firmware files from oem for different phy's as oem's usually only pack the one firmware they need, there was no universal driver as seen from realtek or intel) -I kind of miss atlantic.ko (lots of cheap 10G cards with that one) and aqc111.ko (https://github.com/bb-qq/aqc111), both where asked for 6.2.3 extra drivers -default mod for synoinfo.conf only works with one nic (maxlanport=1), it needs manuall tweaking that is not for beginners, it should detect all nic's and set synionfo.conf accordingly or make it 4 as fixed setting - it might also need more when it comes to mac adresses (netif_num=1 as default needs to be set to 2 or more and mac2, mac3, ...) - atm its problematic to have more then one nic -defaut config only shows 2 disks in gui (even if 6 ports are detected on loader setup),more disks can be used for raid but cat /proc/mdstat shows only two drives are used (?,2of2) for the system/swap (two pairs of disks in exaple as SHR1) for a system with shr1/raid1 that might be ok but usually it should be all disks that hold dsm system/swap [note: the "raidF1" option the kernel offers, that was not availible on 918+ 6.2.3, thats one reason more to user dva1622) Personalities : [raid1] [raid6] [raid5] [raid4] [raidF1] md3 : active raid1 sata2p6[1] sata1p6[0] 268605760 blocks super 1.2 [2/2] [UU] md2 : active raid5 sata4p5[3] sata3p5[2] sata2p5[1] sata1p5[0] 700414848 blocks super 1.2 level 5, 64k chunk, algorithm 2 [4/4] [UUUU] md1 : active raid1 sata4p2[2](S) sata3p2[3](S) sata2p2[1] sata1p2[0] 2097088 blocks [2/2] [UU] md0 : active raid1 sata4p1[2](S) sata3p1[3](S) sata2p1[1] sata1p1[0] 8388544 blocks [2/2] [UU] test of possible disk fails tested with only disk 3+4 present and it did not boot (8GB + 2GB partitions are present on disk 3+4 but as mdstat indicates are not used) test with 1+2 booted as expected but had the raid/volume1 shown as "crashed" (shr1 raid not mounted/used), after adding the two missing disks it went back to normal boot with 2+4 looks messy as it now shows the 2nd disk as disk1 and 4th disk as disk2 (but only as detected), reattaching the two drives did not return the system to normal and shoed disk1 as crashed its not unexpected as the system/swap raid1 of disk1 was offline and as the shr1 is composed of a raid1 and raid5 (md2 and md3) the raid1 was mounted and with just one disk present in the boot before and now fails because of this (2nd disk has older data), the raid5 is ok as it was not mounted/used in the boot before as two disks where missing cat /proc/mdstat Personalities : [raid1] [raid6] [raid5] [raid4] [raidF1] md2 : active raid5 sata1p5[0] sata4p5[3] sata3p5[2] sata2p5[1] 700414848 blocks super 1.2 level 5, 64k chunk, algorithm 2 [4/4] [UUUU] md3 : active raid1 sata2p6[1] 268605760 blocks super 1.2 [2/1] [_U] md1 : active raid1 sata4p2[0] sata3p2[2](S) sata2p2[1] 2097088 blocks [2/2] [UU] md0 : active raid1 sata4p1[0] sata3p1[2](S) sata2p1[1] 8388544 blocks [2/2] [UU] the messy part is that its not possible to repair, when using the repair option it tells you to use a new disks (i guess because of the raid5 partition still in use and working) I deactivated the drive in gui to remove it from all raid sets but there seemed not to be no option to activate it again or make it available to use it with the pool/volume, a reboot fixed that, repair now worked with the disk and raid/volume got back to normal to "break" the still fine working raid5 was not so good but its still easy to handle as its not needed to use the console (and you had the chance to backup data before doing it) as my plan is to use a clean raid5 (all disks same size) i will not run in that kind of problem with my final system but its not intuitive to use as it need some knowledge about the internal workings when having problems and needing to find a way to fix it

versuch mal den 2. nic zu entfernen und mit nur einer karte, kann sein das es da probleme gibt ich habe auch ein wenig mit der beta2 herumgespielt (dva1622) und da gibt es kleinere probleme die man manuell zwar umgehen kann aber dazu muss man erst mal rausfinden was warum nicht geht (wobei ich nur mit der dva1622 probiert habe) versuch doch mal die letzte 1.0 version https://github.com/fbelavenuto/arpl/releases/tag/v1.0-beta13 ansonsten wäre arc auch eine option https://github.com/AuxXxilium/arc edit: ob deine 10G karte gehn würde wäre ohnhin nicht sicher (in arpl) gibt es weder in geminilake noch in apollolake eine atlantic.ko

there seem to some little changes in DSM 7.1 (tested with dva1622 and arpl 1.1 beta2) its not /dev/sda, /dev/sdb, ... anymore its now /dev/sata1, /dev/sata2 and partitons are p1, p2, ... a cat /proc/mdstat from a 2 disk system without a volume looks like this (dont mind that its not starting with sata1, its from a dva1622 test and the system only goes to two disks as its originally a 2 disk unit) md1 : active raid1 sata4p2[0] sata3p2[2](S) sata2p2[1] 2097088 blocks [2/2] [UU] md0 : active raid1 sata4p1[0] sata3p1[2](S) sata2p1[1] 8388544 blocks [2/2] [UU] so the above example still works with /dev/sataY synostgpool --create -t single -l raid5 /dev/sata1 /dev/sata2 /dev/sata3 /dev/sata4 /dev/sata5 this will create a raid5 volume and its creation will instantly be shown in the storage manager it will look like this (this example uses only disk2 to disk5, 1st disk was different size and is not part of the raid5) md2 : active raid5 sata5p3[3] sata4p3[2] sata3p3[1] sata2p3[0] 46845465600 blocks super 1.2 level 5, 64k chunk, algorithm 2 [4/4] [UUUU] [>....................] resync = 2.9% (463234168/15615155200) finish=1055.4min speed=239258K/sec md1 : active raid1 sata2p2[2](S) sata1p2[0] sata5p2[3](S) sata4p2[4](S) sata3p2[1] 2097088 blocks [2/2] [UU] md0 : active raid1 sata2p1[2](S) sata1p1[0] sata5p1[3](S) sata4p1[4](S) sata3p1[1] 8388544 blocks [2/2] [UU] i think i also found a loophole in the actual GUI process (Storage Manager) allowing a raid5 creation (gui only show SHR for anything higher then RAID1, no raid5/6 option when creating something new) its possible to create a basic volume on one disk (no lvm overlay with that i guess) and after that extend the storage pool by choosing "change raid type", that way a raid5 option is presented - but there is a downside to this, it will take ages to finish as it will add disks one by one, so it will be convert the Basic to a raid1 (2 disks) and then to raid5 (3 disks) - i did only start the process to see if its working and then destroyed the thing (there is not regular way to stop the process in the gui), i did see the basic to be changed into a raid1 with two disks and i think when waiting (a few days, depends on disk size and speed) it will be raid 5 in the next step until all disks are added - maybe it would be better to test with some smaller disks on a hypervisor system that uses ssd's as base it might be a alternative for people not wanting to mess around on the console

no thats just the message from loading the driver, the one i'm looking for would be earlier in the log or if you use "lspci -vv" you would only need to look for a device of the Class 200 it would look similar to this (but as i wrote above the vendor ID (1st part of xxxx:yyyy) is supposedly 1d6a:.... ... 0000:04:00.0 Class 0200: Device 14e4:16a1 (rev 11) Subsystem: Device 1043:866e Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ ... Kernel driver in use: bnx2x ... (this last with the used driver name will only be there if there was a driver loaded for that device, if there is no driver then you would still see al the information about the device's vendor and product id as this is the part the driver would identify the hardware with and only loaf if it find a matching id)

its kernel is two years old, a little borderline when its supposed to be "recent" but it should at least be able to list the pci devices even if there is no matching driver how about this: https://www.system-rescue.org/Download/ yes, its more comfy if use ssh/putty, you can just copy an paste from a windows to the browser (forum) but you can start a consol from the gui local, there should be enough things there to copy stuff to a file and save that onto a usb flash drive "lspci -vv" should deliver all whats needed about the devices (but things from the log with dmesg should also deliver informations

could you boot any recent live linux and have a dmesg from that, i cant see any pci id's from the last one i'd like to seen some pci vendor and device id's (and maybe sub id's) to make sure what device it really is also a lspci should list any device and its id's so try that too the board/chipset is form sandybrige so its pretty old and i guess that would be ppcie 2,0 and that should work with "newer" cards/chips that are made for pcie 3.0 or 4.0 with a "complete" dmesg you usually see at first a list of the pci devices like xxxx:yyyy and later on messages about the driver, the thing i'm looking for a the "raw" pci id's (and maybe sub id's) to identify the hardware of that card

they already are at dedicated hardware and have build in limits into the kernels they release for models the thing they could do would be to rely on TPM's and secure boot with there own certs in the future but afaik we have not seen anything like that and they would still need to support "old" hardware they sold for 3-5 years, so i dont think we will seen drastic changes in a short time frame that would lock us out for now they just officially get rid of stuff they already not supporting anymore, anyone with a original hardware should at least use 6.2.4 or above if they want security updates PS: there are also alternatives like open media vault anyone can switch to on the fly by just booting omv from usb or a disk, the (software) raid and file system will be recognized and it will be usable nearly ootb (volume names might need some tweaking to mount afair, i did a thing here about that and its still my personal fall back i have around as a omv5 boot stick), the one exception i know about is raid F1 for ssd's as its synology specific but i guess very few will use that as its only available in business units and for all flash configurations

no, that should not make a difference fo a added nic you can try a different pcie slot and you can also try to boot a live linux from usb to look for the pci device id'd with "lspci" and "lspci -vv" or "lspci -vv |grep 1d6a:" you should see a device with "1d6a:..." for the asus c100c as the chip on it is a aquantia AQC107 and at least the vendor should match, even if they have used some newer chip like the AQC113 (i'd expect them to rename the product when using something so different as the AQC113 can do pcie 4.0)

from the full log there is no pci device "1d6a:07b1" anymore as before, and so there is no driver loading i dont see a pci device message that looks like a 10G nic

also halten wir mal fest tcrp 0.9.4.0 sollte das problem fixen https://github.com/pocopico/tinycore-redpill/releases/tag/v0.9.4.0