quicksilver Posted February 17, 2015 #1 Posted February 17, 2015 Hello, Something has happened to by NanoBoot diskstation while replacing a bad disk. I'm getting a message saying: Partition layout is not Diskstation style and sed: couldn't flush /tmpRoot/etc/....: No space left on device ... I get a login prompt and the webgui seems to be there but it will not accept my login. Does anyone here know how to boot DSM/NanoBoot into single user mode so that I can check /root. Thanks
quicksilver Posted February 17, 2015 Author #2 Posted February 17, 2015 (edited) well... I've managed to get into the volumes by booting to a Ubuntu Live CD, opening a terminal and issuing the following commands: sudo -i apt-get install mdadm lvm2 mdadm –Asf && vgchange -ay or mdadm --assemble --scan Note: specify 'no configuration' for postfix, which seems to be a dependency for mdadm. I can now see my main volume so at the very least I can recover, but this does not get me into the root partition, which is what is full... Perhaps this will prove useful to anyone who needs to access their Synology data from another system but it get me any closer to recovering... Perhaps someone here will know how to get into root. Edited February 18, 2015 by Guest
Diverge Posted February 18, 2015 #3 Posted February 18, 2015 Hook a monitor to your box, or check the console if you're using VM's. There's also SSH, if you enabled it, and telnet (which I think is enabled by default). user: root password: your_admin_password I think I recall reading about this issue in the past, and pretty sure it's fixable. You should be able to search for it. Here's one thread about it: http://forum.synology.com/enu/viewtopic ... 19&t=77121
quicksilver Posted February 18, 2015 Author #4 Posted February 18, 2015 I found another guide here that was somewhat helpful: http://phenomenology/forum/viewtopic.ph ... 262#p32262 I've now tried SystemRescueCD. It also allows me to get to /volume1 but not root. SystemRescueCD puts volume1 in /dev/dm-0 so: mkdir /v1_recovery mount /dev/dm-0 /v1_recovery or.. mount /dev/mapper/vg1000-lv /v1_recovery Provides access to the Synology volume in /v1_recovery Pretty cool actually an makes it really easy to pull the data out. I've also tried: mkdir /tmprootmount /dev/md0 /temproot ls /temproot As suggested in the other post but when I try to mount /dev/md0 I get: mount: /dev/md0: can't read superblock I would really love to repair root. trying to find out why it can not read the superblock now. Any/all suggestions welcome. I've also been considering an upgrade to XPEnoboot anyway. Is a reinstall safe with DSM in semi-broken state?
quicksilver Posted February 18, 2015 Author #5 Posted February 18, 2015 Hook a monitor to your box, or check the console if you're using VM's. There's also SSH, if you enabled it, and telnet (which I think is enabled by default). I think I recall reading about this issue in the past, and pretty sure it's fixable. You should be able to search for it. Here's one thread about it: http://forum.synology.com/enu/viewtopic ... 19&t=77121 Hi Diverge, Thanks for the response. Neither telnet nor ssh, nor the console will let me in using root, admin or any other username/password combination. All were working but now everything says access denied. I'm checking out the Synology post now.
quicksilver Posted February 18, 2015 Author #6 Posted February 18, 2015 It's an interesting post but does not say what do do if I cannot get myself logged in. It does say: In that case you have 2 possibilities: login to the command line interface (telnet/SSH) as root, locate and delete the files that are using too much space and try again.Or you reset your DS and reinstall the DSM. This procedure is designed not to touch your data partition, but should clear the system partition. I think that I'll try a reinstall
Diverge Posted February 18, 2015 #7 Posted February 18, 2015 I'm pretty positive the problem is from log files filling up the DSM partition. I know older gnoboots had this issue, because there were logs of debug errors. I think eventually gnoboot changed it so the errors aren't written to disk, and just ignored. Are you using an old boot image? Also, the DSM is mirrored to the first partition of every disk... So if you manually try to fix on other Linux OS, you may need to do each disks partition. I'm not 100% positive though. Best bet is try to get access using DSM via terminal. Sent from my Nexus 6 using Tapatalk
quicksilver Posted February 18, 2015 Author #8 Posted February 18, 2015 I completely agree. It's got to be the logs and they likely filled up while the rebuild was occurring. I wish that I had checked /root and /logs before attempting a reboot. At least I WAS logged in. Live and learn. I'm using Nanoboot with DSM 5. I think that it's the latest one before everything changed to XPEnoboot. I'm now extracting files that will be difficult to replace from the Array using an Ubuntu CD and mdadm. Currently it says 13 hours to go... if I have not figured out how to get logged back in to clear /logs by then I'll try a reinstall. That should clear out the logs. I suspect that the login problem is due to the system trying to log my login and failing so it's all a bit of a catch 22. If I could get to a single user instance of DSM it would be easy but I've tried adjusting the kernel line in grub but whatever I changed it to I only ever got a login prompt. Thanks again for the responses.
quicksilver Posted February 19, 2015 Author #9 Posted February 19, 2015 crap... migration will not run... back to trying to get into the logs or backing everything up and installing a fresh system.
Recommended Posts