`yarn install` fails inside /mnt with EINVAL for lstat during step 3

[khuongduybui]

• Your Windows build number: Version 10.0.16273.1000

• What you're doing and what's happening: (Copy&paste specific commands and their output, or include screen shots)

Running yarn (install) in a directory inside /mnt/c/Users/foo/bar

$ pwd
/mnt/c/Users/duybui/code/web/old
$ yarn
yarn install v0.27.5
warning package.json: No license field
info No lockfile found.
warning aurelia-web@1.0.0: No license field
[1/4] Resolving packages...
warning aurelia-cli > npm > request > node-uuid@1.4.8: Use uuid module instead
warning browser-sync > browser-sync-ui > weinre > express@2.5.11: express 2.x series is deprecated
warning browser-sync > browser-sync-ui > weinre > express > connect@1.9.2: connect 1.x series is deprecated
[2/4] Fetching packages...
warning fsevents@1.1.2: The platform "linux" is incompatible with this module.
info "fsevents@1.1.2" is an optional dependency and failed compatibility check. Excluding it from installation.
[3/4] Linking dependencies...
warning "muicss@0.9.22" has unmet peer dependency "react@^0.14.0 || ^15.0.0".
error An unexpected error occurred: "EINVAL: invalid argument, lstat '/mnt/c/Users/duybui/code/web/old/node_modules/accord/node_modules/cliui/README.md'".
info If you think this is a bug, please open a bug report with the information provided in "/mnt/c/Users/duybui/code/web/old/yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.

• What's wrong / what should be happening instead: Note that every time I run the command it may fail while lstat'ing a different file.

[khuongduybui]

My current workaround is to create a node_modules directory outside /mnt, then ln -s it into my directory inside /mnt.

[umamialex]

Related issue in the Yarn repo: yarnpkg/yarn#4188

[hikurangi]

Also getting this when adding a dependency from the command line. I can install packages successfully using npm, so am I correct in thinking that this is a Yarn issue, not a WSL one?

I'm on 16281.rs3 fwiw.

[khuongduybui]

It's a WSL issue with the recent file system later changes

[tjmonsi]

It fails on the new build of windows. I reverted back to 16251.rs3 and yarn works fine again

[sunilmut]

Adding @SvenGroot who is taking a look at this. Also, marking it as a bug.

[treebeard]

Also fails on 16278.rs3, npm works fine

[simonbuchan]

This looks like it's the same error in React Native's packager (roughly equivalent to webpack --watch):

✘130 ➜ yarn start
yarn start v1.0.1
$ node node_modules/react-native/local-cli/cli.js start
Scanning 723 folders for symlinks in /mnt/c/code/learning-hub/mobile-app/node_modules (80ms)
 ┌────────────────────────────────────────────────────────────────────────────┐
 │  Running packager on port 8081.                                            │
 │                                                                            │
 │  Keep this packager running while developing on any JS projects. Feel      │
 │  free to close this tab and run your own packager instance if you          │
 │  prefer.                                                                   │
 │                                                                            │
 │  https://github.com/facebook/react-native                                  │
 │                                                                            │
 └────────────────────────────────────────────────────────────────────────────┘
Looking for JS files in
   /mnt/c/code/learning-hub/mobile-app

Loading dependency graph...
React packager ready.

Loading dependency graph, done.
Bundling `index.android.js`
  Transforming modules  100.0% (913/913), done.
 ERROR  EINVAL: invalid argument, lstat '/mnt/c/code/learning-hub/mobile-app/.git/index.lock'
{"errno":-22,"code":"EINVAL","syscall":"lstat","path":"/mnt/c/code/learning-hub/mobile-app/.git/index.lock"}
Error: EINVAL: invalid argument, lstat '/mnt/c/code/learning-hub/mobile-app/.git/index.lock'
    at Error (native)

See http://facebook.github.io/react-native/docs/troubleshooting.html
for common problems and solutions.
error Command failed with exit code 11.

This one is pretty intermittent though.

[sunilmut]

We have been trying to get to the bottom of this issue, but the bug seems very evasive. Every time we try to gather an strace or put it under the debugger, it does not repro. Seems like some kind of race condition. If someone is able to get a strace of the failing command, that might shed some light. strace -o <trace_file> -ff <failing_cmd>

[AndyGauge]

I attempted to create a react app using yarn create-react-app hello-api and ran it through the strace recommended. I zipped up the output.

https://github.com/AndyGauge/yarn-debug/blob/master/yarn-fail.zip

[khuongduybui]

When I run strace -o ~/trace.log yarn install the error does NOT show up. When I run strace -o /dev/null yarn install the error DOES show up.

[AndyGauge]

rails webpack:install fails with the same message. The trace.log file: https://github.com/AndyGauge/yarn-debug/blob/master/trace.log

[CrshOverride]

I was able to reproduce locally. You can download a zip of all of the trace files at https://www.dropbox.com/s/oy78n0qvtqqyxwb/yarn_trace.zip?dl=0

[hikurangi]

If it helps, for me the problem seems to be resolved in 16288.1.

[khuongduybui]

No the original issue has absolutely NOT been resolved in latest insider (non skip-ahead) build.

[wycats]

I was able to reproduce this issue with strace on.

trace.zip

[SvenGroot]

Thanks for all the input. We've been able to determine the root cause of this issue and are working on a fix.

[khuongduybui]

You made my (our) day! Keep up the good work.

[Warblefly]

The news of the cause being determined is very, very welcome. I shall be glad to test it. Maybe the fix is in build 16296, which just landed here?

[AndyGauge]

I was upgraded to 16296 yesterday and still had to work around the issue by moving across file systems to run yarn add I'm sure it still affects yarn install.

[SvenGroot]

We're still working on the fix, so it's not available yet. I'll update this thread once the fix becomes available.

[jingsam]

This issue has annoyed me for a month, expecting fix it in the next release.

[Verikon]

@jingsam agree, this one is particularly painful.

[orenfromberg]

I am having this error on Windows 10 Home 1709 16299.15

[khuongduybui]

I upgraded to 17017.1000 and no longer observe this issue. Can someone confirm a fix?

[Archomeda]

Updated my Windows 10 Pro yesterday to 16299.15, which was already painful with .url shortcuts not working, night light having weird coloration, Nvidia driver 387.68 shitting themselves (why even install this version automatically, it's not even available from Nvidia themselves), and now WSL not handling yarn add properly.

This really is the worst Windows update for me so far. I'm reverting back to the previous Windows 10 version. Any ETA for when this is fixed?

[orenfromberg]

@khuongduybui I also upgraded to 17017.1000 and the issue is no longer observed. Thanks!

[skyzh]

I have upgraded to 17017.1000 but this issue still exists.

yarn install v0.27.5
[1/4] Resolving packages...
[2/4] Fetching packages...
warning fsevents@1.1.2: The platform "linux" is incompatible with this module.
info "fsevents@1.1.2" is an optional dependency and failed compatibility check. Excluding it from installation.
[3/4] Linking dependencies...
warning "bootstrap@4.0.0-beta" has unmet peer dependency "jquery@>=3.0.0".
warning "bootstrap@4.0.0-beta" has unmet peer dependency "popper.js@^1.11.0".
error An unexpected error occurred: "EINVAL: invalid argument, lstat '/mnt/d/Work/BlueSense/node_modules/@firebase/util/gulpfile.js'".
info If you think this is a bug, please open a bug report with the information provided in "/mnt/d/Work/BlueSense/yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.

[khuongduybui]

@skyzh I am using latest version of yarn 1.x and do not observe the problem. Maybe that could help.

[Verikon]

Running 1709 (OS Build 17017.1000) and still seeing the issue;

bren@Crowley:/mnt/e/project$ yarn install
yarn install v1.1.0
info No lockfile found.
[1/4] Resolving packages...
[2/4] Fetching packages...
info fsevents@1.1.2: The platform "linux" is incompatible with this module.
info "fsevents@1.1.2" is an optional dependency and failed compatibility check. Excluding it from installation.
[3/4] Linking dependencies...
error An unexpected error occurred: "EINVAL: invalid argument, lstat '/mnt/e/project/node_modules/amqplib/node_modules/string_decoder/index.js'".
info If you think this is a bug, please open a bug report with the information provided in "/mnt/e/project/yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
bren@Crowley:/mnt/e/project$

[SvenGroot]

Build 17017 does not have the fix for this issue yet. The fix has been checked in and is making its way through our system, and will hopefully be in an insider build sooner rather than later, but it's difficult for me to say when that will happen. We'll keep you informed.

[codeart1st]

Is it possible that fixes like that will be patched with normal windows updates?

[danicatalan]

This is working for me now after updating to 17017.rs_prerelease.171010-1400 with yarn 1.0.2.

[mrmckeb]

@SvenGroot I installed the official release today and encountered this problem. I understand this will go out to insiders, but what about those of us not in the insider program - will this be available as an update through Windows Update or the Microsoft Store?

We rely on Yarn Workspaces - so this effectively stopped me from being able to work on our project, unless I roll back Windows 10 (which I might do tonight).

---

Edit: I found that cloning the repository to my home directory (in the Linux file system) enabled me to complete a yarn install keep working.

cp -R -d /full_source_path /full_destionation_path

If you, like I did, see that all files are now marked as modified in git, try this:

git config core.fileMode false

[nelak]

@SvenGroot I was just hit by this when upgrading to the RTM fall update. Can you confirm if there's an ETA for the fix and if it will be possible to get it without going through the insiders builds? The issue is also reproducible with npm install although it doesn't fail as badly

[SvenGroot]

We are working to get this bug serviced in the Fall Creator's Update as soon as possible. Unfortunately, the timing of that depends on a lot of things besides just me, so I can't give you any dates. We'll keep you posted.

[nelak]

Thanks for the update, and looking forward to the fix.

[Warblefly]

Still getting failures in compilation of very large projects within lxss with gcc very occasionally reporting EINVAL. Re-running the compilation cures the problem, so it appears that the referenced file (a header, usually) is still occasionally turning into something odd, then coming back again. Built 17017.1000. This is a terrible pity, because WSL used to be totally reliable for the biggest compilations, like native GNU/Linux. Very sad to see it not working as it used to.

[SvenGroot]

Unfortunately, Insider build 17025 does not appear to have the fix for this yet. However, it looks like it will be in the next Insider preview build. We're still working on getting this serviced on the Fall Creator's Update as well.

[Warblefly]

Thanks for letting me know.

[Log1x]

😿 This bug makes me want to claw my eyes out.

[noinkling]

For some of us this issue is a massive showstopper and causing more than a little frustration. Don't forget that it's also a regression (at least from a user perspective), so I would expect it to be very high-priority. It has been about 3 weeks since the FCU landed and we haven't gotten much more than a vague "we're working on it", which doesn't exactly inspire a whole lot of confidence that this will be addressed in a timely manner. We would greatly appreciate a little more information/assurance about when/how the fix is going to land, so we can at least make a better decision on how to mitigate the productivity loss caused in the meantime. Any insight into the process, even if it's just a hypothetical worst-case scenario, is better than having a question mark hanging over the whole thing (if the fix isn't going to be speedy).

I don't want to sound ungrateful or anything - I'm very appreciative of the work that has gone into WSL, and from what I understand things like update timing are mostly outside the WSL team's control - but a little more transparency/communication would go a long way towards alleviating some of our concern.

[rhyek]

This sort of thing paints Windows + WSL as an unreliable setup for modern Web development where Linux or MacOS seem more robust and streamlined. I understand Microsoft's interest in making something like WSL, especially with new hardware offerings such as the Surface Book 2 competing directly with Macbook Pros. They want to target professional users who use their laptops as their main work tool, but there doesn't seem to be enough focus going into making WSL attractive/trustworthy enough with issues such as this persisting almost 2.5 months after being reported.

How can I, as a professional, justify purchasing Microsoft products when I can't trust them to properly support them in a timely manner?

Sorry for the rant. I really want my next laptop to be a Surface Book 2, but it is not looking very likely.

[peterjuras]

The rants might seem harsh, but maybe to reiterate the impact of this issue:

Right now it is not possible to work on any nodejs, webpack, etc. project since both npm and yarn fail to install. The workaround is very painful and costs too much time because it needs to be done on each dependency change or adjustment.

I'm actually quite pessimistic, there were no WSL updates between Creator's Update and Fall Creator's Update for users of the stable Windows version as far as I can remember, therefore it is somewhat sad to have an absolutely broken WSL for node users, especially with the big fanfare of blog posts announcing that WSL would no longer be beta?

[Log1x]

The above couldn't explain the situation any better. I had been tempted to write something similar but wasn't sure I could contain my anger and frustration in the process.

The amount of time (AND MONEY) I've lost the last 3 weeks trying to work around this bug has made me incredibly bitter after spending hours writing guides, resources, tutorials, etc. talking up WSL.

I have the number one result on Google for a majority of the keywords revolving around setting up development with WSL and it makes me incredibly tempted to just edit my post and tell people to stay the hell away.

If Microsoft can't take this seriously, I'm afraid I can't take them seriously either.

[orenfromberg]

I had been developing with WSL since January 2017. This issue forced me to install and dual boot with Ubuntu. I managed to fix the issue on my personal laptop but the issue persisted on my main work laptop. It will be a hard sell for me to go back to developing on Windows after this issue.

[simonbuchan]

I should note that for many npm workflows, including the majority of webpack setups, you can simply use Windows yarn or npm, and that it's possible to alias them such that you don't even need to change your workflow.

That said https://blogs.msdn.microsoft.com/commandline/2017/07/28/windows-subsystem-for-linux-out-of-beta/ is pretty ironic 😓

[rhyek]

@simonbuchan

I should note that for many npm workflows, including the majority of webpack setups, you can simply use Windows yarn or npm, and that it's possible to alias them such that you don't even need to change your workflow.

Working with 2 filesystems at the same time is already hacky enough to be working with two redundant binaries for each OS simultaneously as well. Which to use when and how? I would rather just have everything inside the Linux context and have it work 100%. That should be the goal.

[noinkling]

@simonbuchan That may work ok for some people, but be warned that it produces non WSL-compatible native modules and binaries/binstubs, and causes issues for packages that make use of inotify (or anything else that requires OS checks at install time).

The other workaround to have node_modules reside on the WSL filesystem is probably "cleaner", but that obviously breaks any Windows tooling (e.g. VS Code intellisense).

[Verikon]

I must say, my Vim skills have greatly increased due to this issue exclusively.

Being this issue has arisen from Yarn , its probably safe to assume the people most pained from this issue are ReactJS developers (and some Angular). This issue has really empowered the "nay-windows sayers" in my workplace when they argue "you cannot develop javascript on windows, in the same way you cannot really develop .NET applications without windows".

I'm a big advocate for win10 and personally feel the new direction and innovations from Microsoft should be both acknowledged and enjoyed because really, its just a great OS! WSL makes it fantastic.

Please take this issue as a strong use-case to improve the release methodology for WSL, I don't want to go onto Linux or Mac because I can't safely rely on it.

Keep up the good work otherwise!