Skip to content
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

Closed
Moisie2000 opened this issue Sep 27, 2021 · 11 comments
Closed

Syncthing: DSM7 Repair Package Caused Loss of AppData? #4888

Moisie2000 opened this issue Sep 27, 2021 · 11 comments

Comments

@Moisie2000
Copy link

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:

  • Ensured the Syncthing package was up to date;
  • Upgraded from DSM 6.2.4 to 7.0.1;
  • Repaired the Syncthing package after the DSM upgrade.

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 new config.xml and options.conf files - the index-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...

2021/09/27 08:41:45	install syncthing 1.17.0-22 Begin start-stop-status stop
2021/09/27 08:41:48	install syncthing 1.17.0-22 End start-stop-status stop ret=[0]
2021/09/27 09:09:45	(system) trigger syncthing 1.17.0-22 Begin start-stop-status stop
2021/09/27 09:09:46	(system) trigger syncthing 1.17.0-22 End start-stop-status stop ret=[0]
2021/09/27 09:16:21	upgrade syncthing 1.17.0-22 Begin preupgrade
2021/09/27 09:16:21	===> Step preupgrade. USER=sc-syncthing GROUP=sc-syncthing SHARE_PATH=
2021/09/27 09:16:21	upgrade syncthing 1.17.0-22 End preupgrade ret=[0]
2021/09/27 09:16:21	upgrade syncthing 1.17.0-22 Begin preuninst
2021/09/27 09:16:21	===> Step preuninst. USER=syncthing GROUP=sc-syncthing SHARE_PATH=
2021/09/27 09:16:21	upgrade syncthing 1.17.0-22 End preuninst ret=[0]
2021/09/27 09:16:22	upgrade syncthing 1.17.0-22 Begin /bin/rm -rf /volume1/@appstore/syncthing
2021/09/27 09:19:13	upgrade syncthing 1.17.0-22 End /bin/rm -rf /volume1/@appstore/syncthing ret=[0]
2021/09/27 09:19:13	upgrade syncthing 1.17.0-22 Begin postuninst
2021/09/27 09:19:13	===> Step postuninst. USER=syncthing GROUP=sc-syncthing SHARE_PATH=
2021/09/27 09:19:13	upgrade syncthing 1.17.0-22 End postuninst ret=[0]
2021/09/27 09:19:13	upgrade syncthing 1.17.0-22 Begin preinst
2021/09/27 09:19:13	===> Step preinst. USER=sc-syncthing GROUP=sc-syncthing SHARE_PATH=
2021/09/27 09:19:13	upgrade syncthing 1.17.0-22 End preinst ret=[0]
2021/09/27 09:19:13	upgrade syncthing 1.17.0-22 Begin /bin/mkdir -p /volume1/@appstore/syncthing
2021/09/27 09:19:13	upgrade syncthing 1.17.0-22 End /bin/mkdir -p /volume1/@appstore/syncthing ret=[0]
2021/09/27 09:19:13	upgrade syncthing 1.17.0-22 Begin /bin/rm -rf /volume1/@appstore/syncthing
2021/09/27 09:19:13	upgrade syncthing 1.17.0-22 End /bin/rm -rf /volume1/@appstore/syncthing ret=[0]
2021/09/27 09:19:13	upgrade syncthing 1.17.0-22 Begin /bin/mv -f /volume1/@tmp/pkginstall/extract.dgMWMl/package /volume1/@appstore/syncthing
2021/09/27 09:19:13	upgrade syncthing 1.17.0-22 End /bin/mv -f /volume1/@tmp/pkginstall/extract.dgMWMl/package /volume1/@appstore/syncthing ret=[0]
2021/09/27 09:19:13	upgrade syncthing 1.17.0-22 Begin /bin/rm -rf /var/packages/syncthing
2021/09/27 09:19:14	upgrade syncthing 1.17.0-22 End /bin/rm -rf /var/packages/syncthing ret=[0]
2021/09/27 09:19:14	upgrade syncthing 1.17.0-22 Begin /bin/mkdir -p /var/packages/syncthing
2021/09/27 09:19:14	upgrade syncthing 1.17.0-22 End /bin/mkdir -p /var/packages/syncthing ret=[0]
2021/09/27 09:19:14	upgrade syncthing 1.17.0-22 Begin /bin/touch /var/packages/syncthing/installing
2021/09/27 09:19:14	upgrade syncthing 1.17.0-22 End /bin/touch /var/packages/syncthing/installing ret=[0]
2021/09/27 09:19:14	upgrade syncthing 1.17.0-22 Begin /bin/mv -f /volume1/@tmp/pkginstall/extract.dgMWMl/INFO /var/packages/syncthing/INFO
2021/09/27 09:19:14	upgrade syncthing 1.17.0-22 End /bin/mv -f /volume1/@tmp/pkginstall/extract.dgMWMl/INFO /var/packages/syncthing/INFO ret=[0]
2021/09/27 09:19:14	upgrade syncthing 1.17.0-22 Begin /bin/rm -rf /var/packages/syncthing/scripts
2021/09/27 09:19:14	upgrade syncthing 1.17.0-22 End /bin/rm -rf /var/packages/syncthing/scripts ret=[0]
2021/09/27 09:19:14	upgrade syncthing 1.17.0-22 Begin /bin/mv -f /volume1/@tmp/pkginstall/extract.dgMWMl/scripts /var/packages/syncthing/scripts
2021/09/27 09:19:14	upgrade syncthing 1.17.0-22 End /bin/mv -f /volume1/@tmp/pkginstall/extract.dgMWMl/scripts /var/packages/syncthing/scripts ret=[0]
2021/09/27 09:19:14	upgrade syncthing 1.17.0-22 Begin /bin/rm -rf /var/packages/syncthing/WIZARD_UIFILES
2021/09/27 09:19:14	upgrade syncthing 1.17.0-22 End /bin/rm -rf /var/packages/syncthing/WIZARD_UIFILES ret=[0]
2021/09/27 09:19:14	upgrade syncthing 1.17.0-22 Begin /bin/mv -f /volume1/@tmp/pkginstall/extract.dgMWMl/WIZARD_UIFILES /var/packages/syncthing/WIZARD_UIFILES
2021/09/27 09:19:14	upgrade syncthing 1.17.0-22 End /bin/mv -f /volume1/@tmp/pkginstall/extract.dgMWMl/WIZARD_UIFILES /var/packages/syncthing/WIZARD_UIFILES ret=[0]
2021/09/27 09:19:14	upgrade syncthing 1.17.0-22 Begin /bin/rm -rf /var/packages/syncthing/conf
2021/09/27 09:19:14	upgrade syncthing 1.17.0-22 End /bin/rm -rf /var/packages/syncthing/conf ret=[0]
2021/09/27 09:19:14	upgrade syncthing 1.17.0-22 Begin /bin/mv -f /volume1/@tmp/pkginstall/extract.dgMWMl/conf /var/packages/syncthing/conf
2021/09/27 09:19:14	upgrade syncthing 1.17.0-22 End /bin/mv -f /volume1/@tmp/pkginstall/extract.dgMWMl/conf /var/packages/syncthing/conf ret=[0]
2021/09/27 09:19:16	upgrade syncthing 1.17.0-22 Begin postinst
2021/09/27 09:19:16	===> Step postinst. USER=sc-syncthing GROUP=sc-syncthing SHARE_PATH=
2021/09/27 09:19:16	upgrade syncthing 1.17.0-22 End postinst ret=[0]
2021/09/27 09:19:16	upgrade syncthing 1.17.0-22 Begin postupgrade
2021/09/27 09:19:16	===> Step postupgrade. USER=sc-syncthing GROUP=sc-syncthing SHARE_PATH=
2021/09/27 09:19:16	upgrade syncthing 1.17.0-22 End postupgrade ret=[0]
2021/09/27 09:19:16	upgrade syncthing 1.17.0-22 Begin start-stop-status start
2021/09/27 09:19:16	upgrade syncthing 1.17.0-22 End start-stop-status start ret=[0]

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! :-)

@hgy59
Copy link
Contributor

hgy59 commented Sep 27, 2021

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

  1. backup the package data before the installation of DSM 7
  2. NEVER PRESS REPAIR
  3. ensure a package built for DSM 7 is available
  4. install package built for DSM 7 to upgrade the package

@BenjV
Copy link

BenjV commented Sep 28, 2021

@hgy59
The DSM 7 syncthing package does not copy those files to the new data location, so an upgrade will be the same as a new installation.
Not only the database and config are now gone but also the certificates.

All the files from ${SYNOPKG_PKGDEST}/var should be copied to ${SYNOPKG_TEMP_UPGRADE_FOLDER}
in the pre-upgrade phase
and restored in the post-upgrade phase like:
mv -fv "${SYNOPKG_TEMP_UPGRADE_FOLDER}"/* "${SYNOPKG_PKGVAR}/var"

Maybe this should be added as kind of default action when upgrading from DSM6 to DSM 7?

@th0ma7
Copy link
Contributor

th0ma7 commented Sep 28, 2021

That is rather interesting as currently the code directly copies it over to ${SYNOPKG_PKGVAR} and assumes it will stay permanent. Based on your comment I've applied new changes to the rsync to allow doing exactly that and a little more feae7fe part of PR #4797. That new code is untested yet but give the overall idea.

@BenjV
Copy link

BenjV commented Sep 28, 2021

@th0ma7
DSM 7 has moved the default data folders to @appdata instead of @appstore.

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.
So the configuration data should be saved to a temporary location and must be restored after the installation (and creation of the @appdata/syncthing folder) of the new package (in the post-upgrade 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.
But I cannot keep upgrading from DSM 6 to DSM 7 to test the upgrade process of packages,
So we can only react on feedback of end-users.

@th0ma7
Copy link
Contributor

th0ma7 commented Sep 28, 2021

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.

@hgy59
Copy link
Contributor

hgy59 commented Sep 28, 2021

The DSM 7 syncthing package does not copy those files to the new data location, so an upgrade will be the same as a new installation.

The problem is, when you have a package installed on DSM 6 and upgrade to DSM 7 and then press repair:

  • The installed package knows nothing about DSM 7
  • We don't know what the repair does in this case, but the var folder might be deleted (at least at the second press of 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.

@BenjV
Copy link

BenjV commented Sep 28, 2021

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.

@Moisie2000
Copy link
Author

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.

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! ;-)

@Moisie2000
Copy link
Author

Oh... and a Feature Request if it's possible... :-)

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.

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!)

@BenjV
Copy link

BenjV commented Sep 30, 2021

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.
So save all files in this folder:

/var/packages/syncthing/target/var

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.
If not you can copy the ones you saved yourself.

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.
But moving a big database file does not take must time, that is only changing a pointer in the filesystem.

@hgy59
Copy link
Contributor

hgy59 commented Feb 4, 2022

installer is fixed with #5117. It should now properly migrate from DSM 6 to DSM 7 (but this is hard to verify).

@hgy59 hgy59 closed this as completed Feb 4, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants