flyride

Bad news, if you did not specify a 6.1.x .PAT file during the migration, you downloaded and installed 6.2 now that it is released across all platforms. This post is consistent with how I would attempt to recover it.

It's for the 1.02 loader regardless of platform.

Platform: ASRock J4105-ITX Loader: Jun's v1.02b DS916+ DSM: DSM 6.1.7-15284 LAN: Realtek RTL8111H Gigabit SATA3: 2x Intel via chipset, 2x ASMedia ASM1061 (hot plugging supported on all ports) Comments: This is the Gemini Lake update of the ITX motherboard ASRock has been selling for years, and it runs XPEnology baremetal without special configs or drivers. Pros: 4x 2.4 Ghz cores and up to 32GB RAM (ignore the manual's 8GB limit). Hardware-accelerated video (Intel UHD 600) and AES-NI hardware encryption. On-board WiFi option. Only con is lack of expansion - only one PCI 2.0x1 slot. This board is basically a DS918+ with double the L2 cache and higher clocks. Can't go wrong for $85 USD if you want to build a simple 4-bay Plex-able XPEnology NAS.

Just built a machine with the latest Gemini Lake rev of this board, J4105-ITX. It works perfectly baremetal, no drivers required. A pretty nice XPEnology setup for a 4-bay NAS, 4x 2.5Ghz cores and 4 SATA ports for $85 USD. Expandable to 32GB RAM (ignore the false 8GB limit in the manual).

I'm using a Kaby Lake Xeon on C236 chipset, and it works fine on both baremetal and with ESXi. Given that CFL is basically Kaby Lake and Z370 is basically Z270, I can't imagine you would have trouble.

It would have to be a SN/MAC from a DS3615XS+ and not have been used by anyone else prior. Also, see this: https://xpenology.com/forum/topic/9392-general-faq/?do=findComment&comment=82390

I'd wait at least until the loader is released official, since there are other code bases that support 6.2, there should be a good demand for the trusty DS3615XS, although it has the 3.10 Linux kernel, not the 4.4 of DS918+.

Yes, you should be able to migrate. Have a backup. As a newbie to XPEnology installs, it would be useful for you to get another hard drive and do some test installation/migrations before you move forward on your production disks.

Verify you have a 6th gen Intel processor or later: Skylake, Kaby Lake, Coffee Lake, Apollo Lake, Denverton, Gemini Lake. The current alpha loader is built on an Apollo Lake binary, so it may have some processor-specific instructions.

Cannot install on a drive on a secondary controller, but you probably knew that. Also tried subbing a secondary/alternate controller on a running system, which also did not work. The alpha tutorial indicates this, but the synoboot drive is not hidden (and you knew that too). At some point if there are things you'd like the community to test, please post. Bravo on a great alpha effort.

Installed fine on ESXi 6.5 on a Kaby Lake Xeon. Tried setting up a VMWare NVMe virtual disk, but DSM does not recognize it for SSD Cache. It can see it using the command line tools, however. It may be an issue with an enforced approved equipment compatibility list. Will poke around a bit and report back.

Rereading the later posts - you did identify your drive as a mSATA drive. In any case, you should be able to use that (or any) drive as an SSD cache with ESXi by virtualizing the storage or physical RDM.

You did not say what type of Kingston drive you were trying to use. If your drives are NVMe, they won't work on a baremetal installation. None of the currently supported XPEnology hardware options (DS3615xs, DS3617xs, DS916+) can support a NVMe drive. If you have a M.2 SATA drive, I'm pretty sure it would work. M2D17 only provides M.2 SATA interfaces, so it will probably also work (but don't try to install NVMe devices into it). Back to NVMe: I was able to make NVMe drives work under ESXi as physical RDM or virtualized (both options work). See https://xpenology.com/forum/topic/12391-nvme-optimization-baremetal-to-esxi-report/?do=findComment&comment=88690 If you install this way, you should be able to use an NVMe drive as a SSD cache. In my opinion, SSD cache is not worth the effort, expense or additional risk.

I assume you mean NVMe and not mSATA. In any case, I've been able to get NVMe drives to work (in my case, U.2 interfaced drives, but they are the same to the system as M.2 NVMe) using ESXi and configuring the NVMe drives as physical RDM. I'm not aware of anyone getting NVMe to work in any other way as of yet. See https://xpenology.com/forum/topic/12391-nvme-optimization-baremetal-to-esxi-report/?do=findComment&comment=88690

Thank you, and congratulations. Is there a plan to update the reference hardware platform? I note that a new 6.2 feature (NFS 4.1 multipathing) unrelated to the processor instruction set is only available for DSx16 systems and newer.

- Outcome of the update: SUCCESSFUL - DSM version prior update: 6.1.6-15266 - Loader version and model: Jun's loader v1.02b - DS3615xs - Using custom extra.lzma: NO - Installation type: ESXi 6.5.0 U1-7388607 - Additional comments: REBOOT REQUIRED / No issues with test VM upgrade or production VM with physical RDM and controller pass-through.

I have no reason not to believe you yet the behavior you describe is consistent with it trying to boot from a Syno disk, which obviously won't work. sbv3000 has the next steps advice I would consider for myself, if I were in your shoes. However, how long are you waiting for the SATA detection to complete before giving up? Try waiting a LONG time to see if it finally times out. Just curious, what version of DSM was running on the DS410? As a last resort, you could take a spare drive, configure XPEnology, then once it is properly configured and booted, hot connect your DS410 drives. I'll have to look them up, but there are a few Syno CLI "magic commands" that will allow you to import your DS410 volume instead of migrating. Then you could repair your system partition to update DSM on the old drives. sbv3000's advice about a backup is paramount if you were to attempt to go this direction. The disks are partitioned as Linux partitions but you won't be able to mount them in Windows without additional software. What does "unreadable" mean? You can verify that the drive is working by looking at the partition table, which can be done using Windows Disk Manager.

Fix your boot order to prefer the USB stick over SATA drives. Preferably you should just be disabling SATA boot options when running XPEnology.

Are you sure that applies to physical RDM (-z vs. -r)? You don't mount the drive as a datastore at all with that method. http://www.myvmwareblog.com/2013/01/14/quick-tip-how-to-create-an-rdm-mapping-file-via-the-cli/

If you present virtual disks to DSM, it does not know and treats like regular block storage. The latency question is a good one but DSM seems fairly tolerant of that. You'll just have to test it for yourself. That said, if you get pRDM to work, actual block storage commands are being presented to the physical media and it is essentially direct disk access with a translation for the controller only. If I were in your shoes and had a choice, I would configure the USB drives as pRDM. In my first response, I left you a link to my journey on ESXi, where I did what you are trying to do, but with NVMe. Initially RAID 1 BTRFS on two VMFS volumes, then converted those to physical RDM. Still RAID 1, still BTRFS, DSM seems happy. Again, if latency is a problem, I do not experience it and you might, but you will have to try and report back.

I don't think you can do it with a device passthrough, but you could set up ESXi to use the USB drives as datastores, then create virtual disks in the datastores, which will then be accessible by DSM under XPenology. Also, you may be able to map the USB drive storage with physical RDM, which is able to translate a NVMe drive as a SCSI device. It may work to translate the USB storage to SCSI as well (you'll still have to disable the USB arbitrator). See: http://www.virten.net/2015/10/usb-devices-as-vmfs-datastore-in-vsphere-esxi-6-0/ and

You can either RDM passthrough your drives (where ESXi still has control of the chipset SATA controller) - see: https://kb.vmware.com/s/article/1017530 Or, you can pass through the chipset SATA controller to the VM (the drives then go with it). You may have to add it to ESXi's device map. Read: https://forums.freenas.org/index.php?threads/configure-esxi-to-pass-through-the-x10sl7-f-motherboard-sata-controller.51843/ Also of note, with an 8-core processor, you will need to disable hyperthreading in your BIOS as DSM can only handle 8 CPU threads total.

Look at the Synology CPU lineup here: What kind of CPU does my NAS have You can get a sense of how XPEnology may perform based on the specs of the product closest to your system. 10Gbe makes a significant difference in performance, which is not an option for all but the most recent Synology products, but almost always an option for an XPEnology system.

Just read the messages in this exact thread you are replying to, and you will see that 6.2 beta won't work with the current loader.

What exactly are you trying to reset? You can reset to default settings from Control Panel within DSM, with no risk to data. [Edited by Polanskiman] Also this will work: sudo /usr/syno/sbin/synodsdefault --reset-config Options: Synology DS Default Reset Util. Usage: synodsdefault --reset-config Reset DSM configs. --reinstall Reset to reinstall DSM. --factory-default Reset to brand new DSM. Include remove all data volumes. --help Show this help.