4403 2013-04-23 12:42:59 +0000 stap fails on core-image-sato x86-64 2017-06-13 11:15:51 +0000 1 1 7 Build System, Metadata & Runtime Meta-yocto meta-yocto 1.4 x86 Multiple RESOLVED WONTFIX Low normal Future 1 alexandru.c.georgescu tom.zanussi bogdan.a.marinescu ioanax.grigoropol poky.bs.watcher poky.watcher richard.purdie sgw --- --- Don't know oldest_to_newest 32526 0 alexandru.c.georgescu 2013-04-23 12:42:59 +0000 poky 789b2b7e0cca404ff8ba8ed5ba823d215e6ba5b4 HOST: Fedora 18 64bit STEPS TO REPRODUCE: 1. Build a core-image-sato qemux86-64 with stap support (add tools-profile to EXTRA_IMAGE_FEATURES) 2. Launch the qemu image 3. I have the following error in qemux86-64 core-image-sato when using stap: root@qemux86-64:~# stap trace.stp Checking "/lib/modules/3.8.4-yocto-standard/build/.config" failed with error: No such file or directory root@qemux86-64:~# Trace file: root@qemux86-64:~# cat trace.stp probe syscall.open { printf ("%s(%d) open (%s)\n", execname(), pid(), argstr) } probe timer.ms(4000) # after 4 seconds { exit () } root@qemux86-64:~# 5. When using crosstap from the host, I have the following: [yocto@localhost build]$ crosstap root@192.168.7.4 trace.stp /mnt/ssd/0418-1/poky/build /mnt/ssd/0418-1/poky/build /mnt/ssd/0418-1/poky/build root@192.168.7.4's password: [yocto@localhost build]$ 32559 1 tom.zanussi 2013-04-23 22:05:30 +0000 OK, the first thing is that invoking a script in the target isn't a supported use-case - only from the host. Invoking a .stp script directly on the target requires the ability to compile a kernel module on the target, and hasn't been tested under those conditions. The only supported mechanism is via 'crosstap', and I don't see any indication in the output that it failed - just no output, which is very possible if no files were opened on the target. Try opening some files on the host and see if there's still no output. 32580 2 ioanax.grigoropol 2013-04-24 13:19:34 +0000 Hi Tom, The error message Alex received is reproducible by running the crosstap script on a qemu machine that has a different architecture than specified in conf/local.conf. I have two macines: arm and x86_64, and conf/local.conf MACHINE points to qemuarm. When running crosstap script for the arm machine, the output is: ~/git-repos/poky/build [master] $ crosstap root@192.168.7.2 ../test.stp ~/git-repos/poky/build ~/git-repos/poky/build ~/git-repos/poky/build syslogd(391) open ("/var/log/messages", O_WRONLY|O_APPEND|O_CREAT|O_LARGEFILE|O_NOCTTY|O_NONBLOCK, 0666) If I run the script for qemux86-64(without changing the config), the output is: ~/git-repos/poky/build [master] $ crosstap root@192.168.7.4 ../test.stp ~/git-repos/poky/build ~/git-repos/poky/build ~/git-repos/poky/build Checking "/lib/modules/3.8.4-yocto-standard/build/.config" failed with error: No such file or directory After changing to qemux84-64, everything works fine: ~/git-repos/poky/build [master] $ vim conf/local.conf ~/git-repos/poky/build [master] $ crosstap root@192.168.7.4 ../test.stp ~/git-repos/poky/build ~/git-repos/poky/build ~/git-repos/poky/build dmesg(628) open ("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC|O_LARGEFILE|O_CLOEXEC) dmesg(628) open ("/lib/tls/x86_64/libc.so.6", O_RDONLY|O_CLOEXEC|O_LARGEFILE|O_CLOEXEC) dmesg(628) open ("/lib/tls/libc.so.6", O_RDONLY|O_CLOEXEC|O_LARGEFILE|O_CLOEXEC) dmesg(628) open ("/lib/x86_64/libc.so.6", O_RDONLY|O_CLOEXEC|O_LARGEFILE|O_CLOEXEC) dmesg(628) open ("/lib/libc.so.6", O_RDONLY|O_CLOEXEC|O_LARGEFILE|O_CLOEXEC) ~/git-repos/poky/build [master] $ Couldn't the architecture be determined using the ip from the script instead of the local.conf ? Something like "ssh root@IP uname -m" ? Thanks, Ioana 32581 3 tom.zanussi 2013-04-24 13:43:21 +0000 Yeah, the problem in this case is that crosstap uses bitbake to get a number of variables that it uses in the script: BITBAKE_VARS=`bitbake -e virtual/kernel` So having MACHINE pointing to something different will cause it to used the wrong values. At minimum, this should be documented, and probably the script can detect this and print out a message to that effect. We could also provide a way to override the settings it gets from the wrong machine, as you suggest. I'm not sure at this point about the best way to fix it robustly, but in any case it's easily worked around, and in fact not a common thing that people run into - hadn't seen it until now. 74062 4 richard.purdie 2017-06-13 11:15:51 +0000 This appears to be user error in setting an incorrect MACHINE. In an ideal world we'd check the MACHINE setting matched the target but I'm not sure how we'd do that. This doesn't stand much chance of being implemented as we're not actively working on crosstap so resolving as user error when testing.