Yarn: "EINVAL: invalid argument, uv_interface_addresses" when running "yarn install"

[ludo237]

Do you want to request a _feature_ or report a _bug_?

Report a Bug

What is the current behavior?

Yarn doesn't work on Ubuntu 14.04 LTS

If the current behavior is a bug, please provide the steps to reproduce.

• Use Ubuntu 14.04 LTS
• Install yarn
• Try to run Yarn

It shows up this error

/home/ludo237/.npm-global/lib/node_modules/yarn/bin/yarn.js:48
      throw err;
      ^

Error: EINVAL: invalid argument, uv_interface_addresses
    at Error (native)
    at Object.isOffline (/home/ludo237/.npm-global/lib/node_modules/yarn/lib/util/network.js:13:25)
    at Object.<anonymous> (/home/ludo237/.npm-global/lib/node_modules/yarn/lib/util/request-manager.js:46:54)
    at Module._compile (module.js:556:32)
    at Object.Module._extensions..js (module.js:565:10)
    at Module.load (module.js:473:32)
    at tryModuleLoad (module.js:432:12)
    at Function.Module._load (module.js:424:3)
    at Module.require (module.js:483:17)
    at require (internal/module.js:20:19)

What is the expected behavior?

Install the dependencies

Please mention your node.js, yarn and operating system version.

Node v6.7.0, NPM v3.10.3 on Ubuntu Trusty 14.04 LTS

[Daniel15]

Which installation method did you use? Did you use the Ubuntu package, the tarball, or npm?

[simonbuchan]

This is almost certainly in Windows' new "Ubuntu on Windows" / WSL / LXSS feature, this is a known unimplemented API that is currently being worked on https://github.com/Microsoft/BashOnWindows/issues/468#issuecomment-251298565

That fix will not reach general release until (rumored) early next year with the Redstone 2 update, so it would be nice if you added a try / catch around the os.networkInterfaces() call. Note that the current "Insider Preview" build 14942 gets slightly further inside uv_interface_addresses so it gives ENOTSUP instead.

[Daniel15]

@simonbuchan - @ludo237's post mentioned that they're using Ubuntu 14.04, and /home/username/ doesn't exist by default in WSL (it mounts the home directory as /mnt/c/Users/Username instead)

I guess #772 should fix this issue too, though. I'd be curious as to _why_ it's happening though.

[simonbuchan]

Nope, WSL installs the real Ubuntu user-space bits:

% echo $HOME
/home/simon
% lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 16.04.1 LTS
Release:        16.04
Codename:       xenial

Current fast ring lets you do-release-upgrade to Xenial, it installs 14.04 Trusty by default.

[simonbuchan]

Home directory thing is because bash.exe without a magic ~ arg (which the shortcut has) defaults to the windows current directory:

C:\Users\simon>bash.exe -c pwd
/mnt/c/Users/simon

C:\Users\simon>bash.exe ~ -c pwd
/home/simon

[wycats]

@Daniel15 the TLDR is that the necessary syscall(s) used by the native node code haven't been implemented yet. Thats becoming increasingly rare in my experience, but this is one I hit when testing yarn on WSL over the past few weeks.

[Daniel15]

Sorry, I should have clarified my comment - @ludo237 didn't mention Windows at all in their post, which made me think they're using Ubuntu proper rather than Ubuntu on Windows 😄 By "I'd be curious as to why it's happening though", I meant "If this is happening in Ubuntu proper, I wonder what's causing that, as I've only seen it in WSL"

[simonbuchan]

For real Ubuntu, it probably could only be bad network hardware or drivers, in which case I'm surprised they could post the report 😄

[ludo237]

Hello.

Sorry for the late answer, yes it's Windows Subsystem for Linux I apologize that I miss that part 😞

[esimkowitz]

I'm having the same issue with WSL and the ENOTSUP exception. I'm guessing I could fix this by changing the '~' directory to the true Ubuntu home directory but I'd rather not as that would mess up my workflow. Are there plans to fix this with a WSL-specific directory check or something?

[simonbuchan]

I confirmed that #772 fixes this, yarn HEAD works fine except for the progress bar rendering (which could be due to the current fast ring build so I won't bother with an issue if it isn't already known)

Don't know what the release schedule is like, but you can install a clone of this repo with a standard npm install npm run build sudo ln -s bin/yarn.js /usr/local/bin/yarn (I think, this was yesterday)

[Daniel15]

except for the progress bar rendering

What issues are you seeing with the progress bar? It works for me in Cmder, cmd.exe, and PowerShell. Here's a GIF from last week:

This is just on "regular" Windows though, I haven't tried via WSL yet.

[simonbuchan]

I wouldn't expect it to, as the windows bits will be using the windows console APIs not ANSI like WSL will be. The problem will be that ANSI codes are not be completely implemented in the console host, so I'm not sure there's too much you can do except use dumber progress-bar rendering

[Daniel15]

Wow, that sure is some... interesting... output. Hahaha. I wonder if simply rendering some different ("simpler") characters for the progress bar would solve that. For example we could render it like:

[==                 ]
[=======            ]
[===================]

In environments where we know they don't support fancy rendering.

[bestander]

The title issue should have been fixed

[kolaniyi]

I am still having this issue, on WSL windows. How do I implement the fixes

[BYK]

@kolaniyi upgrade your yarn? Or try adding the --ci flag to suppress fancy output?

[kolaniyi]

Thanks man, I am using 0.27.5. The latest version as at now

[kolaniyi]

@BYK Thanks man, I am using 0.27.5. The latest version as at now

[BYK]

@kolaniyi sorry, I referred to a non-existent option, --ci earlier :)

Try using the --no-progress option. You can put this into your .yarnrc file to make it the default too.