Open vmanchot opened 7 years ago
I would say it is a "known issue", I experienced same trouble with owncloud
package uninstall (but only in a VM when testing). Most package delivered are for DSM 5.2 and work is in progress to support DSM 6.x.
In case you are stuck, here are commands to retrieve DSM service:
sh-4.3# synoservice --enable DSM
sh-4.3# synoservice --status DSM
Service [DSM] status=[enable]
required upstart job:
[synoscgi] is start.
=======================================
sh-4.3# synoservice --start DSM
I have exactly the same problem. I uninstall debian chroot, cause I wasnt working on DSM 6.1.x. But after I uninstalled it, I couldnt connect anymore to the web interface.
The above command wont help:
ash-4.3# synoservice --start DSM ash-4.3# synoservice --status DSM service [DSM] status=[error] required upstart job: [synoscgi] is stop.
Anybody an idea what I can do now?
A search lead me to this list of commands: https://diktiosolutions.eu/en/synology/synology-dsm-6-terminal-service-control-en/
I guess you should first invoke restart synoscgi
and try again with synoservice --start DSM
This happened to me today too on DSM6x. Also I didn't know that removing debian would clear out all the contents of my volume1. Is there any way to recover this lost data? I lost around 2TB of work files.
Your data is not lost. You have to plug your hdds on a linux pc/vm and you can access to your data (https://www.synology.com/en-us/knowledgebase/DSM/tutorial/Storage/How_can_I_recover_data_from_my_DiskStation_using_a_PC). Then backup and reinstall your dsm.
Thanks for the reply @vmanchot . I ended up bring the data drives to data recovery center and spending about $1000 CAD to recover my files :( Prior to logging out of the DSM after debian chroot uninstall. File browsing using native DSM software showed empty folder. Removing the drives and running UFS File Recovery and proxying the RAID there were also no files listed in the BRTFS. After getting my drives back today, I tried the same thing again to see what was wrong and my first attempt the same thing happened with a dummy text file in place. I'm assuming with the volume1 RAID array mounted to debian chroot, when uninstalling, it destroys the file tables as well. Perhaps unmounting the drives from debian chroot prior to uninstall would be safer? I'm going to try that next to see if it yields different results.
All SynoCommunity packages have only be delivered and tested for DSM 5.2... and start/stop/install/uninstall scripts are just not supposed to work on DSM 6. "Debian Chroot" is probably the most complex package of them and this package behavior on DSM 6 is just "unpredictable"...
As an advice, to avoid large damages, my DSM is configured with multiple volumes, each dedicated to store different concerns: system and packages, homes, backups, media... if one fails, I do not lose others.
@ymartin59 is version 8.4-7 still affected by this issue?
@ruimarinho Yes, no work has been done on this package for DSM 6
@ymartin59 is there any recommended procedure one can follow to safely remove this package at all? There is no mention that it is only supported on DSM 5 :/
None I am aware of. Effort is pushed on DSM 6 support and this "debian chroot" issue is not a priority. So recommended procedure is to not uninstall it.
I think it's important to bump the priority of this package as my guess is there will be others in the same situation. At the very least, please force the version constraint to be <6. Data loss should be taken very seriously.
Agree with that. As a result, I have removed from package repository and consider it as no longer maintained.
@ymartin59 is there anything we help with?
This package got me as well. After removing it, the interface went dead. I spent some time trying to get it back. Only solution for me was to reset the NAS: reboot it without disks; insert disks after boot and run the DSM installer. None of my data were affected; but all settings, however, have been overwritten (reset). So I guess I learned my lesson and will be reinstalling all user accounts/services. Luckily I have some offsite backups of my important files. (some free advise for you all :) ) I'll be running pihole from a pi in stead of the DS.
Same issue here with Debian Chroot.
Upon further inspection it doesn't seem like the data was deleted.
sh-4.3# df -h Filesystem Size Used Avail Use% Mounted on /dev/md0 2.3G 1.4G 869M 61% / none 990M 0 990M 0% /dev /tmp 994M 856K 993M 1% /tmp /run 994M 3.3M 991M 1% /run /dev/shm 994M 4.0K 994M 1% /dev/shm none 4.0K 0 4.0K 0% /sys/fs/cgroup cgmfs 100K 0 100K 0% /run/cgmanager/fs /dev/sdq1 2.7T 2.0T 797G 72% /volumeUSB1/usbshare
I have 20tb worth of data - no mount is present for the volume. I am going to reinstall DSM and reinsert the disks and hope that the data is still there.
I can confirm the data was NOT deleted. Uninstalling this package will break DSM but will not delete the data on the Volume. Reinstalling DSM on a spare drive and reinserting the drives I was able to recover all of the data. Where is the error in the package? I'll try to provide a fix.
Really no idea, I have not investigated at all. I propose you to review installer script for mount -o bind
and corresponding umount
commands... Probably some are lacking at uninstall and rm
commands drop DSM files.
I had the same problem after uninstalling debian-chroot.
After a quick check I came to the same conclusion, the shared libs were corrupt. Thanks to nighty for providing me this script to check the ELF-signature of the so files.
#!/bin/bash
for filename in /lib/libsyno*.so; do
xxd $filename | head -c 20
printf "(%s)\n" $filename
done
Every file should begin with the following file header: 7f 45 4c 46 -> 0x7F 'E' 'L' 'F' (some files begin with 494e 5055 (/lib/libpanel.so), it works too)
I had to replace the following files: /lib/libsynoshare.so.6 /lib/libsynopkg.so.1 /lib/libsynostoragemgmt.so (yes no symoblic link) Note that you have to replace the correct file, not just the symbolic link.
I downloaded the correct version according to etc/VERSION of the DSM. unzip hda1.tgz opened the hda1 and got to the lib path -> /usr/lib/ After replacing libsynoshare.so.6 and a reboot I had a mounted volumegroup. Replaced /lib/libsynopkg.so.1 & /lib/libsynostoragemgmt.so and after a reboot I had a fully functional DSM.
https://forum.synology.com/enu/viewtopic.php?f=39&t=140831&p=521595
I just lost 15TB of data doing this... Is there any way to bring it back or check?
@mystycs reinstall dsm it will not wipe your data. You can still ssh into the server and try to fix the libs as shown in the post above yours and that may fix it as well. If you need a lib folder off a working DSM let me know. I have done this twice my data and was able to recover each time.
I confirmed that it did. I was able to reinstall it and installed a fresh version of DSM and the data was gone. I also then mounted my drives in Ubuntu and confirmed the same.
On Tue, Oct 9, 2018, 7:11 AM OpenIPC notifications@github.com wrote:
@mystycs https://github.com/mystycs reinstall dsm it will not wipe your data. You can still ssh into the server and try to fix the libs as shown in the post above yours and that may fix it as well. If you need a lib folder off a working DSM let me know. I have done this twice my data and was able to recover each time.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/SynoCommunity/spksrc/issues/2758#issuecomment-428152734, or mute the thread https://github.com/notifications/unsubscribe-auth/AC3YllhHURhZFHmoCzMCVrRqkEH-WjJWks5ujIRmgaJpZM4NVwKh .
I am pretty sure this is because /var/packages/debian-chroot/scripts/start-stop-status status returns the wrong value when it is stopped.
It returns 1, /var/packages/debian-chroot/scripts/start-stop-status:
status)
if daemon_status; then
echo ${DNAME} is running
exit 0
else
echo ${DNAME} is not running
exit 1
fi
;;
If we look at the developer guide, it should return 3 for "package is not running":
!!!. status: When Package Center is opened to check package status, it will send a request to ask the status of the package using this parameter. The following exit status codes should be returned:
0: package is running. 1: program of package is dead and /var/run pid file exists. 2: program of package is dead and /var/lock lock file exists 3: package is not running 4: package status is unknown 150: package is broken and should be reinstalled. Please note, broken status (150) is only supported by DSM 4.2 and later.
https://originhelp.synology.com/developer-guide/synology_package/scripts.html
If you edit /var/packages/debian-chroot/scripts/start-stop-status and change it to 3 debian-chroot can now be started and stopped from the web interface:
status)
if daemon_status; then
echo ${DNAME} is running
exit 0
else
echo ${DNAME} is not running
exit 3
fi
;;
I am not game to try on my own system, but looking at the log @vmanchot posted when he opened this issue I am going to hypothesize that the fact "start-stop-status status" returns 1, which means "program of package is dead and /var/run pid file exists", causes the uninstall to believe that the chroot is not running so does not try to stop debian-chroot before uninstalling, so deletes all debian-chroot files, including, and this is the important bit, anything on any bind mounts that are still mounted (because it has not been stopped).
Unfortunately this information will not help people who have already lost data.
@ymartin59 ^^ Seen this?
I'm scared! ;) I changed the file "var/packages/debian-chroot/scripts/start-stop-status" to return 3 according to the posting of snaunton. Then i tried to stop the debian-chroot via shell, but it returned an error for umounting chroottarget/dev:
sudo /var/packages/debian-chroot/scripts/start-stop-status stop Stopping Debian Chroot ... umount: /volume1/@appstore/debian-chroot/var/chroottarget/dev: target is busy (In some cases useful info about processes that use the device is found by lsof(8) or fuser(1).)
Now i'm scared to proceed further, because im unsure if the uninstall routine will also delete /dev or anything relevant on my Synology. Any way to properly umount that /volume1/@appstore/debian-chroot/var/chroottarget/dev ? can't figure out who is using it anyway.
Part 2...
Ok, to hell with being scared...
I rebooted the Diskstation and was then able to manually umount different stuff, including the /dev part from the shell:
CHROOT=/usr/local/debian-chroot/var/chroottarget umount $CHROOT/dev/pts umount $CHROOT/dev umount $CHROOT/proc umount $CHROOT/sys
So i guessed the debian-chroot package is stopped, the mounts are umounted. Now i dared to uninstall the package... (after a full hyper-backup of the system ;). Till now nothing seems to be a problem, i was able to login to the DSM, even after a restart of the Synology. Debian-Chroot is gone Hope it stays that way
I'm still on DSM 6 with that package that I want to remove before upgrading to DSM 7. Did anyone figure out to properly uninstall without breaking DSM? I see that last message seems to be the right option with editing the script but is it needed to unmount after that shared library? Thanks in advance
For new Package Requests, see the guidelines
Setup
_Package Name: debian chroot _Package Version: 8.4-7
_NAS Model: DS416 _NAS Architecture: armv7l _DSM version: DSM 6.1 15101-1
Expected behavior
I've installed debian chroot from webui (package center), tried to install urbackup in chroot but compilation take too long and I've canceled compilation. I uninstall debian chroot because I finally prefer install urbackup in my x86 server. And then i've lost connection to dsm. Tried to reboot but got the same issue.
Actual behavior
Now I can connect thru ssh but led status still blinking orange and synology webui won't start.
Steps to reproduce
1. install debian chroot _2._apt-get install gcc build-essential curl libcurl-devel 3. urbackup ./compile --> make install --> abort 4. uninstall debian chroot
Package log
root@grognas:~# ls /usr/local/packages/* /usr/local/packages/@appstore: FileStation SynoFinder
/usr/local/packages/@tmp: synopkg.tmp
Other logs
ssh 192.168.9.1 -p 22
Could not chdir to home directory /var/services/homes/manchot: No such file or directory
/var/log/synopkg.log