[yocto] Errors building with Windows Subsystem for Linux (aka Bash on Ubuntu on Windows)

Bryan Evenson bevenson at melinkcorp.com
Wed Sep 27 05:57:05 PDT 2017


Ross,

From: Burton, Ross [mailto:ross.burton at intel.com]
Sent: Tuesday, September 26, 2017 6:15 PM
To: Bryan Evenson <bevenson at melinkcorp.com>
Cc: yocto at yoctoproject.org
Subject: Re: [yocto] Errors building with Windows Subsystem for Linux (aka Bash on Ubuntu on Windows)

On 26 September 2017 at 22:01, Bryan Evenson <bevenson at melinkcorp.com<mailto:bevenson at melinkcorp.com>> wrote:
Now this *is* interesting.  Try removing the repeated slashes just in case the WSL ln is being incredibly pedantic (ie sstate-build-package//packages-split), but I don't seriously expect that to be the problem.  Running stat on the source and verifying the destination doesn't exist would be helpful.  Can you tell if that is the first ln that it is trying to do, or do many work and that one fails?  Does WSL have a working strace or similar to identify which exact syscall is failing?

I am about 60% through the full image build when it gets to glibc-locale with about half of the packages for the image fully complete.  I did a stat on one of the source files and verified it did exist, and it had 0644 for access rights and is owned by me.  I also verified that the destination file doesn’t exist.  WSL does have a working strace.  I ran strace on the failed cp command shown above and I now have a 56MB strace output file.  What should I be looking for in this file?

Feel free to compress and email it directly to me, but simply grepping for EINVAL (invalid argument error) might be enough.

I did a search on EINVAL and I got a bunch of entries of that look like this:

  linkat(AT_FDCWD, “<source_full_path>”, AT_FDCWD, “<dest_full_path>”, 0) = -1 EINVAL (Invalid argument)

I checked a few entries by doing a stat on the source and destination.  In each case, the source file exists at the specified path, was owned by the user account with which I’m doing the build, and had access rights of 0644.  Also in each case, the destination file did not exist but the destination directory did exist, the destination directory was owned by the user account with which I’m doing the build, and the destination directory had access rights of 0755.  From reading the man page for linkat, linkat should only return EINVAL if the flags argument is invalid, and 0 should be a valid value for flags.

I think there may be something missing from WSL’s implementation of linkat.  I am doing OPKG packages, so I’m guessing there is something different about the resulting function calls in the libc-package class as opposed to the package_ipk class.  I think I may enable the other package types to see if it is as successfully with RPMs and DEB packages.  I’m also going to see if there is an easier way to reproduce the problem to report the issue to Microsoft.

Bryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20170927/3b9a434c/attachment.html>


More information about the yocto mailing list