adding ssh to standalone firmware instance

[Jocko]

Currently, you have only one solution repair xfs.

Note: you should read this topic about xfs_repair which requires more ressource to run:
http://plugout.net/viewtopic.php?f=26&t=2247&p=19210&hilit=console+swap#p19210

[AlexStanica]

Hi again Jocko and many thanks for your work! I was able to repair and mount my array using the thread you gave.

A very weird thing: I first ran xfs_repair -n (to prevent any damage to the disks) and after tried to mount my array. AND IT WORKED.
I rebooted and again I could not mount it. xfs_repair -n was not enough the second time so I used the usb stick to extend the swap and run xfs_repair -L
It got stuck at some point so I opened another telent window, hit a dmesg and a poweroff -f. Rebooted again and was able to mount and see my files.

So I inserted a 2Tb disk from my other 5big (that has fvdw-sl) and began copying files.
Anything below 4Gb was copied fine, for anything else I get:

# cp -a /mountpoint/shares/2/\(1\)\ SAMSUNG\ HD103SI1AG01118\ -S1VSJD2Z907470.dsk /mountpoint2
/Vol-B/
cp: can't open '/mountpoint/shares/2/(1) SAMSUNG HD103SI1AG01118 -S1VSJD2Z907470.dsk': File too large

I have 5 of these, 1Tb disk images. How can I copy them?

# mount
rootfs on / type rootfs (rw,size=255008k,nr_inodes=63752)
none on /proc type proc (rw,relatime)
none on /sys type sysfs (rw,relatime)
none on /dev/pts type devpts (rw,relatime,mode=600)
/dev/sdd8 on /mountpoint2 type ext3 (rw,relatime,errors=continue,user_xattr,acl,barrier=1,data=ordered)
/dev/md4 on /mountpoint type xfs (ro,relatime,attr2,inode64,sunit=1024,swidth=4096,noquota)

both ext3 and xfs should support at least 16Gb files.

Is it possible cp was not compiled with large file support (I read that somewhere...)?
Is there any rsync compiled for 5Big v2 that I may have? Since some of the files where not copied I hope I could use rsync to just sync the folders instead of copying everything again.

Many thanks!

[fvdw]

I think we have seen this problem already before.
The version in the firmware is a sym link to busybox. Although busybox has been compiled with large file support it seems that some applets have problems with them
The reason why we use busybox is size. if we would include all full versions the firmware image would become large

Attached a cp version form core-utilities.
You could try it to see if it solves your problem, but it could be that this code is also limited. You can rename the sym link cp in /bin folder and put this binary inside of course setting executable permissions. I assume you know how to do that

[AlexStanica]

Thank you fvdw. You guys are doing an amazing job here!
I will test this tomorrow. Meanwhile, since this thread is called "adding ssh to standalone firmware instance", is there any compiled ssh that I can run (and maybe other people looking for it, as I haven't much use for it right now).

[AlexStanica]

double post - ignore this

[fvdw]

why would you need ssh in the standalone kernel ? telnet is easier and more speedy and has provide also the linux command prompt, what more would you need ?


ssh is more suitable for running systems

[Mijzelf]

For normal use ssh is not slower than telnet. And it has a few big advantages. For the stand-alone kernel the biggest one is the possibility to pipe files through ssh. For instance, copying the contents of a directory:

Code: Select all

ssh root@nas "tar cf - /path/to/directory/*" > directory.tar

The other way is also possible.

Dropbear is a very small ssh server.

[AlexStanica]

Yes, Mijzelf, that was exactly what I had in mind.
My setup consists of 2 Lacie 5big, and I wanted to copy all contents of the broken one (official firmware, crashed, RAID5, all disk used, bootable via the console) to the functioning one (fvdw firmware, JBOD). Tftp was slow, so I searched online and decided I would go for tar via ssh, but since I had not ssh in the standalone kernel I created this thread.

Jocko and fvdw gave me a better solution: to connect a USB on which to copy data (I don't have a large enough external USB hdd for this) OR since one of my RAID5 was marked as faulty/absent use that available slot for disks from the functioning Lacie, which I did.

The cp provided by fvdw functions perfectly and I can copy files as large as 1Tb. Many thanks!

Just for the sake of it, how would I use dropbear to get ssh in the standalone kernel?

[Mijzelf]

In case of copying much data between 2 boxes, you can also use netcat (nc), which might be available as busybox applet. Nowadays ssh by default doesn't permit unencrypted connections anymore, which gives a serious hit on the achieved throughput.

At the receiving side:

Code: Select all

cd /path/to/directory
nc -l 9999 | tar xf -

at the sending side:

Code: Select all

cd /path/to/directory
tar cf - * | nc ip-of-other-box 9999

(BTW, if busybox cp has problems with big files, maybe busybox tar has also. Netcat won't be a problem, I think, as it only passes a stream)

Just for the sake of it, how would I use dropbear to get ssh in the standalone kernel?

I don't understand the question. Dropbear *is* an ssh server.

[Mijzelf]

In case of copying much data between 2 boxes, you can also use netcat (nc), which might be available as busybox applet. Nowadays ssh by default doesn't permit unencrypted connections anymore, which gives a serious hit on the achieved throughput.

At the receiving side:

Code: Select all

cd /path/to/directory
nc -l 9999 | tar xf -

at the sending side:

Code: Select all

cd /path/to/directory
tar cf - * | nc ip-of-other-box 9999

(BTW, if busybox cp has problems with big files, maybe busybox tar has also. Netcat won't be a problem, I think, as it only passes a stream)

Just for the sake of it, how would I use dropbear to get ssh in the standalone kernel?

I don't understand the question. Dropbear *is* an ssh server.