Jump to content
XPEnology Community

cuspess

Member
  • Posts

    47
  • Joined

  • Last visited

Recent Profile Visitors

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

cuspess's Achievements

Junior Member

Junior Member (2/7)

0

Reputation

  1. Followed steps 1 to 9 from op, but still get "The operation failed. Please log in to DSM again and retry". I am not fluent in SSH at all, so I have no clue what is supposed to return after entering each line from step 1 to 9 to the SSH console. But I suspect something went wrong at Step 3 for me. I extracted the linked "syno-letsencrypt.zip" with winRAR, uploaded the file to my xpenology's shared folder called "Work". The saved location displayed in Properties is "/volume1/Work/" and the extracted file became an empty folder once uploaded to my "Work" shared folder. I typed in the commend line as instructed in Step 3 with "Downloads" replaced by "Work" which is my shared folder. "sudo cp /volume1/Work/syno-letsencrypt /usr/syno/sbin/" Then the console return with the line: Password: which i entered my DSM password Then the a line returned: cp: omitting directory '/volume1/Work/syno-letsencrypt' I carried on with step 4 to 9, and as mentioned gets "The operation failed. Please log in to DSM again and retry". I am not sure if the file inside syno-letsencrypt.zip actually get copied to my shared folder as it turned to an empty folder without any file size. Then I also not sure if the file did copied to /usr/syno/sbin with the omitting directory prompt. Can someone please help? thanks so much
  2. Sure enough if you already got Jun's 1.0.2a2 or 1.0.2a working with your machine, then you are safe. I personally encountered Error 13 with both loader and just couldn't get it working with my rig. And this post is about people like me not able to update to these 2 loader with bug free DSM 6.1 installed. Recommendation like Salah's is quite useful. There we have a hint what could be done if we could not upgrade to DSM 6.1.1-U4. Now if Salah can elaborate more this method, that would be great.
  3. It seems that Synology has released a security patch yesterday to address the potential vulnerability of DSM in relation to recent WannaCry attacks. Xpenology usually is quite stable once you got the bootloader all working bug free; but it is the time like these that could cause problem to xpenology users, just like synolock back in 2014. Xpenology users are limited to certain version, depends on the bootloader version they are using. For instance some user are still on DSM 5.x which their bootloader doesn't support further update or a complete upgrade of bootloader is require if to upgrade to DSM 6; same applies to those, and including myself, who yet to get the newer bootload which support DSM 6.1 to work with their machine. My queries, with the difficulties mentioned above, how do we protect ourselves from security vulnerability? Version: 6.1.1-15101-4 (2017/05/25) Important Note The update is expected to be available for all regions within the next few days, although the time of release in each region may vary slightly. Fixed Issues Fixed a security vulnerability regarding samba service (CVE-2017-7494).
  4. While I agree both points, I think whether to use DS3617xs or DS3615xs bootloader comes to trial & error more than anything. No doubt people with knowledge in these area could make a better judgement on which would suit them better, but because most hardware we use to run DSM here are unofficially supported, no guaranteed anything would work. So I think there is no harm trying both, with your testing environment at least, to find which suits your hardware best.
  5. I aint Rhubarb so maybe only he can answer exactly. But I am making a guess here that it really doesn't matter if you go for DS3615XS or DS3617XS because you need to create a new usb drive to boot the DSM 6.1 or later iteration anyway. Moreover latest Jun's loader for DS3615XS is v1.02a whereas the latest is v1.02a2 for DS3617XS, which is a later revised version. Although I remember v1.02a2 only contains very minor change, it still make sense to go for the later version if you were to try something new. Having said all above, neither of the two loader work for my setup with both error 13, which really is a bomber.
  6. cuspess

    DSM 6.1.x Loader

    Interesting. I am on Gen8 Microserver, ESXi 6.0, tried both DS3615xs 1.02a and DS3617xs 1.02a2, neither worked, both produce error 13.
  7. cuspess

    DSM 6.1.x Loader

    I got it back up and running few hours ago, then spent few hours working on all the settings to match mostly how I had it before. With the recent wannacry strikes around the globe, i also try to tighten my security such as setting more restrictive firewall rules and blocking unused ports, etc. I think my failure in upgrading to DSM 6.0.3 did indeed give me this great opportunity to do so. My DSM is running on a Gen8 Microserver under esxi 6, so it would be different experience to your mediasmart server setup i would imagine. From what you described if 6.0.2 rev8 did work flawlessly, you might want to download the .pat file of 6.0.2 rev8 and fresh install onto a spare Hard Drive, get over the initial setup, then plug in your original Hard Drive. DSM will then prompt your to repair your original Hard Drive. After the repair, you should be able to turn off the machine and unplug the spare Hard Drive, boot it up again with your original Disk. Down side is, you won't retrieve your DSM settings. But for me it is fine as I want to start over, but most importantly my data were kept intact this way.
  8. cuspess

    DSM 6.1.x Loader

    Hey, I am back to report I have revived my DSM and all data; only lost the DSM settings e.g. user, apps, backup schedules, etc. It was done with the method I mentioned in my previous post, by installing a new DSM on a spare disk to repair the corrupted system partition on my existing storage disks. I take it a opportunity to clear up some bloated and abandoned settings, so I am pleased with the result. And this is where I think the forum should evolve. I am sure there are plenty of users without much technical knowledge in coding programming but have some kind of idea how to get round things just like myself in this forum (obviously there are also many more with such knowledge and tinkering capability), but there are relative lot more of those who just don't know what they are doing yet want to grab a piece of this holy grail of xpenology, those who jump into it without knowing anything then only ask everything without even a look around. Thats what bloating the forum, together with a unorganised forum structure and buzzard searching engine made looking up useful information and write ups even more obscure. I still think there are good guys doing the community great here, I can tell by some of the search returned result. But why hiding them and requiring a search to reveal them? if you list them out clearly, with good layout and appropriate location, it will efficiently lower the bloat questions and threads and posts.
  9. btw I am using Gen8 too, though run DSM under esxi. Otherwise we had a very similar setup. One thing you got lucky, which is that DSM 6.1 actually works for you. Somehow I couldn't get it work. So I am recovering back to 6.0.2 using your above method.
  10. Good write up. I faced similar issue and had the same idea in my head to solve it. Great to see someone already come across this method and assure my thinking. Will try this now, hope it all works out.
  11. cuspess

    DSM 6.1.x Loader

    So I just saw the red text on the updated tutorial regarding shouldn't update to 6.0.3 on v1.01 when looking for solution to my situation. Damn. I wish any updated or important notes was made clear in the forum, like a specific headline in big text or a prompt note or something. Not to blame anyone but this forum is bloated with questions of outdated DSM5 and query of different issue, it is just so difficult to aware of any update, not to mention any important notice.
  12. cuspess

    DSM 6.1.x Loader

    Thank you IG-88 for your response. I am proceeding with my plan at the moment. Unfortunately I hit the wall already as we speak. I encountered the Error 13, which I expereienced previously when testing Jun's 1.02a DS3615xs loader on a separate testing vm. I wasn't running a passthrough back then so I thought the error was caused by that. Now with passthrough error 13 remains, that is tricky. Will need to see what I can do to work it.
  13. cuspess

    DSM 6.1.x Loader

    To add in some background, I am running ESXi 6 on a HP Microserver Gen8, with the built-in B120 controller run in ACHI mode and passthrough to the DSM virtual machine. Which means my production Hard Drives should technically plugged in and formatted just like a normal Synology NAS would be.
  14. cuspess

    DSM 6.1.x Loader

    I have been on Jun's 1.01 running with DSM 6.0.2 for ds3615xs for quite some time, runs stable and faultless for months. I have been notified a new update of DSM 6.0.3 is avaliable for weeks but reluctant to update until just now. I have always been able to update using the updater in control panel over the past few updates. But this time my dsm would not boot up. The local IP is changed and I got given the option to recover. Not hard to guess the recovery didn't work out. So I am going to try upgrading to Jun's v1.02a2 and hopefully by installing the new DSM 6.1, it will work again. One technical issue though. As the hard drives I am using is the main production drives with my important data, I have a thought of first unplug all the drives and install the DSM 6.1 with a spare hard drive. That should classify as a clean install, then I will plug back in my production drives; in theory I should then be able to "migrate" or "re-habit" my data back to the new DSM 6.1. Can anyone confirm this will work?? Will I be able to then transfer the DSM 6.1 settings and main system files back to my production drives from the spare, optimally unplug the spare drive to free up the bay again??? Kind of nervous because I didn't expect upgrading to 6.0.3 would go wrong, even I knew migrating to 6.1 would be more likely to fail and avoided it. So any help and advice would be deeply appreciated. Thank you
  15. Just tried creating a vm with 40GB virtual HDD on esxi 6.0, boot the loader v1.01a2 for DS3617xs of a USB flash drive. It boots into "Install DiskStation Manager (DSM)" alright, then when I try to start the installation by using "Manual Install" with "DSM_DS3617xs_15047.pat" or "Install the latest DSM", it both proceed to 54% and interrupted with error message "Failed to installthe file. The file is probably corrupted. (13)" Thinking it might be something to do with my virtual HDD, but the same method had been deployed successfully on my working xpenology, which is still on DS3615xs DSM 6.0. Not sure what's the problem is. Anyone with similar experience?
×
×
  • Create New...