When i try to mount a ntfs partition using ntfs-3g i get this cryptic error message:

(doesn't matter whether i'm using mount og ntfs-3g directly)

It doesn't seems to be a problem with fuse, as i can use sshfs just fine.

dmesg doesn't show anything useful other than the fuse version:

i'm using ntfs-3g version 0.20070102-BETA
It's running on a XScale (armv5teb - big endian) based NSLU2 running gentoo linux

uname -a:

I couldn't find anything about known problems with big-endian arm.

On Thu, 11 Jan 2007, poizan42 wrote:


Does it help if you use any option?


sshfs and ntfs-3g use fuse differently, so it's not possible to make such
conclusion.


This seems to be a big-endian arm related fuse problem.

Szaka

nope - i have tried a lot of different combinations of ro, force, streams_interface and the other options

Would some other fuse filesystem using blockdevices be a better test?

Might be - but i can't find the problem described anywhere.
Is there some way i can get ntfs3g or fuse to show more verbose output?

On Thu, 11 Jan 2007, poizan42 wrote:


I don't think so.


Big endian arm worked with fuse 2.5.3. But there was some option parsing
related changes in fuse since then. I should also note that we can't support
this hardware officially since we don't have any physically available for
development. Of course patches are welcome.


No. You should debug this on your hardware. I've also reported this problem
to the FUSE development.

Could you try this patch please:
http://www.ntfs-3g.org/fix-redundant-fuse-arg-init.diff

I'll take a look at it. It takes some time to compile it - and i don't have physical access to the NSLU2 right now, so i can't connect the disk. I'll write back when i have tested it (in 2-3 hours i think).

It doesn't work - and i don't think it should unless there is some bug in gcc.
from src/ntfs-3g.c. FUSE_ARGS_INIT is defined as #define FUSE_ARGS_INIT(argc, argv) { argc, argv, 0 }
so it shouldn't really make any difference to use it twice.

On Thu, 11 Jan 2007, poizan42 wrote:


Yes, I suspected a gcc big-endian arm bug (the related code works on all
other architectures). Often such intuitions work but unfortunately not now.
It's one thing what __should__ work and a totally different one what
__does__ work. This is why we would need the hardware.

You may also try replacing the
fuse_opt_add_arg(&margs, "");
lines to
fuse_opt_add_arg(&margs, "ntfs-3g");

It doesn't seems like the problem is in ntfs-3g (or in the compiler when compiling it).
I added some debug information to ntfs-3g.c and got this output:


the content of margs is from just before the call to fuse_new. So either it somehow isn't passed correctly to fuse_new or the problem happens somewhere inside fuse.

ok it's definitely a gcc bug...

Could you try replacing the
==> fuse_opt_add_arg(&margs, "");
lines to
==> fuse_opt_add_arg(&margs, "ntfs-3g");

Perhaps it will be liked better ...

I solved the problem. After all it wasn't in gcc - it was somewhere in the linking. For some reason it tried to use version 2.2 of the symbols when it was started. I commented the symvers defining the older versions to use the compatibility functions out and everything worked just fine.

Hi,
Actually, I faced up the same problem on MIPS board and I need a help on this issue.
I downloaded fuse 2.6.3 and ntfs-3g-0.20070207-RC1.tgz.
And I cross-compiled them for MIPS board.
However, when I tried to mount, I could see the messages as below.

# ntfs-3g /dev/sda1 /mnt/usb
fuse: unknown option `'
fuse_new failed.
Unmounting /dev/sda1 (DATA)
#

I think this is the same problem in this discussion.
I want to know how you could fix the problem.
Thanks for reading.

Hi. I suggest submitting a bug report to FUSE because it's a FUSE problem.

No i don't think so. The problem happens somewhere in the dynamic linking. Somehow the wrong version of the symbols gets called. Maybe it's a problem with uclibc.

Ok. FUSE plays with symvers too that's why I thought it's a FUSE problem
when you refered to it. But unfortunately I have neither XScale nor MIPS,
so I can't debug the reason but I trust you to find it out

Thanks to all of advices from everyone, I could port te NTFS-3G on MIPS board.
Thank you again.

In order to port it on MIPS board, I had to change the code of fuse and kernel
as follows.

1. In fuse/lib/, comment out all of the lines that includes .symver
(Thank you, poizan42!! ;) )
2. In fuse/kernel/fuse_i.h, enable the line #define DCACHE_BUG
3. In fuse/kernel/dev.c, modify as below.

// Before
#ifdef DCACHE_BUG
flush_cache_page(vma, cs->addr, page_to_pfn(cs->pg));
#endif

// After
#ifdef DCACHE_BUG
r4k_flush_cache_page(vma, cs->addr, page_to_pfn(cs->pg));
#endif


4. Modify the kernel source in linux/arch/mips/mm/c-r4k.c
// Before
static void r4k_flush_cache_page(struct vm_area_struct *vma, unsigned long page, unsigned long pfn)
{
...
}

// After
void r4k_flush_cache_page(struct vm_area_struct *vma, unsigned long page, unsigned long pfn)
{
...
}
EXPORT_SYMBOL(r4k_flush_cache_page);


Then I cross-compiled all the sources and kernel, and tested again.
It works good. ;)

Thank you.

Thank you for the good news hebb!

Hi,
could you please explain this a bit more for non-developers? I'm also using uClibc and I'm getting the same error message.
Thanks

Hi,

Actually you can reproduce the problem on an x86 platform by using uclibc.
I'm using the following:
kernel version: gentoo-sources-2.6.22-r5 (with fuse build in - _not_ a module)
uclibc version: 0.9.28(.3 - gentoo sub-version)
fuse version: 2.7.0
ntfs3g version: 1.913

I have created an ntfs partition with mkfs.ntfs (ntfsprogs)
and have tried to mount it this way:

For now, I will start compiling ntfs3g in debug mode to find out the problem on my own but if anyone as a clue about it, posting will be a great help.

Thanks for reading.

I just also tried with fuse as a module built from the fuse-2.7.0 package (and not from the kernel sources). I got the same error.

This is a patch that I have created, it disable symvers for version 2.2. This have solve my problem fuse with uclibc, Hope that this will help you.



diff -urp fuse-2.7.0-orig/lib/fuse.c fuse-2.7.0/lib/fuse.c
--- fuse-2.7.0-orig/lib/fuse.c 2007-07-02 14:33:08.000000000 +0300
+++ fuse-2.7.0/lib/fuse.c 2007-08-22 19:31:39.000000000 +0300
@@ -3294,7 +3294,7 @@ __asm__(".symver fuse_process_cmd,__fuse
__asm__(".symver fuse_read_cmd,__fuse_read_cmd@");
__asm__(".symver fuse_set_getcontext_func,__fuse_set_getcontext_func@");
__asm__(".symver fuse_new_compat2,fuse_new@");
-__asm__(".symver fuse_new_compat22,fuse_new@FUSE_2.2");
+//__asm__(".symver fuse_new_compat22,fuse_new@FUSE_2.2");

#endif /* __FreeBSD__ */

diff -urp fuse-2.7.0-orig/lib/helper.c fuse-2.7.0/lib/helper.c
--- fuse-2.7.0-orig/lib/helper.c 2007-07-02 14:32:17.000000000 +0300
+++ fuse-2.7.0/lib/helper.c 2007-08-22 19:32:40.000000000 +0300
@@ -391,10 +391,10 @@ int fuse_mount_compat1(const char *mount
}

__asm__(".symver fuse_setup_compat2,__fuse_setup@");
-__asm__(".symver fuse_setup_compat22,fuse_setup@FUSE_2.2");
+//__asm__(".symver fuse_setup_compat22,fuse_setup@FUSE_2.2");
__asm__(".symver fuse_teardown,__fuse_teardown@");
__asm__(".symver fuse_main_compat2,fuse_main@");
-__asm__(".symver fuse_main_real_compat22,fuse_main_real@FUSE_2.2");
+//__asm__(".symver fuse_main_real_compat22,fuse_main_real@FUSE_2.2");

#endif /* __FreeBSD__ */

@@ -428,6 +428,6 @@ int fuse_mount_compat25(const char *moun
}

__asm__(".symver fuse_setup_compat25,fuse_setup@FUSE_2.5");
-__asm__(".symver fuse_teardown_compat22,fuse_teardown@FUSE_2.2");
+//__asm__(".symver fuse_teardown_compat22,fuse_teardown@FUSE_2.2");
__asm__(".symver fuse_main_real_compat25,fuse_main_real@FUSE_2.5");
__asm__(".symver fuse_mount_compat25,fuse_mount@FUSE_2.5");
diff -urp fuse-2.7.0-orig/lib/mount_bsd.c fuse-2.7.0/lib/mount_bsd.c
--- fuse-2.7.0-orig/lib/mount_bsd.c 2006-05-03 17:46:04.000000000 +0300
+++ fuse-2.7.0/lib/mount_bsd.c 2007-08-22 19:31:55.000000000 +0300
@@ -360,4 +360,4 @@ int fuse_kern_mount(const char *mountpoi
return res;
}

-__asm__(".symver fuse_unmount_compat22,fuse_unmount@FUSE_2.2");
+//__asm__(".symver fuse_unmount_compat22,fuse_unmount@FUSE_2.2");
diff -urp fuse-2.7.0-orig/lib/mount.c fuse-2.7.0/lib/mount.c
--- fuse-2.7.0-orig/lib/mount.c 2007-07-02 14:32:17.000000000 +0300
+++ fuse-2.7.0/lib/mount.c 2007-08-22 19:31:19.000000000 +0300
@@ -579,5 +579,5 @@ int fuse_kern_mount(const char *mountpoi
return res;
}

-__asm__(".symver fuse_mount_compat22,fuse_mount@FUSE_2.2");
-__asm__(".symver fuse_unmount_compat22,fuse_unmount@FUSE_2.2");
+//__asm__(".symver fuse_mount_compat22,fuse_mount@FUSE_2.2");
+//__asm__(".symver fuse_unmount_compat22,fuse_unmount@FUSE_2.2");

Thanks ! This helps a lot :)

I'm not familiar with the .symver directive.
Is this problem fuse or uclibc related ?

I guess fuse is not the only library using .symver directive so why is this problem occuring with fuse in particular ?

Anyway thanks again,

Thibault.

Thank you very much.
I used these above methods to port ntfs-3g my MIPS board successfully.
My System Info is showed below:
1、fuse 2.7.3
2、ntfs-3g 1.5130
3、mips Board
4、kernel: Linux 2.6.18
5、uclibc：3.4.5
mips-linux-uclibc-gcc (GCC) 3.4.5
6、busybox：BusyBox v1.4.2 (2008-07-25 08:36:45 CST) Built-in shell (ash)

But I don't see the chinese file and chinese catalogue while i mount successfully the NTFS volume, and I don't know how to support the GB2312 character set.
Please give some little advice , and i will be appreciated.