Recommended Posts

There are some nice functions in 5.1.. as well as some improvements to security attack points I would imagine.

Relax, this is just a network storage server and it will continue its primary function to store files even with not the latest OS. If its possible to break the latest DSM it will be done one day. Getting the original Synology box and update to the latest "With Bells and Whistles" DSM is still an option for the most impatient.

Share this post


Link to post
Share on other sites

I really hope we will get this ASAP. That doesn't mean I'm impatient.

 

The one new feature, not just a bell or a whistle, that I'm waiting for is the built in sync with Onedrive. Plus it would be very nice to see what the new security center has to tell us in order to get DSM more secure.

 

Keep up the good work guys!

Share this post


Link to post
Share on other sites
I'm waiting for is the built in sync with Onedrive.

Just enable the beta channel in Package Manager and update the Cloud Sync to lastest beta version.

 

Plus it would be very nice to see what the new security center has to tell us in order to get DSM more secure.

And you'll always see 'hacked' and 'vulnerable' state due to nature of XPENOLOGY )

Share this post


Link to post
Share on other sites
Relax, this is just a network storage server and it will continue its primary function to store files even with not the latest OS. If its possible to break the latest DSM it will be done one day. Getting the original Synology box and update to the latest "With Bells and Whistles" DSM is still an option for the most impatient.

Now, where are the "Like" and "Thumbs up" buttons? :wink:

Share this post


Link to post
Share on other sites
Relax, this is just a network storage server and it will continue its primary function to store files even with not the latest OS. If its possible to break the latest DSM it will be done one day. Getting the original Synology box and update to the latest "With Bells and Whistles" DSM is still an option for the most impatient.

Now, where are the "Like" and "Thumbs up" buttons? :wink:

 

Do you want me to put " send a beer" button instead?

:grin:

Share this post


Link to post
Share on other sites

"Beerware"

 

Relax, this is just a network storage server and it will continue its primary function to store files even with not the latest OS. If its possible to break the latest DSM it will be done one day. Getting the original Synology box and update to the latest "With Bells and Whistles" DSM is still an option for the most impatient.

Now, where are the "Like" and "Thumbs up" buttons? :wink:

 

Do you want me to put " send a beer" button instead?

:grin:

Share this post


Link to post
Share on other sites
I'm waiting for is the built in sync with Onedrive.

Just enable the beta channel in Package Manager and update the Cloud Sync to lastest beta version.

 

Plus it would be very nice to see what the new security center has to tell us in order to get DSM more secure.

And you'll always see 'hacked' and 'vulnerable' state due to nature of XPENOLOGY )

 

I updated the Cloud Sync beta.... The sync speed with One drive very slow.....

 

 

從我的 用 iPad 發送

Share this post


Link to post
Share on other sites

The one new feature, not just a bell or a whistle, that I'm waiting for is the built in sync with Onedrive

 

no need to wait ! OneDrive Hubic and Box came up with DSM 5 update 7 :smile: tested & approved

Share this post


Link to post
Share on other sites

It took me a few tries, but I now have a Virtualbox vm running 4977 Update1 Volume1. I used the NB_x64_5032_DSM_51-4977_BETA_Xpenology_nl.iso and 4 32GB .vdi disks. Procedure was:

 

1. Create VM & Disks

2. Install 5.0-4493, but do not SHR create volume

3. Update this to Update 7.

4. Verify that the array is healthy (cat /proc/mdstat) poweroff.

5. Power on, select 4977 install from boot menu in Console.

6. Install using synology assistant & DSM_DS3612xs_4977.pat

7. Be patient. Wait until you can logon as your admin account via the console.

8. Wait until the md0 / md1 raid is fully operational (cat /proc/mdstat)

9. Poweroff.

10. Poweron, login to gui, set ssh/telnet/time etc.

11. Open ssh (via putty)

12. Download Update in Gui

13. sed's & mv the upd@teinfo as usual

14. Install the update

15. Poweroff

16. Poweron, create the volume in the GUI.

 

The key was not creating the volume until beta 51. is in and updated. I realise that this isn't a viable upgrade path for a running installation, but it does prove that Synology haven't done anything that breaks or interferes with xpenologys boot method.

 

When I first tried upgrading a VM to beta 5.1 it was with a volume created in 5.0 - this resulted in apparmor bombing and wierd stuff happening with the raid array (md2 got lost, and md0 & md1 were getting renamed and built with non existing devices - it ran, in the sense of having a filesystem on it, but the configuration was so messed up that it couldn't be checked, modified, or expanded.

 

Andrew

Share this post


Link to post
Share on other sites

avanerven wrote:

The one new feature, not just a bell or a whistle, that I'm waiting for is the built in sync with Onedrive

 

no need to wait ! OneDrive Hubic and Box came up with DSM 5 update 7 :smile: tested & approved

 

Excellent news. I will try to update my system this afternoon! Thanks for the info.

Share this post


Link to post
Share on other sites

So I've updated to update 7 while waiting for 5.1 to get the Onedrive sync.

 

Someone mentioned that Onedrive sync is included in update 7 but I cant seem to find it anywhere.... bummer.

Share this post


Link to post
Share on other sites
It took me a few tries, but I now have a Virtualbox vm running 4977 Update1 Volume1. I used the NB_x64_5032_DSM_51-4977_BETA_Xpenology_nl.iso and 4 32GB .vdi disks. Procedure was:

 

1. Create VM & Disks

2. Install 5.0-4493, but do not SHR create volume

3. Update this to Update 7.

4. Verify that the array is healthy (cat /proc/mdstat) poweroff.

5. Power on, select 4977 install from boot menu in Console.

6. Install using synology assistant & DSM_DS3612xs_4977.pat

7. Be patient. Wait until you can logon as your admin account via the console.

8. Wait until the md0 / md1 raid is fully operational (cat /proc/mdstat)

9. Poweroff.

10. Poweron, login to gui, set ssh/telnet/time etc.

11. Open ssh (via putty)

12. Download Update in Gui

13. sed's & mv the upd@teinfo as usual

14. Install the update

15. Poweroff

16. Poweron, create the volume in the GUI.

 

The key was not creating the volume until beta 51. is in and updated. I realise that this isn't a viable upgrade path for a running installation, but it does prove that Synology haven't done anything that breaks or interferes with xpenologys boot method.

 

When I first tried upgrading a VM to beta 5.1 it was with a volume created in 5.0 - this resulted in apparmor bombing and wierd stuff happening with the raid array (md2 got lost, and md0 & md1 were getting renamed and built with non existing devices - it ran, in the sense of having a filesystem on it, but the configuration was so messed up that it couldn't be checked, modified, or expanded.

 

Andrew

 

Hi Andrew,

 

I followed the steps you provided above.

However, after step 10, I login into DSM and found that all disks disappeared... :sad:

I did upgrade to 4493 Update 1, but after step 16, disks are gone too...

I cant create volume from GUI... Did I miss anything?

Thank you for help.

Share this post


Link to post
Share on other sites

Did you check that the raid was built and synced (cat /proc/mdstat) at step 8 before continuing?

As far as I understand, synology doesn't use mdadm.conf, but they store the equivalent information somewhere else & the install program apparently only writes this info to the configuration AFTER the array is built and synced. This is why mdadm --assemble --scan doesn't work: there is no mdadm.conf, and mdadm can't make sense of the on disk structure.

 

What do "cat /proc/partitions" and "cat/proc/mdstat" tell you with the machine in its current state?

Share this post


Link to post
Share on other sites

also, what does "/usr/syno/sbin/synospace --enum -a" tell you?

 

I just discovered "synospace" over the weekend it seems to be synologys interface for blockdevices/arrays/volumes.

Share this post


Link to post
Share on other sites
Did you check that the raid was built and synced (cat /proc/mdstat) at step 8 before continuing?

As far as I understand, synology doesn't use mdadm.conf, but they store the equivalent information somewhere else & the install program apparently only writes this info to the configuration AFTER the array is built and synced. This is why mdadm --assemble --scan doesn't work: there is no mdadm.conf, and mdadm can't make sense of the on disk structure.

 

What do "cat /proc/partitions" and "cat/proc/mdstat" tell you with the machine in its current state?

 

After step 8, system has md0, md1, and md2. But after reboot again, it only left md0 and md1.

 

For current state, /proc/partitions shows system has sda, sda1, sda2, and sda3.However, it shows no disk in DSM (Storage Manager).

/proc/mdstat shows only md0 and md1 too.

Share this post


Link to post
Share on other sites
also, what does "/usr/syno/sbin/synospace --enum -a" tell you?

 

I just discovered "synospace" over the weekend it seems to be synologys interface for blockdevices/arrays/volumes.

 

"/usr/syno/sbin/synospace --enum -a" shows me nothing.. :sad:

Share this post


Link to post
Share on other sites

Ok, the synospace shows no trace of a volume at all. Apparently that is all that synospace manupulates.

 

Back to step 8, during the install, md0, md1, and md3 were present, BUT DID YOU WAIT FOR THEM TO REBUILD/SYNC - this takes a Loooong time, you can speed it up by entering:

sysctl -w dev.raid.speed_limit_min=200000

sysctl -w dev.raid.speed_limit_max=5000000

but even then it will take something close to a day with 4Tb Disks (depending on cpu, ram and disk controller)

 

I was working in a VM with only 4x 32GB "disks" and it still took something like 3 hours.

 

The key, I think, is that you DO NOT shutdown/restart during the install UNTIL THE ARRAY IS COMPLETELY FINISHED BUILDING AND SYNCING.

 

Every attempt I made with the vm failed until I waited for the array to be completely assembled and synced, once I did, it worked fine (& I have now done it a few times, so it probably wasn't just chance)

 

Andrew

Share this post


Link to post
Share on other sites

Hope in the DSM 5.1 final it's possible to migrate without recreate volumes...

Share this post


Link to post
Share on other sites
also, what does "/usr/syno/sbin/synospace --enum -a" tell you?

 

I just discovered "synospace" over the weekend it seems to be synologys interface for blockdevices/arrays/volumes.

 

"/usr/syno/sbin/synospace --enum -a" shows me nothing.. :sad:

 

same here. synospace --enum with any option shows nothing.

Share this post


Link to post
Share on other sites

synospace is apparently only for manipulating the volumes. The problem with trying to get the beta51 installed is that it doesn't create the volume (except as I documented above), so if, after the reboot, you have no md2, then you haven't got any volumes.

 

I tried for a long time to get md2 (which is normally constructed from the sdX5 partitions) up. I think I must have tried every variant of mdadm -assemble -create -destroy -build or what have you, I also tried mounting the disks under a different vm and recovering the raid, It seems that if md2 isn't up, clean, and synced before you do the shutdown at the end of the upgrade/install of DSM51 then it never will be.

 

I have installed DSM51 on various VMs using the procedure above, and it does come up with the volume working, so whatever it is, it isn't some module that is missing, or new check that synology has built in to make xpenology impossible, but plain and simple a question of timing. What I did notice when trying to resuscitate the md2 was that although md0 & md1 were built from sdX1 and sdX2, what the mdadm did find in the ondisk structures was hdx... not sure if this is a latencey issue with udev detection still starting or not, frankly I don't now enough about linux to say.

Share this post


Link to post
Share on other sites

i figured out the same. in DSM5.0 raid is build on sdX and under DSM5.1 on hdX. i think its related with that:

Synology Hybrid RAID is no longer supported.
its from DSM5.1 release notes. in my case the problem is that after using this procedure cat /proc/mdstat is showing that that md0 and md1 are build on sdX and i dont know how to change it or just delete md0 and md1 manually.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now