I'm trying to get an electron forge app running on my Windows 10 machine via Linux on windows (using the new built-in windows bash functionality).
When running electron-forge start I am getting back the error message:
[1484:1126/222326.466455:FATAL:setuid_sandbox_host.cc(157)] The SUID sandbox helper binary was found, but is not configured correctly. Rather than run without sandboxing I'm aborting now. You need to make sure that /mnt/c/.../node_modules/electron/dist/chrome-sandbox is owned by root and has mode 4755.
From some searching, this thread on the electron Github makes it pretty clear that this is somewhat by design and the way to get around it is to run chmod as a root user post-installing all of the dependencies.
I attempted to do this and the command looked like it had worked (no error on running the chmod to 4755), but that didn't fix running electron-forge start - I still got the same error message. I looked into that a bit and it seems that this has to do with what files the linux subsystem are allowed to control permissions for per this Microsoft thread.
Is there some other trick to getting electron forge to work with bash on Windows?
I found that running the electron-forge init from Windows powershell into a native Windows directory allowed me to subsequently use npm start in my-app (for example) in WSL. So ultimately what I ran was
powershell npx create-electron-app my-app
(I have alias powershell="/mnt/c/windows/system32/WindowsPowerShell/v1.0/powershell.exe" in my .bashrc file)
Related
I have a nativescript application in windows that deploys to the emulator just fine, but when I git clone onto the MacBook Pro and run the same process, I get:
new-host:nativescript jbaird$ tns run android
Searching for devices...
Starting Android emulator with image Nexus_5X_API_26
Waiting for emulator device initialization...
Executing before-liveSync hook from /Users/jbaird/Documents/development/gr8dates/Nativescript/hooks/before-liveSync/nativescript-angular-sync.js
Executing before-prepare hook from /Users/jbaird/Documents/development/gr8dates/Nativescript/hooks/before-prepare/nativescript-dev-typescript.js
Found peer TypeScript 2.4.2
Preparing project...
Project successfully prepared (Android)
Building project...
Unable to apply changes on device: emulator-5554. Error is: spawn EACCES.
Executing after-watch hook from /Users/jbaird/Documents/development/gr8dates/Nativescript/hooks/after-watch/nativescript-dev-typescript.js
Any ideas? Thanks in advance.
The error is a permission error. Therefore, all you need to do is give access to the the folder you are running your apps from. The process involves you to copy and paste the command below into your terminal.
sudo chmod -R a+rwx /AppFolder
The command is an administrator command, therefore, you may have to insert your system password.
PS: Definitely, you hit enter and there will be a prompt for you to insert your password.
Let me know if you have any challenges with this solution!
emulator-5554. Error is: spawn EACCES.emulator-5554. Error is: spawn EACCES.
Seems a permission error. You could solve it by:
sudo,
Or, by giving +x permision to your hooks folder?
I'm a beginner at docker trying to get it working on my Windows 10 machine using creator's update bash subsystem. My dockerfile builds fine on my mac, but when I try docker build from the same file on windows, I get errors like the following:
time="2017-08-28T14:44:36-07:00" level=error
msg="Can't add file \\\\?\\C:\\Users\\username\\Workspace\\...\\node_modules\\.bin\\nodemon
to tar: readlink \\\\?\\C:\\Users\\username\\Workspace\\...\\node_modules\\.bin\\nodemon:
The system cannot find the file specified."
This is printed out for all of my node_modules dependencies. My first question is: What is triggering this "add" operation for all of my node_modules? These error messages are printed out before the first line of my dockerfile is executed
Step 1/25 : FROM ubuntu:14.04
Second, does this issue have something to do with different paths in windows? To me, the weirdest part about the errors is the strange path \\\\?\\C:\\Users\\username. What is going on here with the excessive slashes and a question mark in the path?
Third, is it just me? Or does everyone encounter problems when using docker on windows bash subsystem?
NOTE: I've tried setting up the Docker Toolbox and running the quickstart terminal. I get the following error from running the quickstart terminal
Error with pre-create check:
"This computer is running Hyper-V. VirtualBox won't boot a 64bits VM when Hyper-V is activated. Either use Hyper-V as a driver, or disable the Hyper-V hypervisor. (To skip this check, use --virtualbox-no-vtx-check)"
Looks like something went wrong in step ´Checking if machine default exists
´... Press any key to continue...
So I've tried making sure hyper-v is enabled from this article here
NOTE 2: I've also made sure that my C drive is shared with my containers
I've been working with Docker for Windows, attempting to create a Windows Container that can run cygwin as the shell within the container itself. I haven't had any luck getting this going yet. Here's the Dockerfile that I've been messing with.
# escape=`
FROM microsoft/windowsservercore
SHELL ["powershell", "-command"]
RUN Invoke-WebRequest https://chocolatey.org/install.ps1 -UseBasicParsing | Invoke-Expression
RUN choco install cygwin -y
RUN refreshenv
RUN [Environment]::SetEnvironmentVariable('Path', $env:Path + ';C:\tools\cygwin\bin', [EnvironmentVariableTarget]::Machine)
I've tried setting the ENTRYPOINT and CMD to try and get into cygwin, but neither seems to do anything. I've also attached to the container with docker run -it and fired off the cygwin command to get into the shell, but it doesn't appear to do anything. I don't get an error, it just returns to the command prompt as if nothing happened.
Is it possible to run another shell in the Windows Container, or am I just doing something incorrectly?
Thanks!
You don't "attach" to a container with docker run: you start a container with it.
In your case, as seen here, docker run -it is the right approach.
You can try as an entry point using c:\cygwin\bin\bash, as seen in this issue.
As commented in issue 32330:
Don't get me wrong, cygwin should work in Docker Windows containers.
But, it's also a little paradoxical that containers were painstakingly wrought into Windows, modeled on containers on Linux, only for people to then want to run Linux-utils in these newly minted Docker Windows containers...
That same issue is still unresolved, with new case seen in May and June 2018:
We have an environment that compiles with Visual Studio but still we want to use git and some very useful commands taken from linux.
Also we use of-the-shelve utilities (e.g. git-repo) that uses linux commands (e.g. curl, grep,...)
Some builds require Cygwin like ICU (a cross-platform Unicode based globalization library), and worst: our builds require building it from source.
You can see an example of a crash in MSYS2-packages issue 1239:
Step 5/5 : RUN "C:\\msys64\\usr\\bin\\ls.exe"
---> Running in 5d7867a1f8da
The command 'cmd /S /C "C:\\msys64\\usr\\bin\\ls.exe"' returned a non-zero code: 3221225794
This can get more information on the crash:
PS C:\msys64\usr\bin>
Get-EventLog -Index 28,29,30 -LogName "Application" | Format-List -Property *
The workaround was:
PS > xcopy /S C:\Git C:\Git_Copy
PS > C:\Git_Copy\usr\bin\sh.exe --version > v.txt
PS > type v.txt
As mentioned in that thread, the output gets lost somewhere in the container, thus sending it to a text file.
After playing with it for a long time, my findings were the following:
If your Cygwin utilities are crashing your container, you need to use process isolation. See https://learn.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/version-compatibility for the requirements (essentially you need to use Windows Server 2016 and a build-matching Docker Image). I spent some time trying to understand the reason why hyper-v isolation doesn't work and so far I didn't come to any conclusion;
If your Cygwin utilities apparently do nothing - but they don't crash the container - you need to remove the -t flag (the -i flag is still ok) or alternatively play with stdout redirection. Apparently there seems to be an issue with MSYS2 when it deals with some pseudo-ttys. You can verify that programs still run if you redirect stdout to a file (e.g. whoami won't output anything when you run it without any stdout redirection, but whoami > out.txt will output the expected result to a file). It might be possible to fix this by replacing the pseudo-tty but I didn't try it. I suspect that the problem is an invalid handle somewhere inside the MSYS2 libs - as other console apps can print things to the terminal - but I didn't verify this.
Hope it helps to all of you having the same problem.
I was able to get a preinstalled (copied from the host) copy of Cygwin to work in a nanoserver-based container with these two steps:
Using Żubrówka's recommendation for no -t in the docker run cmd-line (when running docker interactively)
Copying the host's (Windows Server 2016) kernel32.dll to the container's c:\windows\system32
I found serveral versions of kernel32.dll on my system, and used the one from c:\windows\system32 with md5 hash d8948a7af764f7153b3e396ad44992ff
This also made a large variety of other executables work. Note that without a tty, using the container is even more cumbersome, and the bash shell doesn't render the prompt. However, scripts (via Jenkins, in my case) that rely on cygwin components work fine.
If that doesn't help, try this guide, it helped me a lot. If your windows application (other than cygwin) is legitimately missing DLLs, the instructions in this guide can help. It never occurred to me that SysInternals' procmon.exe can be run on the host and still report events from the container!
I am in the process of installing jupyterhub. I successfully install jupyterhub using:
python3 -m pip install jupyterhub
npm install -g configurable-http-proxy
However, when I run jupyterhub -h in the Windows command prompt it gives:
"jupyterhub" is not recognized as an internal or external command, operable
program or batch file.
I added C:\Users\User\AppData\Local\Continuum\Anaconda3\Lib\site-packages\jupyterhub\ to my user environment variable, however still receive the message. What path should I be using?
Please note that according to this, Jupyterhub is not officially supported for Windows yet.
That aside, you could dockerize it to make your life easier. For this error, please check if you can see the executable in C:\Program Files\Continuum Analytics\Anaconda3\scripts. The lib directory you're specifying contains python source files and not the executables.
I had this same issue, and I saw this occurred because jupyterhub is a python script rather than an executable. So to run this on Windows I needed to execute it like python C:\Program Files\Continuum Analytics\Anaconda3\scripts\jupyterhub.
However, I still was unable to run jupyterhub on Windows because it depends on the pwd module, which is a Unix/Linux only module.
As others have said, Windows is not a supported platform. JupyterHub is best used on Linux-like platforms where you have Docker or something similar to conatainerize each user's session.
A good alternative is to install Oracle VirtualBox and run a local VM. I run a 64-bit Ubuntu and it's quite good performance. It makes things much easier to run JupyterHub on. Asides depending on pwd, there are also assumptions around user-creation and other activities that Windows isn't going to handle well.
In short, if you want to run on native Windows, you're going to become the first JupyterHub Windows contributor. I looked at doing it but it looked like too much effort.
The upside of running a VM is that behaviour in the VM is going to more closely resemble what you have running on the server anyway. If you don't plan running on a server, then just "jupyter notebook", as this is all JupyterHub ends up running...
I'm gonna to use vagrant on my windows desktop to develop Laravel project. I have followed all the steps to do that. But it has been failed to create homestead.yaml using bash init.sh command.
Below is the error :
Fakhreddin#Lenovo-PC3 /cygdrive/d/laravel-vagrant/homestead
$ bash init.sh
cp: unwritable ‘/home/Fakhreddin/.homestead/Homestead.yaml’ (mode 0500, r-x------); try anyway?
I'm using Cygwin for simulating Unix terminal in the Windows.
(Copy of the comment I wrote above)
Never used Cygwin in my life, but what I would try is to run it as Administrator and re-try.
Otherwise, you may want to consider changing console client. For example, if you install Git, you should be able to use Unix commands via standard Windows console.
I would seriously point the fault at Cygwin, or its settings. I am a member of a team in which all of us run Homestead on Windows 7, with no problems at all. The difference is, we use native Windows command line.