ariel Posted November 5, 2018 Share #1 Posted November 5, 2018 (edited) 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 November 5, 2018 by ariel added error when attempting to upgrade Quote Link to comment Share on other sites More sharing options...
flyride Posted November 5, 2018 Share #2 Posted November 5, 2018 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. Quote Link to comment Share on other sites More sharing options...
ariel Posted November 5, 2018 Author Share #3 Posted November 5, 2018 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 Quote Link to comment Share on other sites More sharing options...
flyride Posted November 5, 2018 Share #4 Posted November 5, 2018 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. 1 Quote Link to comment Share on other sites More sharing options...
WiteWulf Posted January 16, 2019 Share #5 Posted January 16, 2019 (edited) 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 January 16, 2019 by WiteWulf Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.