flyride

Ok, your arrays seem healthy. It's strange that you have a filesystem (volume) crash without any array corruption. What exactly was happening when the volume crashed? When you say it has "populated with an empty volume" you mean that it shows 0 bytes? I suspect it just isn't mounting it. Run a vgdisplay and post the results please.

You want to troubleshoot your crash from the lowest (atomic) level progressing to the highest level. You are starting at the highest level (the filesystem) which is the wrong end of the problem. Generally you don't want to force things as they can render your system unrecoverable. I have no idea if your data can be recovered at this point but you can troubleshoot until you run into something that can't be resolved. Start by posting screen captures of Storage Manager, both the HDD/SDD screen and the RAID Group screen. Are all your drives present and functional? Then run a cat /proc/mdstat and post the output.

Ooo, I wonder if Syno coded their utilities specifically to a particular PCIe address for DS918? Can anyone with a real DS918+ and a NVMe card run a lspci on their NVMe card? EDIT: there are a number of commands I'd like to run and see the output on an actual DS918 with an installed NVMe SSD. If you own one of these and want to help, please make yourself known...

It would have to be a standalone or on another ESXi host, or you could not get to the XPE backup if ESXi was down.

Get the vendor and device ID from the onboard NIC and you may find that it is supported.

There is nothing magical about the NC360T. The only thing you need to do is to make sure that the device you are trying to buy is supported by the driver in the image you want to run. Refer to this Intel list: https://www.intel.com/content/www/us/en/support/articles/000005612/network-and-i-o/ethernet-products.html The PRO 1000/CT is device ID 10D3. Now look here (for DS3615) or here (for DS918) and look up the device ID in the appropriate spreadsheet. The 10D3 card is supported by both images, so you should be fine with that card.

That would work, or you can just use the datastore browser in the vSphere or web consoles to download the files individually.

It depends a little bit on your installation. In my particular case, since all the NAS storage is passthrough or RDM, there really is no unique XPEnology data in datastores other than the vmx file and the RDM pointers. So I just copy those small files up to my PC for safekeeping. For VMWare itself, it's pretty typical to make a clone of the USB boot device when the system is down, as it doesn't change, unless you upgrade or patch VMWare. I'm running a couple of Linux VM's and I'm using VEEAM for Linux to back those up to XPEnology.

NIC on that board is Atheros, which is not very frequently used, and 100Mbps besides. There is some Atheros support on the 3615 image but I doubt it is comprehensive. I think your simple solution will be to buy an Intel PCIe NIC. There are some PCIe x1 flavors and your board has one PCIe x16 slot too. Should cost you no more than $15-$20.

I believe that your statement is correct.

Again, start with loader 1.02b for DS3615, and download a DSM PAT file for version 6.1.7 DS3615xs+ NOT DS3617 NOT 6.2.x When it installs, DON'T let it upgrade to 6.2.x. This is a version that is almost guaranteed to work on your hardware, and once you figure out what's going on you can experiment with other loaders and DSM versions.

Syndicating an NVMe device via RDM will cause it to appear as the type supported by the virtual controller to which it is attached. In the case of my examples, DSM sees the NVMe drives as SAS. They could as easily by SCSI or SATA, all to which DSM provides direct support as disk devices. So there will be nothing output from the nvme command structure.

MDRAID writes a superblock on each array member so it can still work if the drives are encountered out of order. That said, it's possible to defeat it if enough bad things happen to the array (missing members, etc).

Did this post not explain the situation for you? DS918+ has no slot for 10Gbe card so the Synology support page would not apply.

Guides: Choosing a loader and DSM / DS3615 native drivers / DS918 native drivers

Do you have a valid domain that you used for the Let's Encrypt CSR? It cannot be a made-up one, it has to be resolvable to the IP that services your host.

Looking at the spreadsheets linked here and here, you can see the following: On DS918, v6.2.1 image, the ixgbe (linux device driver that supports X540 NIC family) driver is version 4-2-1-k, which happens to be the default driver in the 4.4 kernel tree On DS3615 image v6.1.7, the ixgbe driver is version 4.4.6, which is a custom build by Synology On DS3615 image v6.2.1, the ixgbe driver is a newer custom build at version 5.1.3 You may have a newer X540 card that is not supported by the older driver in the DS918 image. You should be able to prove it by going into Windows and getting the PCI device IDs for your cards and trying to match to the list of device ID's in the spreadsheets. Synology does not care about updating the ixgbe driver on DS918 because there is no way to install a 10Gbe card in their hardware. If someone builds a functioning, updated ixgbe driver in extra.lzma for DS918, that may work, otherwise you will need to stay on a DS3615 image to support your cards. I have never found that the grub MAC setting had any effect on whether a card was recognized by its driver. AFAIK the point is to enable use of a Synology MAC for a service that requires one, and perhaps secondarily to avoid MAC duplication with multiple XPEnology installations on the same LAN. Still not 100% sure what aspect of search you have not found yet, but if you click in the search box itself, you get this:

You seem to have some sort of compromised install or hardware problem that you reported long ago and has continued. There are no responses, because others don't know why your system is randomly behaving that way, and the problem you describe is not happening to them. Reading through all your posts, you don't seem to be very satisfied with XPEnology ever, and seem to be looking for a reason to use something else. But if you do want to keep on, consider a validation test of your hardware (no overclock, full system and memory test, etc) and then a totally clean installation. Also verify your function prior to installation of, or do not use root-level customization like ipkg/opkg. Regarding your last statement about cost/value, I don't know where you come up with that; if it were true nobody would be using XPEnology Synology doesn't even make a product with the features of my own box, for instance, and the closest (grossly inferior) match is more than twice the cost of my parts.

ixgbe driver is in the DS918 image. You might want to dig a little deeper in the logs to see what is going on. For your future reference:

6.2.1-23824 is a newer patchlevel than 6.2-23739

Dropped by whom? 6.2.1 is the latest available and it runs on 3615 image fine.

Yes, DS918 is the only loader-supported DSM release that is on the 4.4 kernel tree. I'm sure that Synology is using 4.4 for all their newly released product lines. I'm not sure how anyone outside of Synology development would know if they intend to update the kernel on older products. They publicly state that they backport security updates to older kernels. If they were going to arbitrarily upgrade the kernel (or if they were compelled to do so for DSM functionality dependencies), the DSM 7.0 release would seem to be a likely opportunity.

Are you certain that you need to use extra.lzma? DS3615xs has mptsas driver installed in the first place.

Yes, just search, it's right there.

Serial port console. You can redirect it virtually with ESXi.