Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 7 years ago.
Improve this question
I have installed virtualbox 4.3 (also version 5.x). There is no problem in installation. But When I run it via terminal. It gives following warning
WARNING: The vboxdrv kernel module is not loaded. Either there is no module
available for the current kernel (3.10.0-229.11.1.el7.x86_64) or it failed to
load. Please recompile the kernel module and install it by
sudo /etc/init.d/vboxdrv setup
You will not be able to start VMs until this problem is fixed.
When virtual machine starts and I select a VM, It gives following error.
Kernel driver not installed (rc=-1908)
The VirtualBox Linux kernel driver (vboxdrv) is either not loaded or there is a permission problem with /dev/vboxdrv. Please reinstall the kernel module by executing
'/etc/init.d/vboxdrv setup'
as root. If it is available in your distribution, you should install the DKMS package first. This package keeps track of Linux kernel changes and recompiles the vboxdrv kernel module if necessary.
When I run follwoing commad
sudo /etc/init.d/vboxdrv setup
This error appears
Stopping VirtualBox kernel modules [ OK ]
Uninstalling old VirtualBox DKMS kernel modulesError! There are no instances of module: vboxhost
4.3.30 located in the DKMS tree.
Error! There are no instances of module: vboxhost
4.3.30 located in the DKMS tree.
Error! There are no instances of module: vboxhost
4.3.30 located in the DKMS tree.
Error! There are no instances of module: vboxhost
4.3.30 located in the DKMS tree.
[ OK ]
Trying to register the VirtualBox kernel modules using DKMS[ OK ]
Starting VirtualBox kernel modules [FAILED]
(modprobe vboxdrv failed. Please use 'dmesg' to find out why)
And according to above guide, I run dmesg command and it shows following results at tail.
[ 77.790816] tun: (C) 1999-2004 Max Krasnyansky <maxk#qualcomm.com>
[ 77.826151] device virbr0-nic entered promiscuous mode
[ 77.916096] virbr0: port 1(virbr0-nic) entered listening state
[ 77.916105] virbr0: port 1(virbr0-nic) entered listening state
[ 77.916153] IPv6: ADDRCONF(NETDEV_UP): virbr0: link is not ready
[ 78.170824] virbr0: port 1(virbr0-nic) entered disabled state
[ 96.372599] fuse init (API version 7.22)
[ 116.798026] TCP: lp registered
[ 840.569814] warning: `VirtualBox' uses 32-bit capabilities (legacy support in use)
What is the problem, I am tring to solve it for about two months but nothing solve my problem.
Please guide and answer to the point as I am not an expert in such things.
I think, in BIOS setting, you should disable secure boots option is boot setting. It may solve your problem.
Related
I'v installed DC/OS v1.8.4, the destination node has gpu resources and nvidia driver has also been installed, I tried to deploy tensorflow in mesos container, but it failed, there is only one error message in mesos's stderr:
mesos-containerizer: error while loading shared libraries: libmesos-1.0.1.so: cannot open shared object file: No such file or directory
But I can deploy other services successfuly, such as nginx, wordpress (also in mesos container)
The problem may be caused by tensorflow image, in its parent image CUDA, it reset LD_LIBRARY_PATH :
ENV PATH /usr/local/nvidia/bin:/usr/local/cuda/bin:${PATH} ENV LD_LIBRARY_PATH /usr/local/nvidia/lib:/usr/local/nvidia/lib64
In OpenDCOS, before mesos-agent startup, it sets its executor's environment variable LD_LIBRARY_PATH to "/opt/mesosphere/lib", so that executor can locate necessary so files, but in above case, LD_LIBRARY_PATH is reset by tensorflow, so it failed to startup!
Anyone knows how OpenDCOS handle this problem ? Modify these public CUDA images?
GPUs are only officially supported in DC/OS 1.9+
For (unsupported) instructions on getting GPUs to work in 1.8, please see my answer to this question on the DC/OS mailing list:
https://groups.google.com/a/dcos.io/d/msg/users/HEgcUfRRqzk/inIBmapMCQAJ
Additionally, there is also a know issue with setting LD_LIBRARY_PATH in your container image for pre 1.9 clusters (though it usually manifests as a missing libssl.so library).
In your case, the CUDA container is setting LD_LIBRARY_PATH, which is overriding the LD_LIBRARY_PATH setting that DC/OS relies on to find it's library files. This is obviously a bug in DC/OS and has since been fixed in 1.9. The best (unsupported) workaround for this is to run
sudo ldconfig /opt/mesosphere/lib
on all of your nodes to put /opt/mesosphere/lib into the default library path. You will have to redo this on every reboot (or alternatively) add /opt/mesosphere/lib to a file under /etc/ld.so.conf.d/ to make it durable (maybe /etc/ld.so.conf.d/dcos.conf?).
This JIRA addressing the underlying issue can be found here:
https://issues.apache.org/jira/browse/MESOS-7027
I am using salt-stack to manage my production machine.
The minions run Raspbian and my and I have configured a systemd service. The services config file is located at /lib/systemd/system/my_service.service
When I run the following command:
sudo salt my_minion service.stop my_service
The following error is returned:
ERROR: Unable to run command ['/etc/init.d/my_service', 'stop'] with the context {'with_communicate': True, 'shell': False, 'env': {'LANG': 'en_GB.UTF-8', 'PATH': '/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin', 'LC_ALL': 'C'}, 'stdout': -1, 'close_fds': True, 'stdin': None, 'stderr': -2, 'cwd': '/root'}, reason: [Errno 2] No such file or directory
I understand that salt tries to use sysvinit instead of systemd.
Is there any way to tell salt to use systemd?
EDIT:
Tried adding
providers:
service: systemd
to /etc/salt/minion as suggested by Eric. Still getting the same error
EDIT 2
The issue was fixed by using Erics suggestion + upgrading salt-minion to 2015.8.8 from 2015.8.3
This is almost certainly because newer Raspbian is based off of Debian 8, and Salt's systemd execution module does not properly detect newer Raspbian as needing systemd. Can the OP please reply to this message with the output from sudo salt my_minion grains.items? Please redact any grains which you feel have personally-identifiable information, I'm mainly interested in the grains that deal with OS name and version.
EDIT: One more thing. Please confirm that /run/systemd/system exists on the Raspbian box. What I think is happening here is two modules are both claiming to be the ones to provide the service module.
https://github.com/saltstack/salt/pull/32421 should fix this, but you can work around this immediately (without waiting for a new Salt release) by adding the following to /etc/salt/minion on your Raspbian minions:
providers:
service: systemd
I am tying to work/setup the Systemtap tool for profiling OS procesess, on a Virtual Linux. I am using VirtualBox to run the image. Via
rpm -q kernel
and
cat /proc/version
The version obtained is:
Linux version 2.6.32-5-686 (Debian 2.6.32-48squeeze4)
I have correctly downloaded and installed the tool and wrote a simple program (.stp). However I keep getting the same error, which I have searched information in many places without success:
After executing:
sudo stap my_profiler.stp
I get:
semantic error: libdwfl failure (all kernel modules found): no error
Pass 3: translation failed. Try again with another '--vp 001' option.
According to https://sourceware.org/systemtap/SystemTap_Beginners_Guide/errors.html
semantic error: libdwfl failure
There was a problem processing the debugging information. In most cases, this error results from the installation of a kernel-debuginfo package whose version does not match the probed kernel exactly. The installed kernel-debuginfo package itself may have some consistency or correctness problems.
I have found no relevant information on the "kernel-debuginfo" package. I have also tried the verbose option without benefit. I even tried with an old Snapshot of the VM. Any ideas?
The code of the .stp program I ran:
probe timer.profile{
printf("Process: %s\n", execname())
printf("Process ID: %d\n", pid())
}
Found the problem!!!! It seemed that I was using the wrong version of the Linux Kernel. I was using the default kernel supplied by the version I wrote in the question. It seems that that version (the 2.6.32-5-686 one) has problems with the debug-info so all I did was try the same with another version (the Linux version 3.9.6 with gcc version 4.7.2 Debian 4.7.2-5) and it worked without trouble :)
Since it took me quite some time to figure out how to get Xtion (Primesense) to work on VMware I thought to share it here with you. (with Kinect I have a problem to let ROS see the device even though VMware has successfully connected it).
roslaunch openni2_launch openni2.launch
Running the above command gave me the error:
Warning: USB events thread - failed to set priority. This might cause loss of data...
I either got a single frame or no frame when running "rviz" and Add --> Image --> Image topic --> /camera/rgb/image_raw
So how do I get video frames in Ubuntu from a Primesense device while using a Virtual Machine (VMware)?
My specs
Windows 7 running VMware 10.0.4 build-2249910
Ubuntu 12.04.5 Precise in VMware
ROS Hydro
The following question pointed me in the right direction: http://answers.ros.org/question/77651/asus-xtion-on-usb-30-ros-hydro-ubuntu-1210/?answer=143206#post-id-143206
In the answer of blizzardroi (not selected answer) he/she mentions that USBInterface should be 0. I reasoned that since my main Machine is Windows, I should set UsbInterface to 1, which indeed solved it.
Solution
Go to /etc/openni2/ (from system folder, not Home) and open PS1080.ini with administrator rights (e.g. sudo gedit PS1080.ini). Search for UsbInterface, remove the ; and change the value to 1. It should look like below:
; USB interface to be used. 0 - FW Default, 1 - ISO endpoints (default on Windows), 2 - BULK endpoints (default on Linux/Mac/Android machines)
UsbInterface=1
Additional
From previous experience it may also be related that your Windows system may need the kinect drivers as well. If the above not works, try to install the following:
(Kinect SDK) https://www.microsoft.com/en-us/download/details.aspx?id=34808
(OpenNI2 Windows) http://structure.io/openni
p.s. Don't forget your drivers for Ubuntu (replace hydro with your ROS version)
sudo apt-get install ros-hydro-openni*
Important
It doesn't solve the error below, but rviz returns video, which means that we can read the data the Primesense device publishes!
Warning: USB events thread - failed to set priority. This might cause loss of data...
Got the same warning from opennni (issued at start by a binary located at Tools/PSLinkConsole) with another sensor.
Solved by starting process as sudo - my guess: to set priority to USB event threads you need root access. :)
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 6 years ago.
Improve this question
I have setup kvm, libvirt on one of Dell poweredge1000m blades. I am using the following syntax for installing a virtual machine from an existing image (executing as root).
virt-install --name=vm_test --ram=1024 --arch=i686 --vcpus=1 --os-type=linux --import --disk path=/root/shared.qcow2,bus=virtio,format=qcow2 --graphics vnc,port=5901,listen=0.0.0.0,password=newone --noautoconsole --description --autostart
I am getting the following error.
Starting install...
ERROR internal error process exited while connecting to monitor: char device redirected to /dev/pts/1
open /dev/kvm: Permission denied
failed to initialize KVM: Operation not permitted
Domain installation does not appear to have been successful.
If it was, you can restart your domain by running:
virsh --connect qemu:///system start vm_test
otherwise, please restart your installation.
I have used exactly the same command with one of other desktop hosts and it works there. I can install a VM from virt-manager using an ISO image with virt-manager storing the disk image at default location.
It seems like a file permissions error to me as it is not working with /vms directory but is working with some other /home/vm directory.
Thanks for help in advance
I got the same error message on a server, which has libvirt up for weeks.
Setting libvirt to run as root (as mentioned in the link) didn't work for me.
However, granting read & execute access to /var/lib/libvirt/images solved my problem.
chmod go+rx /var/lib/libvirt/images
chmod o-rwx /var/lib/libvirt/images/*
If you follow all the instructions on creating vm using libvirt, you may still meet the error message above. The root cause is AppArmor which can be found on recent Ubuntu distributions. The easiest way is to remove AppArmor if security is not a concern.
The official documentation of Ubuntu gives many advice on disable AppArmor:
Disable AppArmor
I had found the solution to my problem, here it is.
The real reason was that /vms was an NFS mount and its configuration(no_root_squash + rw) was such that it was required to be accessed over root.
By default libvirt runs a virtual machine with the user and group permissions of libvirt-qemu:kvm which would create trouble even if you run it with sudo privileges. So we need to set qemu process's user & group to root in /etc/libvirt/qemu.conf.
Also as others have pointed out, there can be multiple other reasons for this error and its sad that libvirt throws such a generic error.
The least frustrating solution is to give all permissions, disable selinux and make sure that it runs. Now one by one revoke the permissions testing that it works at each step and finally understanding why you were required to give the final set of permissions.
This can happen, if the modules were loaded too soon™ (the actual problem is not known to me, so please enhance this answer if you know it).
Just try to unload the modules and load them again. This did the trick for me:
rmmod kvm_intel # use kvm-amd if you use an amd processor.
rmmod kvm
modprobe kvm
modprobe kvm_intel # use kvm-amd if you use an amd processor.
I got this permission denied error on Arch. The problem turned out to be the access control list. Even though the Unix permissions showed group rw, getfacl showed group::---. This fixed it for me:
setfacl -m g::rw /dev/kvm
I confronted with this same problem. And after look into it, I found it is a problem of permission. You can just run the command below to deal with it:
chown root:kvm /dev/kvm
and you don't need to reboot.