sbv3000

spec says 4 sata ports so should work, but check the settings in bios as before also in the tcrp loader terminal, run the satamap option to find your controllers and drives (but dont update user_config.json) report back results you might try a 'non-device tree' build, DS3615/17/22, could be the 1621 devicetree isnt working right. As an aside, I'd disable any onboard peripherals like audio, serial, parallel, not needed and they take system resources.

What is your mobo hardware setup? -Its good to include that in any posts to help members help you diagnose problems Meantime, Maybe the sata ports 3/4 are disabled in bios? Not set to AHCI ? HDD power not connected properly? Faulty HDD Can you see all the disks in the BIOS?

https://github.com/pocopico/rp-ext/tree/main/aacraid add-on might work?

did you run the satamap option ?

there is a smart array extension in pocopico's library so this might work if manually added to the build? https://github.com/pocopico/rp-ext/tree/main/hpsa

Can you post a bit more info eg ? Some network info like where is your dynamic dns set, firewall ports etc. Any updates to your firewall that might have changed things, say 'resolving hostnames to local lan' How are you connecting to the cams, can you login to them via their ip addresses? Where are you backing up too? Another location, local lan device? Given that your cams are not visible I'd say its a firewall issue somewhere

from the error and rp-ext location i dont think the 3622 module is listed, maybe try a build that is? https://github.com/pocopico/rp-ext/tree/main/qla2xxx/releases

should be standard intel ahci. try lspci for devices from the tcrp terminal, also check bios sata settings are ahci, and post the results of the satamap command

I got one of these from Aliexpress, its a 16 port using 4 independent asmedia 1064 chips standard ahci driver. https://www.aliexpress.com/item/3256802942788966.html?gatewayAdapt=4itemAdapt Tested with TCRP builds 3615/17/22, with satamap 4444 (overriding the discovered/bad ports) Works with 16 drives with onboard ports disabled. With correct combination of satamap/diskidx I had it working with 4 on board and 12. Its not the fastest but good for a backup 'jbod' device

try the tutorial here https://xpenology.com/forum/topic/62221-tutorial-installmigrate-to-dsm-7x-with-tinycore-redpill-tcrp-loader/ and post some results from your build process

I would try a basic hardware install with DS3622; remove the asmedia card, disable the 10gb nic, use a single hdd. run ifconfig in the terminal and get the mac addresses of the intel nics, use the 'realmac' option for the serialgen. note the 'satamap' results for the disk controllers. If that works then add the m2, rerun satamap and rebuild. You will probably need to add the 10gb nic driver manually from rp-ext. you will need to edit/add the netif_num and mac addresses for 3 nics. check the user_config.json file to make sure your settings are 'stored' after the builds. I would not install the asmedia card until you have drives attached.

try boot from UEFI partition

i've an old asus atom 330 mobo 4gb ram from 2010 running ds3615 dsm 7.1 with tcrp build. works ok. n270 single core 32 bit , but maybe try it ?

sata_sil isnt in the rp-ext library, but you could request it be added. https://github.com/pocopico/rp-ext the 3114 is quite old sata 1/2 speed and it might be easier to buy a 4 port standard ahci adapter eg https://www.amazon.nl/Syba-SI-PEX40064-PCI-EXPRESS-Controller-aansluiting/dp/B00AZ9T3OU/ref=sr_1_4?crid=VFK7BNQGYTUD&keywords=marvell%2B88se9215&qid=1661420342&sprefix=marvell%2Caps%2C77&sr=8-4&th=1

Hi All I've not seen this mentioned elsewhere, but how to change the 'netif_num' parameter? The default seems to be '1' in the tests I was doing with various builds. A little bit of testing and the answer is to edit user_config.json with the required settings in the format "netif_num" : "N", where N is your nic count, then add your additional mac addresses, rebuild. If someone else could verify?

Hi All I checked the forums for mention of these and there are a couple of archives from way back. I like to keep away from 'licence' issues with my XPE boxes but see a lot of people using Surveillance Station with hacks. There is a possible good alternative to SS that runs in Docker and seems to work well and no syno licence requirements. https://www.ispyconnect.com/download.aspx I didn't use the docker script, instead this docker guru has created a registry package doitandbedone/ispyagentdvr Once installed and running, check the container details/overview/port settings and find the local port forwarding to 8090, the the webpage is accessed from 'yournasip:localport'. The rest of the setup as per the ispyconnect documentation. Seems to work well with lots of options. There is a subscription option for remote access.

Just as a follow up to this I connected an old 137GB SAS drive to the controller and it shows up ok in Storage Manager and the demsg output is; [ 19.258492] drivers/scsi/mvsas/mv_sas.c 1079:phy 3 attach dev info is 80001 [ 19.258494] drivers/scsi/mvsas/mv_sas.c 1081:phy 3 attach sas addr is f90ad50e00c50050 [ 19.662485] scsi host4: mvsas [ 20.762159] drivers/scsi/mvsas/mv_sas.c 277:phy 3 byte dmaded. [ 20.762268] sas: phy-4:3 added to port-4:0, phy_mask:0x8 (5000c5000ed50af9) [ 20.762275] drivers/scsi/mvsas/mv_sas.c 1116:set wide port phy map 8 [ 20.812335] sas: DOING DISCOVERY on port 0, pid:29 [ 20.812341] sas: DONE DISCOVERY on port 0, pid:29, result:0 [ 20.818290] scsi 4:0:0:0: Direct-Access HP DG146BB976 HPDC PQ: 0 ANSI: 5 [ 20.822575] sd 4:0:0:0: [sde] 286749488 512-byte logical blocks: (147 GB/137 GiB) [ 20.824551] sd 4:0:0:0: [sde] Write Protect is off [ 20.824559] sd 4:0:0:0: [sde] Mode Sense: db 00 10 08 [ 20.826472] sd 4:0:0:0: [sde] Write cache: disabled, read cache: enabled, supports DPO and FUA [ 20.839796] sde: sde1 sde2 sde3 [ 20.846383] sd 4:0:0:0: [sde] Attached SCSI disk

Hi All I'm testing some hardware before updating my 'prod' systems J3455 itx board and Intel add on nic 1 drive attached to mobo onboard sata 1 DS918+ boot loader created/installed DSM6.2.3-25426 and U3 to the mobo drive - all working fine Replaced extra.lzma and extra2.lzma with @IG88's driver extension v.0.13.3 files to boot loader partition Added Supermicro Marvell 98SE6x sas controller with 2 (sata) drives attached Booting system the 2 drives are visible in the Marvell bios DSM Storage Manager only shows the 1 drive attached to the onboard sata Putty connection to the system and running various commands; lspci lists; class 0104: Device 11ab:6485 - The 98SE controller class 0000: Device 1b4b:9215 - The onboard Marvell 9215 controller dmesg output for the Marvell mvsas module; [ 26.873356] drivers/scsi/mvsas/mv_sas.c 1079:phy 0 attach dev info is 0 [ 26.873366] drivers/scsi/mvsas/mv_sas.c 1081:phy 0 attach sas addr is 0 [ 26.974352] drivers/scsi/mvsas/mv_sas.c 1079:phy 1 attach dev info is 0 [ 26.974357] drivers/scsi/mvsas/mv_sas.c 1081:phy 1 attach sas addr is 0 [ 27.075349] drivers/scsi/mvsas/mv_sas.c 1079:phy 2 attach dev info is 0 [ 27.075354] drivers/scsi/mvsas/mv_sas.c 1081:phy 2 attach sas addr is 0 [ 27.176346] drivers/scsi/mvsas/mv_sas.c 1079:phy 3 attach dev info is 0 [ 27.176351] drivers/scsi/mvsas/mv_sas.c 1081:phy 3 attach sas addr is 0 [ 27.277344] drivers/scsi/mvsas/mv_sas.c 1079:phy 4 attach dev info is 0 [ 27.277350] drivers/scsi/mvsas/mv_sas.c 1081:phy 4 attach sas addr is 0 [ 27.378341] drivers/scsi/mvsas/mv_sas.c 1079:phy 5 attach dev info is 0 [ 27.378346] drivers/scsi/mvsas/mv_sas.c 1081:phy 5 attach sas addr is 0 [ 27.579363] drivers/scsi/mvsas/mv_sas.c 1079:phy 6 attach dev info is 0 [ 27.579365] drivers/scsi/mvsas/mv_sas.c 1081:phy 6 attach sas addr is 6 [ 27.780359] drivers/scsi/mvsas/mv_sas.c 1079:phy 7 attach dev info is 0 [ 27.780361] drivers/scsi/mvsas/mv_sas.c 1081:phy 7 attach sas addr is 7 [ 27.780371] scsi host3: mvsas [ 27.784221] drivers/scsi/mvsas/mv_sas.c 277:phy 6 byte dmaded. [ 27.784227] drivers/scsi/mvsas/mv_sas.c 277:phy 7 byte dmaded. [ 27.784379] sas: phy-3:6 added to port-3:0, phy_mask:0x40 ( 600000000000000) [ 27.784428] sas: phy-3:7 added to port-3:1, phy_mask:0x80 ( 700000000000000) [ 27.784450] sas: DOING DISCOVERY on port 0, pid:29 [ 27.784452] sas: ATA device seen but CONFIG_SCSI_SAS_ATA=N so cannot attach [ 27.784453] sas: unhandled device 5 [ 27.784460] sas: DONE DISCOVERY on port 0, pid:29, result:-6 [ 27.784465] sas: DOING DISCOVERY on port 1, pid:29 [ 27.784466] sas: ATA device seen but CONFIG_SCSI_SAS_ATA=N so cannot attach [ 27.784467] sas: unhandled device 5 [ 27.784471] sas: DONE DISCOVERY on port 1, pid:29, result:-6 Seems that the mvsas module is loading ok and finding the drives, but not connecting due to the CONFIG_SCSI_SAS_ATA=N status In an old forum thread from 2018 (https://xpenology.com/forum/topic/12679-progress-of-62-loader/page/13/) @IG88 had recompiled the mvsas and libsas with CONFIG_SCSI_SAS_ATA=Y which seemed to resolve the issue Does anyone have this Marvell or mvsas based card working with 6.2.3 and the v.0.13.3 driver extensions? If IG88 sees this - does your 0.13.3 extension include the recompiled CONFIG...=Y modules Have I missed something with my setup ?

This website seems to suggest the 6tb drives are not compatible with the d70 http://findhard.ru/en/checkcompatibility/part?partType=Drives&id=17597&model=seagate-6-tb-st6000nm0034

I've only used HA mode on real Syno kit so no direct experience of this with XPE, but I'd look at the following; Serial numbers and MAC addresses being 'genuine' (bearing in mind that the XPE community discourages using genuine numbers on XPE) S/N and MACs aside, Try a test with and XPE 'Master' and real Syno 'slave' to see if it works Then vice versa. Might help eliminate if there is a hardware issue Check the system logs in either case Depending on your hypervisor lab setup, are your VM's HA NICs on the same physical NIC or separate? There might be an underlying issue with that so try different NICs I think the best way to prove this would be physical kit rather than VMs, even older hardware if you have spare kit, before you buy new. Also try the 3615 boot loader and lower boot versions. About moving between real syno and XPE, provided you have fully tested your XPE hardware then it should work, however if your real DSM version is higher than your XPE boot build you might need to 'migrate' and reinstall DSM .pat file and then update to the version you have. If its a major build difference you might need to force a downgrade by editing various config files or creating a clean install HDD and adding your array drives afterwards and repairing the system partitions. All this presumes you have good, verified data backups of course! Which, for me prompts another question. If you are currently running an HA real Syno environment, I'm guessing this is business and critical environment, so should you be considering using a 'hacked' O/S like XPE that is community supported and could expire at any time, should for example, Synology lock down the O/S.

You may have fixed this but my comment about 3.3v is that 'some' drives have strange behaviour if powered with the 3.3v supply as well as the usual 5v and 12v. so try sata power connectors without it (the orange lead), alternatively make sure all drives either have it or not, ie not a mix

I would try; disable all onboard devices that you are not using/needed eg audio, usb3. manually setting memory speed to match clock rather than 'auto' Enable disk activity logging and check the system logs following a crash to see if there is a log centre event near when it happens. If you are running any SNMP monitoring, you could use the syno mib to check lots of system resources in real time and see if something is triggering the reboot. One last thought, recreate your usb boot loader on a new drive

My odd thoughts are; Mix of sata 3 and sata 2 channels, maybe a cache/speed issue, disable or enable cache in storage manager? Power supply 3.3v connectors, or not, all drives powered with or without these? Check if drives/PSU are in conflict with 3.3v options, hibernation etc

a silly idea perhaps, but could you remove your raid disks, boot with no disks and see if the network is ok? not sure of the boot process but imagine that with no disks the unit boots with dom based drivers for 'basic' connectivity, but once DSM is installed it uses drivers from the .pat file. if the DSM driver is 'corrupt' then fails to load. Above could also identify if network hardware has failed? Next step would be to install DSM to a spare/new HDD, check that works, if so you just need to 'repair' on the raid drives

just search for 'sataportmap', there will be lots of posts, here is one example grub set sata_args= 'SataPortMap=6' # sata controller, values: 6 - 1 controller on 6 ports; 22-2 controllers on 2 ports; 42-2 controllers, the first on 4 ports, the second on 2, etc. in your case the sataportmap could be 426, 246 66 depending on how the onboard and add on controllers are 'seen' in bus order but it look like the xpe/dsm will only 'see' 4 ports due to the multiplier no matter what you do