I've installed msysgit Git-1.7.10-preview20120409.exe from here http://code.google.com/p/msysgit/downloads/list on my Windows Server 2003 64-bit machine. I included "Git Bash here" during the setup. When I select "Git Bash here" for any folder listed in Windows Explorer I get
C:\Program Files (x86)\Git\bin\sh.exe: * fork: can't reserve memory
for stack 0x490000 - 0x690000, Win32 error 0
0 [main] sh.exe" 1348 sync_with_child: child 2612(0xF8) died before initia lization with status code 0x1
145 [main] sh.exe" 1348 sync_with_child: * child state waiting for longjmp
sh.exe": fork: Resource temporarily unavailable sh.exe"-3.1$
But, the Start Menu item Git, Git Bash does not encounter the same problem. Instead I get
Welcome to Git (version 1.7.10-preview20120409)
Run 'git help git' to display the help index. Run 'git help '
to display help for specific commands.
dmoore#DC1-2K3 ~ $
I suppose the Windows Explorer shell extension should use c:\windows\syswow64\cmd.exe but I don't know how to tell it to do that.
Any suggestions are much appreciated,
DaleEMoore#gMail.Com
OK, so it looks like on 64-bit XP and Server 2003, the 64-bit (default) wscript process can't properly launch bash, and since that's how the menu entry is set up in the registry, it's causing this issue while the start menu shortcut explicitly specifies the syswow64 version.
The solution is to edit the registry key HKEY_CLASSES_ROOT\Directory\shell\git_shell\command "default" value.
It probably looks like wscript "C:\Program Files (x86)\Git\Git Bash.vbs" "%1"
Change it to something like C:\Windows\SysWOW64\wscript "C:\Program Files (x86)\Git\Git Bash.vbs" "%1" as appropriate (if your windows directory is elsewhere, etc.)
This should be brought up as a bug with the git for windows people, unfortunately it looks like they closed their bug tracker.
On Windows XP 64
[HKEY_CLASSES_ROOT\VBSFile\Shell\Open\Command]
change the default from
"%SystemRoot%\System32\WScript.exe "%1" %*"
to
"%SystemRoot%\SysWOW64\WScript.exe "%1" %*"
Randomly I got the '* fork ...' error message for the mingw bash on an other project (I guess mingw is the origin of the sh installed by git - it is definitely the same error message). I could fix the problem by replacing the shell with win-bash
Related
So I have two WSLs (version 2). Kali and Ubuntu. The code command works in Kali but Ubuntu says Command not found. Since it works in WSL, CMD and PowerShell, it is there in PATH variables. Any help?
edit: Ubuntu doesn't read VS Code in PATH variables, while Kali does. I opened the Environment Variables Wizard. VS Code is there.
In a "normal" case, like you are seeing in your Kali instance, WSL's init appends the Windows path to your Linux path. There are two things that I can think of that would cause that to not be happening correctly under your Ubuntu instance:
You or a script that you ran in Ubuntu modified your shell's startup files (assuming Bash, typically ~/.bashrc or ~/.profile) to edit the PATH, possibly removing the Windows elements, or at least the VSCode element.
Try running that instance without any Bash startup files (from PowerShell or CMD) with:
PS> wsl -d Ubuntu -e bash --noprofile --norc
and then try code .. This, of course, assumes that your Ubuntu instance is named Ubuntu. If it's named something else (wsl -l) then edit the -d Ubuntu as needed. You might also try launching it as wsl -d Ubuntu -e sh -c 'code .'
If that works, examine your startup files for any modifications to PATH.
Less likely (because you should know if you did this one), is that you can disable the WSL feature that appends the Windows PATH in a particular distribution/instance. Check for the existence of a /etc/wsl.conf file -- If it exists, the line appendWindowsPath=false would cause the behavior that you are seeing as well. Simply change the offending setting to true. Exit your Ubuntu instance, run wsl --terminate Ubuntu (again, substituting the correct distro name) and then restart. Check your PATH and try code . again then.
I am new to WSL and have installed VS code natively on Windows 10 with the installer. Currently, when I try to run VS Code command code from WSL, I receive the following message:
bash: /mnt/c/Users/user/AppData/Local/Programs/Microsoft VS Code/bin/code: Permission denied
Also, when I try to run VS Code Server for WSL, I am getting a similar message.
[2020-06-29 17:41:41.640] Launching C:\windows\System32\wsl.exe -d Ubuntu sh -c '"$VSCODE_WSL_EXT_LOCATION/scripts/wslServer.sh" cd9ea6488829f560dc949a8b2fb789f3cdc05f5d stable .vscode-server 0 ' in c:\Users\user\.vscode\extensions\ms-vscode-remote.remote-wsl-0.44.4}
[2020-06-29 17:41:41.779] sh: 1: /mnt/c/Users/user/.vscode/extensions/ms-vscode-remote.remote-wsl-0.44.4/scripts/wslServer.sh: Permission denied
[2020-06-29 17:41:41.780] VS Code Server for WSL closed unexpectedly.
I have tried configuring the permissions for wsl # wsl.conf:
[automount]
enabled = true
options = "uid=1000,gid=1000,umask=022,fmask=11,metadata"
Not sure if this is relevant, but I am able to run code from Windows Powershell.
I am currently using Microsoft Windows 1909 (OS Build 18363.836) with WSL v1.
Any help will be appreciated, thanks in advance!
Run wsl.exe or PowerShell as an Administrator Runs as Admin Windows
None of the previous answers worked for me. Instead after a lot of trial and error, I discovered that the code.exe was set in a way that it was being run as Administrator. This is what prevented it from running in the WSL. Find the VC Code executable, and ensure it doesn't have the admin Shield on it's icon.
It has to do with your /etc/wsl.conf. Change the contents of the file to:
[automount]
enabled=true
root = /
options="metadata,uid=1000,gid=1000,umask=002,dmask=002,fmask=002"
umask,dmask, and fmask all have to do with permissions. A pretty good explanation of them can be found here : https://askubuntu.com/questions/429848/dmask-and-fmask-mount-options#:~:text=fmask%20and%20dmask%20are%20mount,files%20and%20dmask%20to%20directories
Maybe for someone will helpfull...
For example i have mistake like this:
$ code .
/c/Users/admin/AppData/Local/Programs/Microsoft VS Code/bin/code: line 61: /c/Users/admin/AppData/Local/Programs/Microsoft VS Code/Code.exe: Permission denied
My error resolving was by click right button mouse on icon VS Code and chosen settings then "compatibility" tab and finaly disabled "run the program as an administrator"
I solved it by putting my Ubuntu user in the www-data group. I edited the /etc/group. That www-data group is the one in my configuration belongs to Apache2. Hope this helps.
We have this problem using VSCode:
creating files using either GUI or console with VSCode gives them permission 644 (on directory it is 755)
creating files using Putty and by Windows CMD gives required permission 664 (and 775)
Considering this it seems like the problem is connected to VSCode and not the Linux settings.
We are using „Remote Development” extension (Remote – Containers / SSH / SSH: Editing Configuration Files / WSL also installed) to do this with VSCode.
System where the files are created:
Debian 9.12
Shell: bash 4.4.12
System where the VSCode is run:
Windows 10
version 1903
We have tried setting umask, but nothing changes.
Ok,
my friend found the solution (thank you too Abdullah Al Farooq - it was good starting point to where to look for - WSL indeed was the problem):
Solution:
run PowerShell (as admin)
type: Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux
restart system
This worked on two machines.
Link:
https://www.computerhope.com/issues/ch001879.htm
For me - it still was not working at this point. I had to make "clean instal" on VSCode because the umask was still setting to default 0022 every time.
Link:
https://www.logicbig.com/how-to/visual-studio-code/remove-vs-code-completely.html
After that - it works perfectly.
When I'm using command: schroot -c 32bit -- bash --login -c "rm -rf ~/SC32 ;"
I'm getting these errors:
E: 20copyfiles: cp: cannot create regular file `/var/lib/schroot/mount/32bit-dcc62f68-de18-4d2a-95d9-b71f0be314ce/etc/resolv.conf': No such file or directory
E: 32bit-dcc62f68-de18-4d2a-95d9-b71f0be314ce: Chroot setup failed: stage=setup-start
Since i'm new to Linux Environment i don't know what to do to solve this error.
The Cent OS which I'm using is 6.3 with x64 architecture
Also i have configured 32bit in /etc/schroot/schroot.conf as
[32bit]
type=directory
description=CentOS 6.3 32bit
directory=/chroot/32bit
users=temp
root-groups=root
personality=linux32
Also I Have this directory available /chroot/32bit
I'm not the root user of the system.
Can anybody tell me what to do to resolve this error?
To debug problems with schroot, try running it verbosely:
schroot -v
or to make it really verbose
schroot -v --debug=notice
The actual failure here is to copy /etc/resolv.conf. There are two potential reasons for this
The source file isn't copyable. Normally unlikely, but try cp and cat by hand to check.
The destination doesn't exist. This is the usual cause of such errors.
Your chroot is /chroot/32bit and it's being (bind) mounted on /var/lib/schroot/mount/32bit-dcc62f68-de18-4d2a-95d9-b71f0be314ce. If /chroot/32bit/etc does not exist, then /var/lib/schroot/mount/32bit-dcc62f68-de18-4d2a-95d9-b71f0be314ce/etc won't exist either, and so the copy operation will fail. You must have a proper system available under /chroot/32bit with all the usual directories (/bin, /etc, /lib etc.).
Assuming that you do have a proper chroot in /chroot/32bit, then something has gone wrong during setup. Running with verbose or debug messages enabled may shed some light on the cause of the failure.
Regards,
Roger
(schroot author)
I followed #Roger 's solution and all is well. But I found another workaround solution:
Enter your schroot directory, maybe like this location: /chroot/32bit, you can find this path in "/etc/schroot/schroot.conf" setting file.
cd /chroot/32bit
mv /chroot/32bit/etc/resolv.conf /chroot/32bit/etc/resolv.conf.bk
Then you can try your schroot login command and check is success.
schroot -c 32bit
(32bit)WDan#linux-buildy01:~$
Enjoy it!
My Cygwin environment (Windows 7 O/S) has developed a strange problem. A couple of days ago I was running a perl script fine, but today I'm getting
0 [main] perl 5056 C:\cygwin\bin\perl.exe: *** fatal error - unable to remap \\?\C:\cygwin\lib\perl
5\5.10\i686-cygwin\auto\Socket\Socket.dll to same address as parent: 0x8F0000 != 0x960000
Stack trace:
Frame Function Args
0088B508 6102749B (0088B508, 00000000, 00000000, 00000000)
0088B7F8 6102749B (61177B80, 00008000, 00000000, 61179977)
0088C828 61004AFB (611A136C, 6123E0FC, 008F0000, 00960000)
End of stack trace
I tried running rebase, as advised here but the problem persists. Any answers appreciated, as I have a demo tomorrow for which this script is needed. Wasn't expecting a problem like this!
This is a semi-informed answer, as I have had similar difficulty and eventually flailed around until the problem went away.
rebaseall with no arguments will rebase all of the dll files that were installed from cygwin packages. However you will often have many other dlls from other programs you have built and installed, including from installed Perl modules with XS code, and you will need to tell rebaseall about these modules somehow.
There may be an easier way to do this, and I hope I haven't forgotten any steps, but I think I had some success doing something like this:
Get a list of all the dll's in your system that run under cygwin. Maybe something like find /bin /lib /usr /home -name \*.dll > /tmp/file1
exit all cygwin processes, open as ash or dash shell from a Windows command prompt, and run /bin/rebaseall -v > /tmp/file2. The -v switch sets a Verbose flag in rebase that lists all the files that get rebased with the default setting.
Use /tmp/file1 and /tmp/file2 to create a new file, say /tmp/file3 with the complete list of files you will want to rebase. From what I remember it is important for the system dlls (all the files in /tmp/file2) to be listed first,
Now run rebaseall -v -T /tmp/file3 (in ash, after closing all cygwin procs, etc.). Pay attention to the output. If there are error messages about rebasing some particular dll, remove that entry from /tmp/file3 and try again.
This may not solve your problem, but maybe it will get you most of the way there. If you do eventually figure it out, I hope you will come back and fill in some of the holes in this solution.
I think it is useful to point out that for most people running into this a simple "rebaseall" without any arguments seems to resolve this issue. I'll post a link to a very useful blog post from My Life, Starting up (I have no relation to that blog):
http://www.mylifestartingup.com/2009/04/fatal-error-unable-to-remap-to-same.html
The action list, (copied directly from the blog) is:
Let me tell you what you can do if you don't care what's actually happening.
1) Close out of Cygwin (and all cygwin processes).
2) Open a Windows command prompt (start -> run - > type 'cmd' or on vista : start -> type 'cmd' in the start search window)
3) Go to your cygwin bin directory. For me it is c:\cygwin\bin.
4) Type ash
5) Type '/usr/bin/rebaseall'
6) Resolve any errors (I had a warning that went unresolved and it still worked fine)
7) Reboot...and you should be good.
And if you DO care what's actually happening, read the blog entry, in addition to the answer by mob here on this same question.