I have Installed GTK on a Linux machine.
I am connecting To Linux Machine from a Telnet Session to compile the GTK programs
From A Windows Machine. I am using Cygwin on Windows Machine. but i am not able to see
GUI output of my GTK program on my Windows Machine.
When i run program from my terminal i get this error:
(helloworld:22576): Gtk-WARNING **: cannot open display:
I tried solutions from every answer posted, but no use now i am getting following error:
$ ./helloworld
Invalid MIT-MAGIC-COOKIE-1 key
(helloworld:22710): Gtk-WARNING **: cannot open display: 172.25.0.161:0
and i am getting following error on my Cygwin console:
client 6 rejected from IP 172.25.0.91 Auth name: MIT-MAGIC-COOKIE-1 ID: -1
You must set the DISPLAY variable in your telnet session to the IP address or DNS name of your Windows machine and append ":0"
export DISPLAY=windows.your.domain:0
And you must start an X server on the Windows machine (comes with Cygwin but you must start it).
You need to run the X window system (install with Cygwin) on your Windows-box and enable remote connections (probably with xhost). Set the DISPLAY-variable on your Linux-box to the address of your Windows-box and :0, as such:
export DISPLAY=192.168.1.123:0
I can recommend using ssh rather than telnet, for security reasons. In this case you do not need to enable remote connections with xhost, and you do not need to set the DISPLAY-variable. You only need to enable X forwarding.
You should install X-server on your windows machine and make sure you have DISPLAY set to yourmachine:0 or something like that. Or better yet use ssh instead of telnet (e.g. putty) and tunnel your X connection. You'll have to do a bit on your own research, though, because the complete answer would be a lengthy one.
Install an small X server on Windows XMing32, then run it, use putty as a console client, and check "X11 Forwarding" in Connection->SSH->X11.
Unfortunately, X11 Forwarding is not available through Telnet, you must run a SSH server on the target Linux and connect through SSH. (See if /etc/ssh/sshd_conf requires enabling X11 Forwarding too).
Related
I am running Centos 7 x86-64. I installed a guest (again Centos 7) through kickstart as an exercise. I prepared my kickstart file, I validated it and I launched with virt-install.
If something went wrong with the network configuration (During install I got no problem, I created a local repo on Host FTP server as source for the install) how can I connect to the machine?
Only SSH or virsh foresee some other connection method?
How can I find my machine running network configuration from outside?
I am running a barebone Centos7 installation so only command line, no graphical interface at all.
Thanks,
M.
You can ssh to your physical host from another one having graphical interface with X forwarding enabled (ssh -X machinename), and look at the the VM with virt-manager
You will need X running on the machine you're connecting from. For Mac OS it's XQuartz
Suppose I can log in to a gpu sever named gpu1.sp.sw, and there are gpu2.sp.sw and gpu3.sp.sw to which I cannot log in directly but can be reached by ssh gpu-2, ssh gpu-3, after I am already on gpu1.sp.sw.
My question is: If I want NSight 6.5 to run and debug remotely on gpu-2 or gpu-3, how can I do it?
As workaround you can use ssh tunnels: run something like
ssh gpu1.sp.sw -L2202:gpu2.sp.sw:22 -L2345:gpu2.sp.sw:2345 -nNT
in background console. Then configure NSight remote debugging to connect to server localhost, ssh port 2202 and cuda-gdbserver port 2345.
Problem: vagrant up fails with the error below. I am running vagrant on Windows 7 and the base box is Ubuntu )( files.vagrantup.com/precise32.box ).
how can it be fixed?
vagrant.bat up
Bringing machine 'default' up with 'virtualbox' provider...
[default] Clearing any previously set forwarded ports...
[default] Clearing any previously set network interfaces...
[default] Available bridged network interfaces:
1) Intel(R) PRO/1000 EB Network Connection with I/O Acceleration
2) Intel(R) PRO/1000 PL Network Connection
Vagrant is attempting to interface with the UI in a way that requires
a TTY. Most actions in Vagrant that require a TTY have configuration
switches to disable this requirement. Please do that or run Vagrant
with TTY.
Process finished with exit code 1
thanks
This worked for me on cygwin:
Or add this to ~/.bashrc:
export VAGRANT_DETECTED_OS=cygwin
Then I got the "Vagrant displays a message that it needs to run some internal upgrades..."
Edit - Oops! Spoke to soon. During its updates, I got Warning: Authentication failure. Retrying... until timeout :P
Edit 2 - I was able to fix it by setting config.ssh.private_key_path to the .vagrant.d/insecure_private_key in my Windows user's home directory.
I had the same error while destroying a Vagrant Box. I simply added -f and it did the job.
vagrant destroy m001 -f
This is happening because when script attempts vagrant destroy, Vagrant asks for [Yes/No] confirmation. Adding -f skips that.
I got the same error after upgrading Vagrant from 1.4 to 1.6.3 (Windows 7).
Running VAGRANT_HOME\bin\vagrant.exe manually resolved this issue for me:
Execute VAGRANT_HOME\bin\vagrant.exe
Vagrant displays a message that it needs to run some internal upgrades
"Press any key to continue"...
Once the process finished (it took several minutes), I was able to proceed with Vagrant instance launch as usual.
This is caused by Vagrant finding multiple Ethernet interfaces that can be used as public network and Vagrant cannot decide which one to use.
There are 3 options:
Deactivate one of the 2 adapters, so that Vagrant can use the other
Specify the Ethernet adapter you would like Vagrant to use in the vagrantfile. Like this:
app.vm.network "public_network", bridge: "Intel(R) PRO/1000 PL Network Connection"
Running the vagrant executable manually as already described in Al Belsky's answer
If you are on Windows and are starting Vagrant through MinGW (Git Bash for example) and get this message, try running it once through Windows' default cmd.exe. You are then able to answer the question about your network adapters.
I'm using Vagrant 1.7.4
Execute the below code before running vagrant up:
export VAGRANT_DETECTED_OS=cygwin
That will eliminate the exiting of vagrant and will allow you to choose Network Interface.
This may also be caused by not having Hardware Virtualization enabled in BIOS.
Also encountered this with Windows 10, when Vagrant cannot properly detect OS.
also can happen if you have both vmware and virtual box installed and you try to use MinGW.
I used to debug the Windows Kernel using VirtualKD, WinDBG and a single Virtual Machine.
Recently I got a Linux machine, and now I wonder- What's the easiest way to debug the Windows Kernel when your host is unable to run VirtualKD/WinDBG*?
I assume the solution will require two Virtual Machines, but I rather have two instances hosted on my actual machine rather than having an instance residing inside another virtual instance...
Is there anyway to make that work?
Thanks in advance!
*Wine is the last resort for stability reasons...
Solved! Basically, I ended up using two (VirtualBox) VMs emulating a Serial connection (null-modem cable) over a Unix domain socket (on the host). For more info, read below:
Hardware setup*:
Debuggee:
Ensure the machine is turned off and edit Serial Ports settings.
Enable Port 1, and assign values as follows: Port Number: COM1, Port Mode: Host Pipe, Create Pipe: Unchecked (client), Port/File Path: /tmp/win_link.
Debugger:
Same as above (using the same path), only this time Create Pipe should be Checked (server).
Debugger setup:
Run WinDBG and press Ctrl+K to invoke Kernel Debugging.
in COM, enter: Baudrate: 115200, Port: COM1, Resets: 0 and verify that Pipe and Reconnect are unchecked (important).
You'll be presented with the following output: Opened \\\\.\com1 Waiting to reconnect...
Debuggee setup:
Run bootcfg /debug on /port com1 /baud 115200 /id 1. To verify, run bootcfg.**
Reboot.
Quite early during the booting stage, WinDBG on the other machine should detect the debuggee is running.
*Assuming VirtualBox is used. VMWare/KVM users will probably be able to achieve the same results following similar steps. Also, for more info refer to the VirtualBox docs.
**Assuming guests are Windows XP. Later versions include bcdedit, which may be used as described here.
For QEMU\KVM follow those instructions:
http://www.linux-kvm.org/page/WindowsGuestDrivers/GuestDebugging
Very helpful but applies to Windows XP machines. You can refer to the following link if you need to configure 2 Windows7-based virtual machines on a Linux host: http://www.aldeid.com/wiki/Category:Digital-Forensics/Computer-Forensics/Debugger/Kernel
Another option nowadays is to enable local kernel debugging. This comes with some limitations, however it will enable you to access kernel data while just using one VM.
This approach only works on Windows 8.0 and Windows Server 2012 and later.
Follow these steps:
Open a Command Prompt window as Administrator.
Enter bcdedit /debug on
If the computer is not already configured as the target of a debug transport, enter bcdedit /dbgsettings local
Reboot the computer.
Once the system is rebooted, you can execute WinDBG as Administrator, press ctrl+k or go to File -> Attach to kernel -> Local and press OK.
At that point, you will be able to execute kernel-only commands and access kernel structures:
Tested under Windows 10 and with the new WinDBG version (preview).
Reference: Setting Up Local Kernel Debugging of a Single Computer Manually
I have the following configuration:
Host OS: Windows 7 SP1
Guest OS: Windows XP SP3 Pro
Guest OS is running inside VMWare Workstation version 7
I have configured a virtual serial port on the VM of type "output named pipe" and the following name:
\\.\pipe\whatever
I have also added the appropriate options to the boot.ini file on Win XP SP3 Pro image to allow for debugging (/debugport=com1 baudrate=115200)
in windbg, I configure the Kernel Debug option by going to:
File->Kernel Debug
and selecting the COM tab and configuring as follows:
Giving port name as:
\\.\pipe\whatever
and checking the Pipe box.
I boot up the Windows XP SP3 VM and select the second entry which has debug mode enabled. Right after I do this, I click on Ok inside the Windbg to start the kernel debugging session.
But even then it remains stuck at the following message:
Opened \.\pipe\whatever
Waiting to reconnect...
It says "Debuggee not connected" and stays at that message even after Virtual Machine boots up completely. The status of the Virtual Serial port in the VmWare also shows as Connected.
I have checked the network connections.
The VM has the Network Adapter in the Bridged Mode and I am able to ping the Guest OS and Host OS from each other successfully.
Your problem is likely to be that WinDbg isn't breaking on connect, so it's connected but it doesn't say so, and you think it's not working.
I had better luck running WinDbg from the command line with a -b, though I notice this option might have been removed in the later builds. I've tested with 6.12.0002.633 x86.
windbg -b -k com:pipe,port=\\.\pipe\com_1
(From here.)
I have had the same problem, and after changing the port at your windows guest (the one at the vmware) you should be connect. In my case the port at the boot.ini file was com1 and i have changed it to com2.
Did you also enable /debug in the boot.ini?
It could also be your VMWare serial port configuration. Config should be:
Use named pipe: \.\pipe\whatever
This end is the server.
The other end is an application.
Yield CPU on poll should be checked.
More info here:
http://www.vmware.com/support/ws5/doc/ws_devices_serial_advanced_example_debugging.html