Closed khuongduybui closed 6 years ago
Apparently my Surface Pro 4 has updated itself overnight because now I have the same issue. It's sad that this issue was surfaced 2.5 months ago and it still is hitting new people.
Hi all. I've been pinged several times over the last 48 hours for an update on the fix for this issue.
Know that we appreciate and understand the enthusiasm for the fix for this issue, but we do ask for your patience as the fix makes its way up through our build and test systems, on its way to the Insider rings.
As @SvenGroot stated above, the fix has been checked in but it didn't make it up to the Insider release branch in time for 17025 which was released on 11/1. It's v. likely it'll arrive in the next Insider build.
Sven is also working to backport this fix to Fall Creators Update (FCU), but since this isn't a fix for a major security exploit, it'll make its way through our normal servicing channels, passing through numerous review and testing gates before it's formally released in an up-coming servicing release.
While Microsoft is much more agile today than ever before (we now essentially ship Windows every week) there are still processes that churn behind the scenes to ensure that we catch as many bugs as we can before they're released, and that fixes are tested & released in an organized manner.
Only fixes for the most high-risk, high-impact issues bypass these standard processes, but these exceptional fixes are themselves placed under the most exacting scrutiny possible, requiring HUGE deployment of humanpower & tooling to quadruple-check that the fix is good before its released. We reserve these rapid fix deployments only for the most important fixes for the most critical of issues, and while annoying, this fix does not qualify as 'exceptional'.
No software is ever perfect or bug free, and when you're delivering software used by more than a billion people every day, one has to take whatever steps possible to ensure the best outcome for the largest audience. The last thing we'd want is to release a fix that doesn't resolve the issue, and that may even make things worse.
So, please bear with us while we process this fix through our release processes.
Thanks.
We appreciate the pain some of you are feeling because of this issue. Please believe me: we take this very seriously and have been working very hard to get the fix to you as soon as possible.
Update! This issue is now fixed in Insider build 17035. If you are a Windows Insider, please update to build 17035 or later and do not use the workaround!
Update 2! This issue is now fixed in the Fall Creator's Update. Please install the latest update (your build number should be 16299.98 or later) and do not use the workaround!
In the mean time, the following workaround should get around this issue. When starting bash, run the following commands:
sudo umount /mnt/x
sudo mount -t drvfs -o noatime,fallback=1 X: /mnt/x
Replace /mnt/x and X: with the mount point and drive letter for any affected drives. If you've done this correctly, you can run mount
and you'll see a line like this:
C: on /mnt/c type drvfs (rw,noatime,fallback=1)
If the fallback option is shown, it has been mounted correctly. We believe that doing this will allow you to use the drvfs mount without hitting this issue.
You'll have to do this every time you start a new WSL instance (so every time you open bash after all bash windows were closed).
Note! Doing this will disable all the performance improvements we've implemented since RS1 (version 1607, the Anniversary Update). Don't use this workaround unless you're hitting this issue.
I'll update once the fix is released, at which point I strongly recommend you stop using this workaround.
@SvenGroot you are our savior, thank you!
I've added the workaround to my ~/.bashrc
and it seems to work:
# Workaround for issue: https://github.com/Microsoft/WSL/issues/2448
if ! mount | grep -q "C: on /mnt/c type drvfs (rw,noatime,fallback=1)"; then
echo "== Remount of C: drive required =="
pushd ~ > /dev/null
sudo umount /mnt/c
sudo mount -t drvfs -o noatime,fallback=1 C: /mnt/c
popd > /dev/null
fi
Thanks for this fix. Just to confirm my understanding of when this fix is necessary (for usage with Yarn), it's only necessary when performing certain functionality of Yarn? Like when creating and updating dependencies?
I've wrapped the above code within a prompt so that my WSL is not always crippled back to version 1607.
Workaround bei @Melatonin64 works fine as well as the workaround by @khuongduybui (symlink outside /mnt). Quick bugfix would be appreciated though! Thanks for the support here @ wsl team!
Thanks a lot for the workaround, that will definitely tide me over until the fix is available.
@JimW
I think it will depend on what you're specifically doing, but anecdotally/personally I haven't run into the issue (yet) outside yarn install/upgrade
. The rest of my day-to-day workflow works fine on the new version. So yeah, it sounds like you have the right idea.
I'm really very sad i meet the same problem today.When i use create-react-app then this problem appear.Hope mircrosoft fix this bug soon..... sad
@imgwho in latest insider release I have not observed the issue, using yarn 1.x. If you still have problems with latest release AND latest yarn version, then try the other workarounds, especially https://github.com/Microsoft/WSL/issues/2448#issuecomment-342254181, that could help.
@imgwho, create-react-app will successfully complete with the above workaround code, using the latest regular "Outsider" Windows.
@khuongduybui thx ~~ i'll try
@JimW oh i update the create-react-app to 1.4.3 then i found the problem sloved ,, thx~~~
@imgwho and whoever else it might help, there's yarn's built-in yarn create react-app myapp
, meaning you no longer need the independent create-react-app
package...
This bug should be fixed in Insider build 17035, which was just released. Please stop using the workaround posted above, and let us know if you still encounter any issues.
Users on the official Fall Creator's Update (build 16299) should continue to use the workaround (or update to the latest Insider build, if possible).
Will an update for this be possible to push to non-insider or are those of us not on insider effectively screwed this update?
@hikurangi i'm Fall Creator's Update (build 16299.19) use WSL on Ubuntu 16.04.3 LTS ,i used use npm to install yarn and then i use apt-get to install yarn yarn official website
Debian/Ubuntu Linux
On Debian or Ubuntu Linux, you can install Yarn via our Debian package repository. You will first need to configure the repository:
curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | sudo apt-key add -
echo "deb https://dl.yarnpkg.com/debian/ stable main" | sudo tee /etc/apt/sources.list.d/yarn.list
On Ubuntu 16.04 or below and Debian Stable, you will also need to configure the NodeSource repository to get a new enough version of Node.js.
Then you can simply:
sudo apt-get update && sudo apt-get install yarn
Note: Ubuntu 17.04 comes with cmdtest installed by default. If you’re getting errors from installing yarn, you may want to run sudo apt remove cmdtest first. Refer to this for more information.
and then i found.. oops....
wuv@wuv:/mnt/e/practice/react$ yarn create react-app app
yarn create v1.3.2
[1/4] Resolving packages...
[2/4] Fetching packages...
[3/4] Linking dependencies...
[4/4] Building fresh packages...
success Installed "create-react-app@1.4.3" with binaries:
- create-react-app
[##############################################################################] 107/107 Creating a new React app in /mnt/e/practice/react/app.
Installing packages. This might take a couple of minutes.
Installing react, react-dom, and react-scripts...
yarn add v1.3.2
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/practice/react/app/node_modules/acorn-jsx/index.js'".
info If you think this is a bug, please open a bug report with the information provided in "/mnt/e/practice/react/app/yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/add for documentation about this command.
Aborting installation.
yarnpkg add --exact react react-dom react-scripts --cwd /mnt/e/practice/react/app has failed.
Deleting generated file... node_modules
Deleting generated file... package.json
Deleting generated file... yarn-error.log
Deleting app / from /mnt/e/practice/react
Done.
error Command failed.
Exit code: 1
so i think i should just waiting the 17035 come...
I had not applied any workaround nor installed newer versions of any binaries since providing traces on September 14th. I now can:
yarn install
create-react-app hello-api
rails webpacker:install
The only change on my system was the build 17035.1000. I have no new errors to report, no regressions noticed yet.
@Log1x As we've pointed out before, a fix for the Fall Creator's Update will be coming soon. Please be patient, and continue to use the workaround I posted above in the mean time. I will update here once the fix has been released.
The fix was in 17035 so all current Insiders builds should no longer have this issue.
@khuongduybui @orenfromberg @peterjuras @Log1x @AndyGauge @rhyek and anyone else reporting this issue - can you please upgrade to Insiders fast-ring build 17035 (or later) - or install a VM running this build - and let us know if your workflow is now fixed & unblocked?
TIA.
hello,
The last insider build fixed the issue on my machine. Below is my environment:
Yarn: v1.3.2
Node.js: v6.9.5, v8.6.0
Insider Build Preview OS Build: 17035.1000
Insider Build Preview Version: 1709
sneakily ran npm install
works as expected however it just made the office internet choked up a little bit but all good.
thanks for all your hard work!
After updating the issue seems to be fixed for me!
Great, thanks for testing and sharing your results. We (i.e. @svengroot ;)) continue to backport the fix through our release machinery.
@bitcrazed @SvenGroot Thanks so much for your work on this. As developers, we can all appreciate how tricky these things can be to solve and the effort required to backport a fix.
Is there currently an ETA on this? And if not, an approximation - one week, a month?
@bitcrazed @SvenGroot Please, tell me, in what not insider build will this bug be fixed?
Using Insider Build 17040 on my very large compilation executed on WSL, with the compilation taking place on a DrvFs mount, almost everything works.
At one point in the day-and-a-half long cross-compiled on eight processors on a 16GB machine, I received:
x86_64-w64-mingw32-gcc: command not found
Once, and once only. Restarting the make process got past this point.
The "x86_64-w64-mingw32-gcc
" is my cross compiler, as found by many, many thousands of other make processes in this long compilation. Why it should disappear for one, and only one, call among the galaxy of other calls, I don't know.
I also received two "fork: invalid argument
" notices. Again, restarting the make process recovered from this. This might be #2469 again.
So, this is much, much more reliable. But the "command not found
" is a mystery.
@RinatMullayanov - we'll let you know once the fix bubbles up into the servicing release mechanisms.
@Warblefly - wow - 36 hour compile??? ;) Have asked the team to take a look at #2469 - please follow/contribute there.
I wish I didn't have to connect Microsoft Account with my installation of Windows in order to participate in Windows Insider. I could really use this fix ASAP, not whenever this is scheduled to go out to non-Insiders. 😞
When can people like me and @RinatMullayanov expect this to go out, is it possible to tell at least roughly @bitcrazed / @SvenGroot?
You can download an ISO
You can download an ISO
Or you can download a Linux ISO while you’re at it. I know I did, and the console works significanlty faster, by the way. Still boot to Windows, but not at work. It’s a shame; I like Windows and miss it a lot.
Seriously folks, I don’t want to sound bitter, but people got other things to do than downloading ISOs or installing insider builds. I know they’re pretty stable, but still.
I know the WSL team probably has very little influence on the release cycle, but I think those who have should reconsider the criticality of the fix. You risk losing people, people.
I'm having the same issue when trying to use yarn
. It is blocking my environment. I might need to change OSes or use docker just because of this :s
@bitcrazed @SvenGroot any reason you guys don't use the Release Preview ring for stuff like that? Seems ideal to me.
@TomasHubelbauer The reason we ask you to primarily get your distros from the store is that this allows distro vendors to patch and service their releases, ensuring that when you install a distro, you're always installing the latest supported version. This requires that you sign-in with your MSA, so that we know to push updates to your machines when they're published.
@hoichi The distros that you download and install manually are identical to the distros you install via the Store so there'll be no perf differential between the two.
@Stanzilla Let's just say that the Windows servicing release mechanism is complex, for good reasons ;)
The fix for the Fall Creator's Update should be coming very soon. We can't comment on the timeline, because the patch could be delayed for any number of reasons beyond our control. In the meantime, the workaround posted above should prevent any issues.
We appreciate your patience and understanding.
@SvenGroot I'm on build 16299.64 . Is this issue related to #2464 ? Will that be fixed in the incoming backport patch?
@nutcasev15 - #2464 jumped the rails because it started as what looked like as a LxFs problem and then someone posted a DrvFs problem in the same thread. The original LxFs problem is still in an indeterminate "needs repro" state. I compile huge GCC builds on LxFs regularly without EINVAL
issues so there is no way to tell what is going on over there or whether it is "related". The 17035 release notes for this issue say DrvFs, and I'd take that at face value.
Good news, everyone!
The November 30th, 2017 Cumulative Update (KB4051963) for the Fall Creator's Update contains the fix for this issue. Please install this update, and let us know if you encounter any further issues.
To verify if you have installed the update, your OS build number should be 16299.98 or later.
The update requires a computer reboot, but afterwards it works for me.
A quick summary of #2712: the files that intermittently go missing are simply "not found". This isn't an EINVAL error. Not sure if it's exactly related to #2448.
Works for me too, no issues anymore
after applying the update, the error is no more.
but - was this always so slow? create-react-app test
takes over 62 seconds in bash compared to 16 seconds in cmd on a decent i7 4.2Ghz workstation.
Yeah, I hadn't used WSL for months. Trying it now and adding packages using yarn
is incredibly slow for my project. I usually work on it on my dual booted Ubuntu install and it is definitely quicker there.
@rhyek @mindhaq Disk IO perf is a well known WSL issue that Sven is working with the storage team to address in future WSL releases.
However, while WSL disk perf is slower right now, it should work correctly. Can you confirm?
@bitcrazed Yes, everything is functional.
Great thanks.
Closing for now since we have a few confirmations that the issue appears to be resolved.
@bitcrazed Apart from slow IO it is working fine now, thank you!
It's good to hear that disk perf is being addressed. Is there an Issue to follow on?
Thanks for letting us know.
The larger disk perf issue is primarily being tracked in issue #873
I upgrade my OS to newest insider preview(17025.10000),still have this problem
newest insider preview(17025.10000)
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