urundai

checked the mpt2sas and mpt3sas. In the json, looks like the version numbers are incorrect for DS3615xs (14222 points 25556 like "ds3615xs_25556": "https://raw.githubusercontent.com/pocopico/rp-ext/master/mpt2sas/releases/ds3615xs_41222.json"). Is this intentional or a typo?

I was able to find the instance using Synology Assistant app on my machine. Thank you @vbap once again. I was really recompiling like crazy, not finding anything the log file.

Thank you @vbap. Very much appreciated. I tried that and it's not found with find.synology.com. But, I do see that the IP address has been assigned. Interestingly, find.synology.com is not finding my other synology box either. So, need to do some local troubleshooting as to what's going on. Maybe pihole is black holing it. I will some more digging and will post an update. Thank you for the help,

I am sure I am doing something wrong. I successfully compiled the img for DS3515xs using the toolkit V11 and Debian (running on vmware on my mac). I then converted it to vmdk using V2V converter. I created a new VM in my ESXI, set the network card to E1000e, set the correct MAC address. When I start it up, I see the message to pick USB or SATA. Once I select SATA, it stops at 'Booting Kernel' message. Nothing happens and I don't see any obvious error message in the log (attached). I used the instructions from this post: Building Redpill image. Did any of you run into the same problem? Any pointers on what I might be doing wrong? log.txt

Outcome of the update: FAILED - DSM version prior update: DSM 6.2.1-23824 - Loader version and model: JUN'S LOADER v1.03b - DS3617xs - Using custom extra.lzma: NO - Installation type: BAREMETAL - MFU X79 Board with Intel Xeon 2650 - Additionnal comment: No Network. System has Realtek onboard NIC and HP NC364T PCIe 4 port. Onboard was never recognized even before but after update, the 4 port PCIe stopped working (even with onboard controller disabled). Had to migrate to 1.03b DS3615 which is working great.

I had the same problem but have used Jun's 3615XS loader and everything is working fine so far (no 'Page not found' error that happened in my 3617xs install and system has been up 24 hours+).

some DSM models has extra checks after running around a few hours, if this check is not passed, a few .so will be deliberately corrupted, the code to deal with this is not enabled for the model if you see "device not supported" in the kernel log Yes, I do see 'Device Not Supported' in the kern.log. I didn't have this issue with 6.02. So, something has changed in the 6.1 DSM code that enforces stricter checks? Is there something I can do to get around this or should I revert back to 6.02?

I got the dreaded 'Sorry, the page you are looking for is not found' after 6.1 upgrade. Digging around, looks like synoscgi upstart job fails to run and it's due to libsynoshare.so.6 (error while loading shared libraries: /lib/libsynoshare.so.6: invalid ELF header). Few other commands I tried (synoupgrade) failed for the same reason. Typically, ELF header issues are due to mixing 32 and 64 bit dependencies (between executable and shared object libs). Hopefully, one of you with more experience with syno stuff can think of workarounds or things that can be tried.