This is because uml doesn't have the attr syscalls mapped
kernel/sys_call_table.c
[ __NR_setxattr ] = sys_ni_syscall,
[ __NR_lsetxattr ] = sys_ni_syscall,
[ __NR_fsetxattr ] = sys_ni_syscall,
[ __NR_getxattr ] = sys_ni_syscall,
[ __NR_lgetxattr ] = sys_ni_syscall,
[ __NR_fgetxattr ] = sys_ni_syscall,
[ __NR_listxattr ] = sys_ni_syscall,
[ __NR_llistxattr ] = sys_ni_syscall,
[ __NR_flistxattr ] = sys_ni_syscall,
[ __NR_removexattr ] = sys_ni_syscall,
[ __NR_lremovexattr ] = sys_ni_syscall,
[ __NR_fremovexattr ] = sys_ni_syscall,
You'll need to correct this table before it will work.
On Tue, 2003-03-25 at 18:00, Derek Glidden wrote:
> Does anyone know of a specific problem with XFS, extended attributes and
> UML (user-mode linux)?
>
> We've got a 2.4.19 kernel with XFS 1.2 and UML 2.4.19-51 patches applied
> that, when we try to run "attr" to add/set extended attributes to a file
> under the UML, returns:
>
> attr_set: Function not implemented
>
> if we 'strace' the 'attr' action, we see:
>
> SYS_227(0xbffffea1, 0xbffffbb4, 0xbffffe98, 0x8, 0) = -1 ENOSYS
> (Function not implemented)
>
> The exact same kernel source, compiled and running "native" works
> as-expected.
>
> Any ideas? Is this a known problem? Is there anyone else out there
> crazy enough to be using XFS under User-mode Linux? :)
>
> (And yes, we know that running a journaling filesystem under UML isn't
> entirely the best idea, but we have an application that wants XFS
> extended attributes that we want to run under UML if at all possible.)
|