I installed an Archlinux distribution, and I am trying to install xOrg.
I installed xorg-server xorg-xinit and xorg-server-utils.
I also installed xf86-video-nouveau because I have a 960M from Nvidia.
To test it :
echo "xterm && sleep 10" > .xinitrc
And I run startx. I got this message
Waiting for X server to begin accepting connections
And after 2-3 minutes, I got :
Unable to connect to X server: connection refused.
Why the connection is refused ?
Thanks for help !
I never answered. But I finally managed to get it working.
I was able to run it by blacklisting nouveau drivers.
To test, at grub boot, press e on the line of your linux distribution.
You should see something like:
linux /boot/vmlinuz-4.10.0-33-generic.efi.signed root=UUID=32290445-e978-4a43-b6d9-27f9e943b3a6 ro quiet nouveau.modeset=0 splash $vt_handoff
Just add nouveau.modeset=0 between quietand splash (pretty sure it's the same as if you write it down at the end of the line but I am 100% sure it's working the way I did).
Press F10 to boot with this configuration. It should work.
Hope it helps.
Related
2I'm trying to execute a program using Vue.JS and I'm using a rich-text editor visual studio code, but every time I hit the run command I get this error:
Local host: 8000, refused to connect. Please see the image attached.
Try running lsof -i :8000 to check if that port is already busy.
If something is running try running kill -9 <PID> for killing it.
I get it, I did not run the npm run serve command on terminal in VS Code that's why it gave me an error as what I've posted. It's 100% working now.I've inserted the image below
I appreciate your answer Mr. Dipansh Khandewal. Thank you :)
my original aim was to run a headless selenium webdriver on a Raspberry Pi 3 (rasbian). After hours and hours of failing, I make a step back and now I only try to run chromium-browser which needed for the webdriver.
There... I recognize some errors after execute:
sudo ./chromium-browser --headless --no-sandbox --disable-gpu --disable-extensions
Error-Stack:
--disable-quic --enable-tcp-fast-open --disable-gpu-compositing --ppapi-flash-path=/usr/lib/chromium-browser/libpepflashplayer.so --ppapi-flash-args=enable_stagevideo_auto=0 --ppapi-flash-version=
[1015/183516.617458:ERROR:browser_main_loop.cc(670)] Failed to put Xlib into threaded mode.
[1015/183516.625190:ERROR:gpu_process_transport_factory.cc(1029)] Lost UI shared context.
I search for solution in internet but I found no results.
Following I have to add:
-everything works fine if run the webdriver on my windows system
-I reproduce the error on two complete different raspberry Pi's
-I also try to run on a Raspbian virtual machine
-I try to run the webdriver with iceweasel and geckodriver with the result "Error: connection refused"
So I am out of ideas, thankful for any response.
For others who are still struggling to find a solution:
It seems that the issue is with diplay resource when running the program on a remote server having multiple display.
You may try setting the DISPLAY environment parameter
export DISPLAY=:1.0;
I have been using ConEmu for some time to run 'bash for windows', but all of the sudden it stopped working. When I launch a bash tab it now says:
ConEmuC: Root process was alive less than 10 sec, ExitCode=0.
Press Enter or Esc to close console...
I think this means that it launched something, but the shell closed quickly. I haven't changed anything that I can recall with the system, it just started doing that.
Windows version: 10 (build 15063)
ConEmu version: 180626 preview
No windows updates were done recently.
If I launch 'Bash on Ubuntu on Windows' from the start bar, it works fine (but I prefer using conemu as a terminal). Also, I can launch a cmd tab in conemu, then type bash and the bash shell will start. Unfortunately, launching bash in this way results in a lack of mouse support, and strange arrow key behavior.
I am at a bit of a loss. It worked perfectly previously... then it just stopped. Any help on how to debug or fix this would be appreciated.
If anybody finds this with a similar problem, my solution was to make a new task in ConEmu, with the command:
%windir%\system32\bash -l -i -cur_console:p5
The key is the -cur_console:p5, which sets the pty type as:
p[N] - pty modes, N - bitmask: 1 - XTermKeys, 2 - BrPaste, 4 - AppCursorKeys; default is 5 (1+4)
For some reason, setting p5 is necessary for me, despite it being listed as the default. Still not sure what changed, but at least it is working now.
I have the same problem but (for what it's worth) found that when it happens (varying between intermittent and incessant) restarting my machine fixes the issue every time.
So I spent a few weeks on this problem now. I've been trying to get CrashPlan running on a headless FreeNAS server. I have found lots a tutorial to do this. However the fact is that I'm missing the .un_info file on my FreeNAS server after installing CrashPlan.
I have searched the whole file system to try and find the elusive .ui_info file.
I've tried creating it manually with information copied from desktop PC but that does not help me resolve my CrashPlan Pro app connecting to the Crashplan server service on FreeNAS.
INFO:
FreeNAS 9.3 STABLE
Crashplan 3.6.3_1 Plugin
The crashplan remote access behaviour changed several times during the last updates, however with version 3.6.3_1 you should find the .ui_info file in
/var/lib/crashplan/.ui_info
Although the jail version is 3.6.3 it's possible that Crashplan updated itself, please check this with:
tail -f /usr/pbi/crashplan-amd64/share/crashplan/log/service.log.0
In the end you want your Crashplan to update itself anyway. If the update process produces an error related to bash, please run:
pkg update
pkg install bash
ln -siv /usr/local/bin/bash /bin/bash
And restart crashplan while checking the log output with the tail -f command from above:
service crashplan restart
If you finally reach a recent version (>4.4.1), its time to remotely connect to crashplan.
The only change on the server necessary for the easiest method without ssh tunnel is the serviceHost tag in /usr/pbi/crashplan-amd64/share/crashplan/conf/my.service.xml.
<serviceUIConfig>
<serviceHost>0.0.0.0</serviceHost>
Either do this everytime you want to connect, because the token will change after every crashplan restart or use my script from here (for OS X): https://gist.github.com/Phlogi/8654e353786ed1cf0858
Copy /var/lib/crashplan/.ui_info to the correct place on your desktop machine and edit the IP address at the end (to your servers address), for example:
4339,7f1d655f-*****,192.168.1.20
That's it, you can start crashplan on your remote machine and it will connect properly, there are no other changes neccessary. Latest crashplan (>4.4.1) will actually use the IP address from .ui_info.
Install JRE. You will need to add --no-check-certificate to the JRE wget line in the install.sh file
I have a server that I am experimenting with, and sometimes I want to work from home so I installed the 'ssh daemon' (namely, 'sshd') and I can ssh to the server. This works fine. But when I try to run a virtual machine on the server with 'qemu', I get the following error Could not initialize SDL(No available video device) - exiting.
Is it possible to run qemu via ssh connection?
Note, I do not want to see the visual interface to the VM that I'm launching. I just want to to run.
Try qemu -curses
or qemu -nographic
to bypass the SDL
Best way to resolve this is to add -X to your ssh parameters.
e.g. ssh -X user#server
This will allow the window created by QEMU to be X-Forwarded through SSH to you. It doesn't matter if you want to view the window or not, if QEMU can't open it, it will consider it a fatal error and you will get the error you described.
You can disable the video card:
qemu -vga none (...options...)
You could also pipe the screen to VNC instead of SDL - the following will provide a VNC server on port 5901:
qemu -vnc :1 (...options...)
qemu-system-i386 -curses works like charm..
And to exit from that, use ESC + 2 then q + ENTER.
I had this problem too.
I think bitwise can't open a new terminal window like qemu does.
You can write make clean qemu-nox in terminal, instead of just make clean qemu and it will launch it in the same window.
This worked for me