i'm trying to use QEMU 5.x for research.
I got QEMU 5.2 source code from qemu.org and installed following instructions.
However, when i tried to run VM by this command:
qemu-system-x86_64 \
-monitor stdio \
--enable-kvm \
-m 4096 \
-cdrom ubuntu-20.04.iso \
-drive file=img.qcow,if=virtio \
-boot c
-rtc base=localtime \
-device virtio-keyboard-pci \
-vga virtio \
then the following texts are printed:
QEMU 5.2.0 monitor - type 'help' for more information
(qemu) VNC server running on 127.0.0.1:5900
then nothing shows up, while QEMU 4.x (used before) pops up a window showing guest ubuntu's GUI.
I'm using ubuntu 20.04. Hope anyone has breakthrough for this..
The message says that this QEMU is using the VNC protocol for graphics output. You can connect a VNC client to the 127.0.0.1:5900 port that it tells you about to see the graphics output.
If what you wanted was a native X11 window (GTK), then the problem is probably that you didn't have the necessary libraries installed to build the GTK support. QEMU's configure script's default behaviour is "build all the optional features that this host has the libraries installed for, and omit the features where the libraries aren't present". So if you don't have any of the GTK/SDL etc libraries when you build QEMU, the only thing you will get in the resulting QEMU binary is the lowest-common-denominator VNC support. If you want configure to report an error for a missing feature then you need to pass it the appropriate --enable-whatever option to force the feature to be enabled (in this case, --enable-gtk).
If you're running on Ubuntu and your apt sources.list file has deb-src lines in it, the easiest way to install all the dependencies that would get you the same feature list as the real Ubuntu QEMU package is to run "apt build-dep qemu". I recommend that you do that and then re-build QEMU, passing --enable-gtk to configure so you can confirm that the necessary dependencies were installed.
Host OS: Windows 10
Vagrant: 2.2.4
VirtualBox: 6.0.6 r130049
When I run vagrant up, it prints this error message:
The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!
setup
Stdout from the command:
Stderr from the command:
bash: line 4: setup: command not found
The machine can be booted normally and SSH from my host to Virtual machine is OK but the synced folder is not working. I know this may not be a critical issue but still feel frustrated as I use my host machine to develop codes and "sync" these codes so that they can be loaded in my virtual machine.
Any advice is highly appreciated.
ps: When I boot a full UI virtual machine (different from my above mentioned) from my VirtualBox directly, it seems OK to have a "sync" directory and the VBGuestAdditions can be installed without errors.
It is a bug in VirtualBox 6.0.6 and it still exists in 6.0.8. The solution is to downgrade your VirtualBox itself and the Guest Extensions to 6.0.4.
Trying to run the following command on VMFusion professional version 10.0.1:
vmrun -T fusion -gu user -gp pass runScriptInGuest /Path/On/Host/\ 10.12.vmwarevm/macOS\ 10.12.vmx /usr/bin/python /Path/On/Guest/a.py
Keep getting the following error:
Guest program exited with non-zero exit code: 1
Cannot find anything on this online.
Host: High-Sierra 10.13
Guest: Sierra 10.12.6
I updated the VM Tools as well.
Also, checked that the file does exists on VM and that running the script manually it does work
Any idea?
Thank you in advance!
Well, I found that the problem is the fact I was trying to run the python file, which is impossible on Mac.
What you need to do is to run the actual script inline!
E.G:
vmrun -T fusion -gu user -gp pass runScriptInGuest /Path/On/Host/\ 10.12.vmwarevm/macOS\ 10.12.vmx /bin/sh "/usr/bin/python -c \"`cat /Path/On/Host/To/Script`\"
So we will create a script on the host and cat it to the command!
I just upgraded to MacOS Sierra, and I realized that I can't seem to run the "ssh -X" command in the Terminal anymore. It used to launch xterm windows, but now it's like I didn't even put the -X option anymore. It was working absolutely fine right before I updated. Other than going from OS X Yosemite to MacOS Sierra, I didn't change anything else in the setup.
EDIT:
As suggested, this is what I found in the debug logs that might be causing this problem.
debug1: No xauth program.
Warning: untrusted X11 forwarding setup failed: xauth key data not generated
I didn't need to reinstall XQuartz, but, based on Matt Widjaja's answer, I came up with a refinement.
sudo vi /etc/ssh/ssh_config (This is ssh client config, not sshd_config)
Under the Host * entry add (or add where appropriate per-host)
XAuthLocation /usr/X11/bin/xauth (The location of xauth changed in Sierra)
ServerAliveInterval 60 (Pings the server every 60 seconds to keep your ssh connection alive)
ForwardX11Timeout 596h (Allows untrusted X11 connections beyond the 20 minute default)
No need to restart ssh, except, of course, existing ssh client connections.
It sounds like -Y (trusted X11) would be preferable to untrusted. If you switch over to trusted, the ForwardX11Timeout line can probably be removed.
The ServerAliveInterval line is also an optional preference.
It may also be possible to make these changes in ~/.ssh/config (the user's config file) but the permissions have to be correct.
EDIT: I removed ForwardX11 and ForwardX11Trusted. They aren't needed and ForwardX11 is less secure and causes problems for git (or other tools using ssh).
I noticed macOS Sierra resetted my X11 settings so that it disabled my xAuth program. To re-enable xAuth on macOS Sierra:
Reinstall X11/xQuartz to presumably reset any changes macOS Sierra made. I made the following changes below too although it sounds like this might be enough.
Load up a Terminal
sudo <text editor of your choice> /etc/ssh/sshd_config
In that file, uncomment the following lines, and set it to these values:
X11Forwarding yes
X11DisplayOffset 10
[Update on 10/07/2017] When you reinstall X11/XQuartz, above all else, it should add an: XAuthLocation <path_to_your_xauth> where mine was in /opt/X11/bin/xauth. This was probably the golden step that explained why reinstalling worked.
Restart ssh via the terminal. I did this by running:
sudo launchctl unload /System/Library/LaunchDaemons/ssh.plist
sudo launchctl load -w /System/Library/LaunchDaemons/ssh.plist
I'm having the same issues with X11 forwarding with the -X option after upgrading to Mac OS X Sierra.
Have a look at the ssh option -Y (trusted X11 forwarding). While using ssh -Y <host> things work for me.
It's an old question but I recently ran into the same issue on my Mac running 10.12.6. The DISPLAY variable is not set in the terminal and ssh -X doesn't work. This is what I did that solved the problem:
Reinstall XQuartz using Homebrew:
brew cask install xquartz (the option --forced may be necessary)
Add the XQuartz launcher to the system default (following the solution in this Reddit post:
launchctl load -w /Library/LaunchAgents/org.macosforge.xquartz.startx.plist
Restart the system.
After doing these, my DISPLAY variable is set properly:
$ echo $DISPLAY
/private/tmp/com.apple.launchd.mfXFpzZ0gC/org.macosforge.xquartz:0
And X11 forwarding in ssh works as well.
Just adding the one line XAuthLocation /usr/X11/bin/xauth to /etc/ssh/ssh_config works on my Mac, running MacOS Sierra, to ssh into a Linux host and be able to run X Windows programs remotely and have them display under XQuartz on my Mac.
My solution to this was the following.
(1) Launch xquartz before trying the ssh -X. In the xquartz options, I just enabled 'Open at login', and then it is always running in the background.
(2) Go to the xquartz Preferences menu, and on the Security window, click the box that says "Allow connections from clients".
After doing these things, everything works fine.
Just upgraded my macbook from El Capitan to Sierra. Simply reinstalling Xquartz has done the trick for me, using ssh -X [linux server]
I spent the whole day looking for solution only to realize that the recent Sierra does not ship with XQuartz installed https://support.apple.com/en-gb/HT201341. Upon install (https://www.xquartz.org/) all works.
If Quartz is installed, all that is needed is to add the line "X11Trusted yes" under "Host *" in the /etc/ssh/ssh_config file.
restarting XQuartz worked for me.
In my case, adding XAuthLocation /opt/X11/bin/xauth to /etc/ssh/sshd_config (note that it's not /etc/ssh/ssh_config) on macOS host worked after installing XQaurtz via brew install --cask xquartz as XQaurtz provide xauth binary
I am using the default Apache installation that comes with Snow Leopard and I have some things installed like MySQL, Rudix (Unix ports and packages) and Xcode.
When I type:
$ sudo apachectl start
I receive this output:
dyld: Symbol not found: _apr_dir_open$INODE64
Referenced from: /usr/local/sbin/httpd
Expected in: /usr/local/lib/libapr-1.0.dylib
in /usr/local/sbin/httpd
/usr/local/sbin/apachectl: line 78: 2023 Trace/BPT trap $HTTPD -k $ARGV
I don't know if it's related but my .bash_profile has this line (I typed it because import MySQLdb was not working in Python):
export DYLD_LIBRARY_PATH="/usr/local/mysql/lib/:$DYLD_LIBRARY_PATH"
If I tick Web Sharing using System Preferences the Apache starts and work, but I wan't to start it using the terminal, maybe I am forgot to pass important arguments to the apachectl command.
The Web Sharing option of System Preferences enables the Apple-supplied Apache. Its apachectl is /usr/sbin/apachectl. You appear to have installed another version of Apache in /usr/local; note the /usr/local/sbin/apachectl path. So you are not using the Apple-supplied Apache installation when you are running from the terminal and the version you are using appears to not have been installed correctly. One way to ensure you are using the Apple-supplied Apache is to specify the full path:
$ sudo /usr/sbin/apachectl start