Sign in to follow this  
quicksilver

Boot into single user mode on Nanoboot

Recommended Posts

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

Share this post


Link to post
Share on other sites

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 by Guest

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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 /tmproot

mount /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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
Sign in to follow this