-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Syncthing: DSM7 Repair Package Caused Loss of AppData? #4888
Comments
Until now nowbody here has a generic solution on how to migrate packages from DSM 6 to DSM 7. The only rule of thumb is
|
@hgy59 All the files from ${SYNOPKG_PKGDEST}/var should be copied to ${SYNOPKG_TEMP_UPGRADE_FOLDER} Maybe this should be added as kind of default action when upgrading from DSM6 to DSM 7? |
That is rather interesting as currently the code directly copies it over to |
@th0ma7 So SYNO_PKGVAR wil point in this case to /volume1/@appdata/syncthing which did not exists prior to DSM 7 and will be created during the installation phase. The problem with this migration from DSM 6 to DSM 7 is that testing is very difficult (for me at least) because I have a DSM 6 NAS and a DSM 7 NAS. |
Indeed testing is not an easy thing. The proposed patch to my PR does that, rsync to a tmp directory pre_upgrade then rsync back to SPKVAR at post_upgrade, which in theory should fix things. |
The problem is, when you have a package installed on DSM 6 and upgrade to DSM 7 and then press repair:
That's why I recommend to never press repair, but install a package (that you know it is built for DSM 7), over an existing package installation. |
I agree totally, nobody knows what repair is trying to do and not even why DSM in some cases (but not all) give you this option. |
I have access to a number of DSM6/Syncthing installations, which I'll be gradually upgrading to DSM7 over the coming weeks. I'm happy to perform any testing required as part of these upgrades - just let me know what you want me to check for during each stage of the process, and let me know where I should keep an eye for updated builds/build instructions - I've only used SynoCommunity for the Syncthing package, so I'm not familiar with where I should be looking round these parts! ;-) |
Oh... and a Feature Request if it's possible... :-)
Is it possible to update the GUI to show that these things are happening? The Syncthing DB can be many GB, which can take a looong time to copy; in the absence of a note to say this copy is happening, it's easy to assume the upgrade has stalled, and proceed to reboot the NAS... (Speaking from early personal experience!) |
I don't know when the changes from @th0ma7 will be available, but to saveguard you for potential problems you could make a copy of the database, configuration and certificate files before you upgrade and if things don't work out restore those files yourself.
After you have upgrade to DSM 7 and installed the DSM 7 version of syncthing (don't start syncthing yet) check of those files are present in that location. By the way, that location is a simlink which differ from DSM 6 to DSM 7 (moved from @appstore to @appdata). And the only message a package can send to the user is at the end of the installation process as far as I know. |
installer is fixed with #5117. It should now properly migrate from DSM 6 to DSM 7 (but this is hard to verify). |
Setup
Package Name: Syncthing
Package Version: 1.17.0-22
NAS Model: DS2415+
NAS Architecture: INTEL Atom C2538
DSM version: 7.0.1-42214
Expected behavior
Syncthing setup files should be preserved
Actual behavior
Syncthing setup files were apparently deleted...
I've not had any such problems before (and I have successfully upgraded another Synology NAS with the same configuration), but today I performed the following sequence of actions:
On launching Syncthing after this, I was greeted with a default setup.
Looking in
/volume1/@appstore/syncthing/var
(the DSM6 location), I can only see newconfig.xml
andoptions.conf
files - theindex-v0.14.0.db
folder etc are entirely missing.Looking in
/volume1/@appdata/syncthing/var
(the DSM7 location), I can see a full complement of setup files - but these have been generated anew.Package log
Looking at the package log, I can't see anything that differs from previous upgrade entries - though I am confused by
Begin /bin/rm -rf /volume1/@appstore/syncthing
- I can't see how the app data is preserved through this...This isn't a massive problem for me - I can re-set the config manually - but I wouldn't want someone else to fall foul of an unexpected problem here.
And many thanks for the DSM7-compatible release otherwise - great work! :-)
The text was updated successfully, but these errors were encountered: