Hi,
I am following up on threads started here [1] and here [2]. I'm not
subscribed to qemu-devel so please dont forget to CC me.
About a year ago, Kenneth Johansson reported [1], that trying to do a
debian debootstrap using qemu user emulation will fail due to the
following error:
/bin/tar: ./postinst: Cannot utime: Level 2 not synchronized
Lisandro had a very similar issue [2]:
/usr/bin/touch: setting times of `tito': Level 2 not synchronized
Since I was also interested in bootstrapping debian using qemu user mode
emulation at some point I tracked down the error to the usage of
utimensat which results in a ENOSYS error (being translated to
EL2NSYNC).
Here is a quick and dirty C snippet that allows to reproduce the issue:
-%<-----------------------------------------
#include <stdio.h>
#include <sys/stat.h>
#include <fcntl.h>
int main()
{
int ret, fd, dir;
dir = open(".", O_RDONLY);
fd = open("./foobar", O_WRONLY|O_CREAT, 0666);
ret = utimensat(dir, "./foobar", NULL, 0);
perror("utimensat");
return 0;
}
----------------------------------------->%-
To see how different architectures behave when executing this, I
compiled it natively and crosscompiled it for arm and mips. I statically
compiled it to avoid shared library troubles. Because of binfmt support
I do not prepend qemu-mips or qemu-arm in the following.
$ gcc -Wall -static utimensat.c
$ file a.out
a.out: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically
linked, for GNU/Linux 2.6.18, not stripped
$ ./a.out
utimensat: Success
$ arm-linux-gnueabi-gcc -Wall -static utimensat.c
$ file a.out
a.out: ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, for
GNU/Linux 2.6.18, not stripped
$ ./a.out
utimensat: Success
$ mips-linux-gnu-gcc -Wall -static utimensat.c
$ file a.out
a.out: ELF 32-bit MSB executable, MIPS, MIPS-I version 1 (SYSV), statically
linked, for GNU/Linux 2.6.18, with unknown capability 0x41000000 = 0xf676e75,
with unknown capability 0x10000 = 0x70401, not stripped
$ ./a.out
utimensat: Level 2 not synchronized
$ mipsel-linux-gnu-gcc -Wall -static utimensat.c
$ file a.out
a.out: ELF 32-bit LSB executable, MIPS, MIPS-I version 1 (SYSV), statically
linked, for GNU/Linux 2.6.18, with unknown capability 0xf41 = 0x756e6700, with
unknown capability 0x70100 = 0x1040000, not stripped
$ ./a.out
utimensat: Level 2 not synchronized
As one can see the error only shows on mips. It also occurs when
natively compiling above snippet on mips and it also occurs when using a
natively compiled `touch` binary for mips from the debian coreutils
package.
Now my questions are:
* why is this happening with mips?
* Whose fault is it?
* is it a qemu bug?
* should I open a bugreport about this issue?
* why was nobody else complaining about it, given that this is an issue
for over a year now?
thank you
cheers, josch
[1] http://lists.gnu.org/archive/html/qemu-devel/2010-05/msg00116.html
[2] http://lists.gnu.org/archive/html/qemu-devel/2011-07/msg00102.html
