ariel

Using Xpenology to test DSM upgrade on RS3411xs

Recommended Posts

Hello everybody,

 

I have been reading up and trying out Xpenology. This is a truly awesome project! Thank you everybody!

 

The main reason for my interest in Xpenology is to test the DSM upgrade from DSM 5.0 to (one of) the latest versions of DSM, before upgrading a production Synology NAS. The production NAS has been heavily customized which is why I feel it is prudent to test the upgrade on a virtual system before upgrading the production system.

 

I have created a VirtualBox-based Xpenology running DSM 5.0 and implemented all of the customizations that are on the production NAS. I then successfully upgraded this system to DSM 5.1 and was able to check that the customizations remained in place and were operational. But before I continue to test the upgrade to DSM 5.2 and to DSM 6.x, I wanted to try and set the Xpenology model to the model of the production NAS. For this purpose I modified the "syno_hw_version" in the syslinux.cfg file of the Xpenology boot image. While the virtual system comes up in DSM 5.0 and is operational, when I try to upgrade this system to DSM 5.1 (after making this change also to the syslinux.cfg file of the DSM 5.1 boot image, and with the PAT for that hardware), the upgrade fails to complete. The error is Error 21.

 

My questions are:

1) Is there any way to customize the boot images so I can use Xpenology to simulate Synology systems other than the specific models for which the boot images were made? Specifically, are serial numbers and MAC addresses tied to Synology hardware models? Is there anything else that needs modification? Or is this hopeless?

2) Is anyone able to give me some indication as to how different the versions of DSM are/behave on different multi-bay, Intel-based Synology models? In other words: if the upgrade works and keeps the customization intact on a DS3615xs, how likely is that result to be a valid indication of the result of an upgrade on a different multi-bay, Intel-based Synology model?

 

Thank you!

 

Ariel

Edited by ariel
added error when attempting to upgrade

Share this post


Link to post
Share on other sites

The short answer is no, you can't do what you want with simulating different Syno hardware.

 

You can only use the specific PAT files (and major DSM versions) that each XPenology loader is built for.  Any other PAT file won't function.  Yes, serials/MACs are coded to hardware types.

 

Internal to DSM, the model string is just informative. You won't be changing the behavior of DSM due to setting that.  The PAT files may start with the same base code, but are compiled for each target hardware platform, and can different significantly from model to model, including the versions and  types of Synology utilities.

 

To your last question, I imagine that it depends on the nature of your customization.  You still may be able to use XPenology to test a newer DSM.  Can you provide some specifics?  Some knowledgeable folks here might have some advice on that.

 

Share this post


Link to post
Share on other sites

Thanks very much for the quick reply flyride!

I guess I can stop my clumsy attempts to modify XPEnoboot images then...

 

Quote

To your last question, I imagine that it depends on the nature of your customization.  You still may be able to use XPenology to test a newer DSM.  Can you provide some specifics? 

 

I am listing here a partial list of customizations. Not included are various standard packages which can easily be re-installed.

Linux GNU toolchain

 

ipkg (optware) with

bash
binutils
bzip2
coreutils
cpio
libc-dev
libcurl
libdb
libidn
libnsl
libstdc++
ncurses
ncursesw
openssl
py26-curl
py26-setuptools
python26
readline
screen
sqlite
termcap
wget-ssl
zlib

 

Modified Craftbukkit server with source and toolchain

CrashPlan with modified configuration

Replacement for FFmpeg with support for DTS

Various customizations to MailServer including support for virtual users on multiple domains each with their own DKIM and DMARC configuration, modifications to SpamAssassin

Git and SVN

Java 8

Debian chroot

 

It is of course possible to re-apply all of these customizations after an upgrade. But what worries me most is the possibility that something will prevent the upgrade from completing successfully on the production unit.

 

Thanks again,

 

Ariel

 

Share this post


Link to post
Share on other sites

Frankly, today the way to do this is to encapsulate the functionality in Docker containers rather than modify the standard DSM environment. The beauty of Docker on DSM is that you can extend Synology filesystem access (and speed) directly into the container so there really is no performance downside.  If that interests you, you could easily do all your Docker dev/test in XPenology and then have very high confidence it would function exactly the same ported over to other DSM versions and Syno platforms.

 

I used to run optware and never had any real issues (other than a version upgrade overwriting the optware startup, which was easy to restore).  Since it installs it's own package versions in its own directory tree, and because the standard shell doesn't have optware enabled, compatibility seemed to work out pretty well for upgrades.  But again, I've pretty much moved all the things I wanted to do in the native shell/optware to Docker and won't look back now.

 

1 hour ago, ariel said:

It is of course possible to re-apply all of these customizations after an upgrade. But what worries me most is the possibility that something will prevent the upgrade from completing successfully on the production unit. 

 

That said, I'd be confident of using XPenology to model out your upgrade and functionality plan.  Again, I never encountered problems with upgrading due to optware excepting the rc entries to start optware.  However, that advice is worth exactly what you paid for it :-)

 

Good luck.

  • Thanks 1

Share this post


Link to post
Share on other sites

Just wanted to quickly bump this: I needed to be able to run 'lsof' against the Synology (not a docker container) as part of some debugging and the optware-ng repo at:

 

https://github.com/Optware/Optware-ng

...still functions fine on my system using the 'x86_64' architecture files.

 

But yeah, for 99% of other cmdline tasks I use a debian docker container these days (great for running mkvtoolnix and ffmpeg jobs on files that I want to mangle in my Plex library).

Edited by WiteWulf

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.