"File too large" when using standalone kernel

[pixell]

First of all, thanks for everyone who had commented previous topics in this forum. By reading those I was able to boot and log in to my Lacie after it failed to start after firmware upgrade.

However, now I have problems transferring my data from Lacie to USB-drive. Whatever command I try to use to transfer the data, I will receive "File too large" after any file hits 2GB. I found in another topic fvdw saying Busybox should be compiled with "Large File Support" and I even tried static "dd-64" executable fvdw had provided. For some reason "dd-64" fails to run outputting only "Illegal instruction".

Does anyone some tool readily available that allows me to transfer my data?

Thanks.

[rafesl]

ITs been a while since I hit this, but wasn't there some kind of file size limit of 2GB on NTFS or similar previously?

What I'm asking is if the file system on the destination pen drive supports files > 2GB in size?

Rafe

[pixell]

Thanks Rafe for suggestion.

What I'm asking is if the file system on the destination pen drive supports files > 2GB in size?

The USB drive (Seagate 3TB) has a single partition and it's formatted to ext2. So I think it shouldn't be a problem?

[fvdw]

are you sure you used ext2 and not FAT32 ?

and which firmware + kernel are you running ?

I add dd-64 static version once more for you,as we had some problems last year with back up of the forum and some attachments went corrupt.
But if you run lacie firmware with a lacie kernel the problem might be that the Lacie kernel you have installed doesn't support large file.
It might also be the reason why you get the "illegal instruction" message when using dd-64

[pixell]

Thanks fvdw for the reply.

are you sure you used ext2 and not FAT32 ?

When typing "mount" it outputs "/dev/sef1 on /mnt/usb type ext2 (rw, relatime, errors=continue)".

and which firmware + kernel are you running ?

If by firmware you mean the UIMAGE, it's UIMAGE-26394-NWSP2CL-STANDALONE-164.

"uname -a" outputs "Linux (none) 2.6.39.4 #164 PREEMPT Sun Jun 2 20:34:28 GMT+1 2013 armv5tel GNU/Linux".

I add dd-64 static version once more for you,as we had some problems last year with back up of the forum and some attachments went corrupt. But if you run lacie firmware with a lacie kernel the problem might be that the Lacie kernel you have installed doesn't support large file. It might also be the reason why you get the "illegal instruction" message when using dd-64

Thank you, but I still got "Illegal instruction" when executing the one you added. The MD5 for dd-64 I downloaded is 390b73e323401c23a9a832c3c721f548.

[fvdw]

ah I see, you use the standalone kernel, that means you don't run our firmware. But you try to transfer files form a harddisk partition to the usb disk using the standalone kernel
The standalone kernel is compiled with large file support (CONFIG_LBDAF=y)
But when only running the standalone kernel libc is not availalble, is it is not included in the standalone kernel. AFAIK it is needed to get support for files of > 2 GB working. I need to study and see what we can do.

attached a min version of glibc. Upload it using fvdwsl console put the tar archive in the tftp folder of the fvdw-sl console, start the tftp server and when you have the telnet client active when running the standalone kernel upload it to the nas

Code: Select all

tftp -r glibc-2.17-mini.tar -l glibc-2.17-mini.tar -g ip-c

(replace ip-pc by actual ip address of your pc running the fvdw-sl console
after uploading extract the archive on the nas

Code: Select all

tar -xvf  glibc-2.17-mini.tar

Now try again if transport of large files succeed

[pixell]

Thanks for the glibc and sorry for the delays, but I'm been away from the office where Lacie is located.

I had a little time to test. I started the nas using standalone kernel, logged via telnet, uploaded the tarball to root and extracted it. But still commands fail to copy large files. I will go through this again when I have more time if I made mistake etc.

What compiler you're using to compile these for Lacie? Probably arm-gcc, but what version? I'm thinking if I could try to compile necessary tools by myself.

PS the problem could be that the static binaries are compiled against ulibc without using the proper settings for large file support.

[fvdw]

I use my own compiler and compile all the software directly on the NAS.
But there are out there arm cross compile toolchain. Indeed you need an ARM compiler. Be aware that you compile if you use binaires that need glibc that you compile them against the right version of glibc or compile the program static so they do not need any shared library.

I will test the big file transport this evening on a nwsp2 to see if I can reproduce your problem

[fvdw]

indeed the standard static busybox version in the standalone kernel doesn't want to copy large file above 2 GB

Code: Select all

root@(none):/sdb8/public # cp -a dark-night-batman.mpg /sda1/
cp: can't open 'dark-night-batman.mpg': Value too large for defined data type

Attached an updated mini glibc package including a busybox version compiled against glibc-2.17
It has name busybox1, it cannot replace the existing busybox in the filesystem of the standalone kernel because that is active to run the telnet server and so on. If you stop it you loose connection

To use this busbox1 version put busybox1 as prefix before the command you want to use, for example to use cp

Code: Select all

busybox1 cp -a

I tried it and copied a 3 GB file from sda8 to a usb stick without a problem.

Code: Select all

root@(none):/sda1 # ls -l
total 2647688
-r--r--r--    1 1000     1000     2708566016 Oct 19  2009 dark-night-batman.mpg
drwx------    2 root     root         16384 Jan 31 21:30 lost+found
root@(none):/sda1 #


to use put it the tftp folder of the fvw-sl console and use tftp in telnet to upload the tar archive to the nas and unpack it

[pixell]

Thank you fvdw! I can confirm that copying the larger files works now. When it's done, I will try to restore the system according to instructions found in another topic. I will let you know how it went.