flyride

So you are RDM'ing your RAID array? I don't know how you can do that and use it for ESXi storage at the same time. Best results are when DSM sees the drives as natively as possible. This is harder to do when you put the restrictions on your system as you have. If you can't come up with another datastore for ESXi, you should consider running individual RAID 0 for each disk and then assign some of them to ESXi and some of them via RDM to a vSATA controller for DSM.

When you say "not verify" can you be specific as to what the error message is? Are you familiar with FixSynoboot?

Well your drives are CMR, so that isn't the problem (DT02 drives are SMR). LSI is not the sweet spot anymore for XPE (AHCI controllers are better supported). You did not mention which DSM version you were running, just the platform. I have two suggestions if you are feeling adventurous: Try and run the LSI controller passthrough and see if you get any different results. Try DSM 6.1.7 and see if you get any better throughput.

Specifics on your hardware would be helpful. What drives, exactly? (Make and model numbers) What motherboard?

x64 is required https://xpenology.com/forum/topic/13333-tutorialreference-6x-loaders-and-platforms/ x86 are very old - we are talking the original Intel Core chip circa 2003 - sure you are trying to use one of those?

I previously did a scripted NFS mount on ESXi. I tried all the above except didn't bother with a firewall exception and was able to mount a test NFS datastore using either V3 and V4 protocols.

I have configured an NFS mount accessed by ESXi on XPE DSM in the past, and it works fine, but I haven't tried explicitly to use it as a datastore. What errors do you get?

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

IMHO you would have to scrap the 1815 board and somehow interface the backplane to an existing multi-port eSATA controller? So you would also need a donor expansion unit. When I have taken apart lower-end Syno units, the backplane cable to the main board was not something I recognized. Probably more trouble than it's worth, especially with the existence of cases like U-NAS 810a etc.

If fred is your account, and pw is your password, the string looks like this: /webapi/auth.cgi?api=SYNO.API.Auth&method=Login&version=1&account=fred&passwd=pw That is not what you put in the post prior.

This doesn't make a lot of sense, since it shouldn't work without all the boot options that are invoked when one of the menu options is chosen. You haven't described the "fiddling" which was required to complete your install. Maybe you can share more details about the exact devices you have, installation resources followed, and any deviations required to make things work.

NAS performance is not significantly affected for baremetal versus virtualized. You should determine your installation platform for other factors that are important to you. https://xpenology.com/forum/topic/13333-tutorialreference-6x-loaders-and-platforms/ When you have figured out how and what to install, use one of these links to guide you: https://xpenology.com/forum/topic/7973-tutorial-installmigrate-dsm-52-to-61x-juns-loader/ https://xpenology.com/forum/topic/13061-tutorial-install-dsm-62-on-esxi-67/

Make a duplicate of the entire boot environment so you don't have to install from scratch. That only has to be done after a major upgrade of ESXI. Then periodically copy the VMX file and the original loader to your local machine? There really isn't very much to back up on ESXi.

If you insist on the boot disk being #2 port on a controller with other drives, I do not see a solution to the problem. Best practice dictates that the boot loader has its own dedicated controller (which is what all the tutorials indicate), and is why you have your issue. I'm still not clear on exactly why you are using the boot configuration that you are. Are you running virtualized? If so, just add a virtual SATA controller and shift the other three controllers over one slot. If you are running baremetal, what is stopping you from just using a USB flash drive as recommended? That would solve your problem.

Personally, I do most all the things listed above or their equivalent on my systems. I am sure others have similar feedback. Plex: Definitely works. I use Docker Plex (superior to the SPK setup in my opinion). Plex functionality is not bound to Synology in any way. Offsite backup & versioning: via Snapshots (versioning) and backup replication (cross-site backup). I use point-to-point VPN via firewall to make it transparent to DSM. "Get share link": I assume this is the sharing functionality in File Station. Don't use that, but I see no reason for that not to work normally Download Station+VPN: Lots of evidence those both work fine. I now use Wireshark instead of OpenVPN. For downloads, Docker sabnzbdvpn and qbittorrentvpn. Active Backup: Works. There are posts on how to defeat the activation so you don't need a serial. For me, VEEAM Free is superior in most every way Access via DDNS: These are two different things. If you open a port, you have access. Synology DDNS client can be configured to work with a DDNS provider other than Synology. I use a Docker app. BTRFS/SHR/scrubbing/compression: Yes SMART: Works with ACPI-compliant SATA controllers and devices directly accessible to DSM. RAID controllers and virtualized disks are less compatible. I run a RAIDF1 array. SMART is mandatory for RAIDF1 because it has to interrogate the drive consumption to work. Bottom line, solutions to most of your challenges exist, if you can be a little bit flexible on implementation.

What is the dreaded blinking cursor? For a baremetal install, the first menu item IS the boot option you need.

The limits on using Synology cloud services are self-imposed (by the community) and enforced by Synology (through legitimate serial number verification). FWIW, HA services seem to be hit or miss. Fan and beep control do not work because they rely on Synology proprietary hardware. Drive hibernation is a bit finicky, and SMART is not functional with all possible hardware combinations. Does VMM not work, or does it just suck? XPEnology has the ability to run as a VM under ESXi or other hypervisor, so reliance on VMM is less of an issue for those who need accompanying VMs. Those are a few that come to mind, but I'm sure I'm missing some significant items. It might be more efficient if you indicated what things you were interested in. Nobody uses or tests all the functionality from the Synology ecosystem.

As I continue to parse your issue report, I think you are confusing disk "suppression" with disks actually being present. You said you set your loader to position 0:1 but if it is ESXi, it enumerates starting with position 0:0. SataPortMap=1 says there is only one device attached to the first controller, but your drive is in the second position so it is never mapped to a /dev/sdx device. SataPortMap=2 says there are two devices attached to the first controller, so the disk gets mapped to a device and then FixSynoBoot can work. You think you are suppressing, but you are not. The way suppression works is that DiskIdxMap must map the loader device beyond the assignable range, as defined by maxdisks (12 for DS36xx, 16 for DS918+) I suggest that the solution may be this: Move your loader disk to position 0:0 SataPortMap=143 DiskIdxMap=100003 (if you are using DS918+) DiskIdxMap=0C0003 (if you are using DS3615xs/DS3617xs)

https://xpenology.com/forum/topic/13333-tutorialreference-6x-loaders-and-platforms/

Please run the following commands and post the output. # cat /proc/cmdline (NOTE: you can redact or obfuscate your serial number if you wish) # synodisk --enum # tail -n+3 /proc/partitions | grep "51200"

First, congratulations on a successful upgrade. Regarding your packages and settings comment: It's a bit hard to follow the sequence of drive migration from prod to test and back to prod. But in the end, it sounds like you added a drive with no volume on it, updated the System Partition (which is an obfuscation of the Linux OS partition and the swap partition), then used that for test, and then back to the prod hardware WITHOUT the other drives. When you boot DSM with no volume, packages are invalidated, because they require the volume in order to function. Normally a migration install preserves virtually everything about the previous system. I believe that the approach to omit your volume was the cause of your config loss.

Broadwell is a refresh of Haswell so you should be able to run DS918+. You MUST run DS918+ if you want to enable hardware transcoding.

Migration install keeps everything. But it would not hurt to also have a backup from Control Panel (css file) just in case it all goes sideways. Docker and Plex are pretty easy to restore if necessary. If you are not using Plex in Docker I strongly suggest you switch over from the SPK.

Neat little chip then. Registered DIMMs only required with older motherboards or extremely large DIMMs that your proposed motherboard does not support. UDIMMs cost less (at least new they do) and were created because modern chipset memory controllers could handle the buffering requirements. I think you will be pretty happy with that hardware.

The procedure to move from major version to major version requires the replacement of the loader and a reinstallation. For example, 6.0, 6.1 and 6.2 all use use different loaders. FMI: https://xpenology.com/forum/topic/13333-tutorialreference-6x-loaders-and-platforms/ Minor updates (6.1.x to 6.1.y, or 6.2.x to 6.2.y) usually work fine via the UI update. Automatic updates are never recommended: https://xpenology.com/forum/topic/9394-installation-faq/?do=findComment&comment=81100 Also, you should see how the update you plan to apply is working for others before you attempt it yourself. Better yet, have a test environment to make sure it works first. https://xpenology.com/forum/forum/78-dsm-updates-reporting/ As far as DSM 7 is concerned, nobody knows yet. It is unlikely to work without a new loader release. DSM source code will probably need to be released before a loader can be created. So you need to plan NOT to update to DSM 7 for some time, maybe never if using XPEnology.