flyride

Members
  • Content Count

    496
  • Joined

  • Last visited

  • Days Won

    38

flyride last won the day on October 22

flyride had the most liked content!

Community Reputation

186 Excellent

4 Followers

About flyride

  • Rank
    Super Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. https://xpenology.com/forum/topic/23473-new-to-xpenology/?do=findComment&comment=127956 Please note the post discussing the FAQ
  2. Nobody knows. The current 1.03b and 1.04b loaders seem to work with DSM 6.2.x but any new DSM patch can (and does with surprising regularity) fail to work with them. The community has found workarounds in most cases. That's the reason for this thread here: https://xpenology.com/forum/forum/78-dsm-updates-reporting/ Look for folks with similar hardware, virtualization, loader and DSM versions being successful before attempting any DSM update. And seeing as you are planning to use ESXi, there really is no excuse not to have a test XPenology DSM instance to see if the upgrade fails or succeeds before committing the update to your production VM. When Synology releases DSM 7.0, it's a virtual certainty that the current loaders will not work. Someone will have to develop a new DSM 7.0 loader hack, and there is really no information about how long it might take or how difficult it may be.
  3. It's not possible for you to agree to Synology's Terms of Service. By using XPenology to connect to Synology services, you are directly violating them. Please note this from the FAQ: https://xpenology.com/forum/topic/9392-general-faq/?do=findComment&comment=82390
  4. Clicking the upgrade button would be unwise. You will need to burn a new boot loader, and you will need to evaluate your hardware to see what combination of loader and code to use. https://xpenology.com/forum/topic/13333-tutorialreference-6x-loaders-and-platforms/ Please have a backup/backout plan as it's not always straightforward depending on your system.
  5. Yes, that's your boot loader and is a required runtime filesystem for DSM. It's not an installation key.
  6. I'm not an HP expert, but I can answer the distilled-down question above. The CPU you have is an Ivy Bridge architecture, which is too old to run the DS918 version of DSM, compiled to use new instructions present in Haswell or later. So those running Ivy Bridge architecture have no choice but to run DS3615xs. Hardware transcoding requires Intel Quicksync drivers that are only implemented on DS918 DSM. This post may help you understand the limitations further.
  7. MBR and Legacy are two different things. If you can support a GPT partition, definitely do so. Loader 1.02b (for 6.1.x) can work in either Legacy or UEFI mode Loader 1.03b (for 6.2.x) works in Legacy mode Loader 1.04b (for 6.2.x) works only in UEFI mode
  8. Nothing that a VPN won't solve. If you think your "patched up" Synology box can't be hacked, you need to meet some white hat security folks.
  9. Sorry for the event and to bring you bad news. As you know, RAID 5 spans parity across the array such that all members, less one must be present for data integrity. Your data may have been recoverable at one time, but once the repair operation was initiated with only 2 valid drives, the data on all four drives was irreparably lost. I've highlighted the critical items above.
  10. If the array was healthy when shut down, it should work out of order. But that is a last resort. I'd use some blank drives and figure out the order of the ports before installing.
  11. Ok, this is a simple system with the following likely attributes: VMware is probably installed on a USB key and booting from that You have a small (32GB) SSD which is dedicated for the VMware scratch datastore You have created a XPEnology VM, storing the virtual boot loader and a 200GB sparsely populated virtual disk as storage for XPEnology. These are all stored on scratch datastore. Presumably you have installed DSM to the virtual disk but it's not clear if you have built a storage pool or a volume. You probably have a physical HDD you want to use as a second (?) disk for XPEnology. This is not explained or shown in the system pics. Hopefully you can see that sparse virtual disk storage will be problematic in a production environment because your virtual disk will rapidly exceed the SSD physical storage once you start putting things onto it. This is fine for test to simulate a larger disk, but definitely not for production. Assuming I am correct about the second disk (assuming for now it is an HDD) you wish to add, there are three ways to connect it. Create a new datastore in ESXi and locate the HDD. Then create a virtual disk for some or all of it, and attach that virtual disk to your VM, which should then be visible in DSM. Create an RDM pointer to the HDD (see my sig on how to do this). Then attach the RDM definition to your VM. The entire disk should then be visible in DSM. If your SSD is not on the same SATA controller as your HDD (for example if SSD is an NVMe drive), you can pass your SATA controller through to the VM entirely. Any attached drives then will be visible to DSM as long as your SATA controller is supported by DSM. This is probably a bit overwhelming. You seem new to ESXi so just build up and burn down some test systems and do a lot of research on configurations, until you get the hang of it. Good luck!
  12. You'll have to be more specific about what you have now, and what you are trying to do. There isn't anything magic about ESXi, but it will matter how you are provisioning your storage.
  13. Quicknick's loader is not supported, and not supported here.
  14. Especially as if someone bought several at once, they all fail within a few moments of each other. Unbelievable.
  15. Download 6.2.1, install and follow the real3x procedure. It's not just replacing extra.lzma, but you have to run the scripted commands that cause the i915 driver to be disabled. Then update to latest version.