I want to boot xv6(unix based os) on Qemu.I compile It from source code and also install qemu but when I type make qemu in terminal I get the following errors:
/usr/bin/qemu-system-i386 -serial mon:stdio -hdb fs.img xv6.img -smp 2 -m 512
Could not access KVM kernel module: No such file or directory
failed to initialize KVM: No such file or directory
Back to tcg accelerator.
but qemu runs (with flicks) and write : no bootable device
I am also read this discussion in SO but doesn't solve my problem.
Note:first qemu can't find QEMU executable and according to this link I solve my problem by changing the #QEMU= with QEMU = /usr/bin/qemu-system-i386 then I have this problem.
EDIT:I finally find the solution.my XV6 source code has a problem(that I don't know what?) then I download it from MIT OS course with this commands:
git clone git://pdos.csail.mit.edu/xv6/xv6.git
cd xv6/
make
qemu-system-i386 -serial mon:stdio -hdb fs.img xv6.img -smp 1 -m 512
i had something similar. are you using a makefile perhaps when you compile?
from some reason for me it didn't recognize some of the time where the file sign.pl was because it was written "./sign.pl" and not /./sign.pl
also make sure to have all of your files with all of the permission required (for example: chmod 700 *)
Related
I am trying to build all CUDA samples by running make in the sample's base folder. One of the samples require mpi.h, but the system did not have it, which causes an error:
make[1]: Entering directory '$HOME/cuda_samples/samples/0_Simple/simpleMPI'
/bin/mpicxx -I../../common/inc -o simpleMPI_mpi.o -c simpleMPI.cpp
simpleMPI.cpp:25:10: fatal error: mpi.h: No such file or directory
25 | #include <mpi.h>
| ^~~~~~~
compilation terminated.
make[1]: *** [Makefile:371: simpleMPI_mpi.o] Error 1
Since I don't have root privilege, I downloaded a deb file for libopenmpi-dev package (using apt-get download command) and extracted it to somewhere in my user space (using dpkg -x command). However, as we can see, mpicxx tries to find mpi.h in ../../common/inc, which is not where I installed libopenmpi-dev in my user space (I did not notice that untill I installed the package. My bad). So I need to somehow tell mpicxx to find mpi.h in another directory. I know there is a -I option to tell make where additional include directories are, but this option does not apply to mpicxx. How to pass directory information from make's command line to mpicxx is beyond my knowledge. Can you please teach me what option I should use in make's command line to specify include directory used by mpicxx? Of course I can manually copy the installed libopenmpi-dev package to ../../common/inc to accommodate original settings in CUDA sample, but I would like to do something cool and learn something new, so I ask here. Thank you in advance for teaching me.
Environment:
Remote Linux with core version 5.8.0. I am not a super user.
CUDA version: 11.2
CPU: Intel Core i9-10900K
gcc version: (Ubuntu 10.2.0-13ubuntu1) 10.2.0
make version: GNU Make 4.3, Built for x86_64-pc-linux-gnu
MPI version: 4.0.3
The include directory in Makefile is held in a variable INCLUDES, together with -I. So, if we can somehow transfer the include directory of mpi installed in my user space to this variable, we are done. So, the question is reduced to how to transfer a user-defined value from make's command line into Makefile's variable and override it if it has be defined, as is clearly asked in the question.
Fortunately make provides this command line option: VAR=value, so the option to answer my question is
make INCLUDES=-I/path/to/mpi/include/in/my/user/space
I know that I can install Cuda with the following:
wget http://developer.download.nvidia.com/compute/cuda/7_0/Prod/local_installers/cuda_7.0.28_linux.run
chmod +x cuda_7.0.28_linux.run
./cuda_7.0.28_linux.run -extract=`pwd`/nvidia_installers
cd nvidia_installers
sudo ./NVIDIA-Linux-x86_64-346.46.run
sudo modprobe nvidia
sudo ./cuda-linux64-rel-7.0.28-19326674.run
Just wondering if I can install Cuda without root?
Thanks,
Update The installation UI for 10.1 changed. The following works:
Deselect driver installation (pressing ENTERon it)
Change options -> root install path to a non-sudo directory.
Press A on the line marked with a + to access advanced options. Deselect create symbolic link, and change the toolkit install path.
Now installation should work without root permissions
Thank you very much for the hints in the question! I just want to complete it with an approach that worked for me, also inspired in this gist and that hopefully helps in situations where a valid driver is installed, and installing a more recent CUDA on Linux without root permissions is still needed.
TL;DR: Here are the steps to install CUDA9+CUDNN7 on Debian, and installing a pre-compiled version of TensorFlow1.4 on Python2.7 to test that everything works. Everything without root privileges and via terminal. Should also work for other CUDA, CUDNN, TensorFlow and Python versions on other Linux systems too.
INSTALLATION
Go to NVIDIA's official release web for CUDA (as for Nov. 2017, CUDA9 is out): https://developer.nvidia.com/cuda-downloads.
Under your Linux distro, select the runfile (local)option. Note that the sudo indication present in the installation instructions is deceiving, since it is possible to run this installer without root permissions. On a server, one easy way is to copy the <LINK> of the Download button and, in any location of your home directory, run wget <LINK>. It will download the <INSTALLER> file.
Run chmod +x <INSTALLER> to make it executable, and execute it ./<INSTALLER>.
accept the EULA, say no to driver installation, and enter a <CUDA> location under your home directory to install the toolkit and a <CUDASAMPLES> for the samples.
Not asked here but recommended: Download a compatible CUDNN file from the official web (you need to sign in). In my case, I downloaded the cudnn-9.0-linux-x64-v7.tgz, compatible with CUDA9 into the <CUDNN> folder. Uncompress it: tar -xzvf ....
Optional: compile the samples. cd <CUDASAMPLES> && make. There are some very nice examples there and a very good starting point to write some CUDA scripts of yourself.
(If you did 5.): Copy the required files from <CUDNN> into <CUDA>, and grant reading permission to user (not sure if needed):
cp -P <CUDNN>/cuda/include/cudnn.h <CUDA>/include/
cp -P <CUDNN>/cuda/lib64/libcudnn* <CUDA>/lib64
chmod a+r <CUDA>/include/cudnn.h <CUDA>/lib64/libcudnn*
Add the library to your environment. This is typically done adding this following two lines to your ~/.bashrc file (in this example, the <CUDA> directory was ~/cuda9/:
export PATH=<CUDA>/bin:$PATH
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:<CUDA>/lib64/
FOR QUICK TESTING OR TENSORFLOW USERS
The quickest way to get a TensorFlow compatible with CUDA9 and CUDNN7 (and a very quick way to test this) is to download a precompiled wheel file and install it with pip install <WHEEL>. Most of the versions you need, can be found in mind's repo (thanks a lot guys). A minimal test that confirms that CUDNN is also working involves the use of tf.nn.conv2d:
import tensorflow as tf
x = tf.nn.conv2d(tf.ones([1,1,10,1]), tf.ones([1,5,1,1]), strides=[1, 1, 1, 1], padding='SAME')
with tf.Session() as sess:
sess.run(x) # this should output a tensor of shape (1,1,10,1) with [3,4,5,5,5,5,5,5,4,3]
In my case, the wheel I installed required Intel's MKL library, as explained here. Again, from terminal and without root users, this are the steps I followed to install the library and make TensorFlow find it (reference):
git clone https://github.com/01org/mkl-dnn.git
cd mkl-dnn/scripts && ./prepare_mkl.sh && cd ..
mkdir -p build && cd build
cmake -D CMAKE_INSTALL_PREFIX:PATH=<TARGET_DIR_IN_HOME> ..
make # this takes a while
make doc # do this optionally if you have doxygen
make test # also takes a while
make install # installs into <TARGET_DIR_IN_HOME>
add the following to your ~/.bashrc: export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:<TARGET_DIR_IN_HOME>/lib
Hope this helps!
Andres
You can install using conda with the following command.
conda install -c anaconda cudatoolkit
But you need to have prior accesss to the device(GPU).
EDIT : If you are finding error in anaconda repository then change the repository to conda-forge which is frequently updated.
conda install -c conda-forge cudatoolkit
You can install CUDA and compile programs, but you won't be able to run them for a lack of device access.
I'm trying to use cuda to accelerate tensorflow. I'm running tensorflow using the docker image.
Firstly, when I launch the gpu image, it has a mismatch in the LT_LIBRARY_PATH environment variable:
~# echo $LD_LIBRARY_PATH
/usr/local/nvidia/lib:/usr/local/nvidia/lib64:
root#d578acbbc2cd:~# ls /usr/local/
bin cuda cuda-7.0 etc games include lib man sbin share src
There's no nvidia directory there. When I try to run the convolutional.py demo, it can't initialise the cuda support:
# python models/image/mnist/convolutional.py
Succesfully downloaded train-images-idx3-ubyte.gz 9912422 bytes.
Succesfully downloaded train-labels-idx1-ubyte.gz 28881 bytes.
Succesfully downloaded t10k-images-idx3-ubyte.gz 1648877 bytes.
Succesfully downloaded t10k-labels-idx1-ubyte.gz 4542 bytes.
Extracting data/train-images-idx3-ubyte.gz
Extracting data/train-labels-idx1-ubyte.gz
Extracting data/t10k-images-idx3-ubyte.gz
Extracting data/t10k-labels-idx1-ubyte.gz
I tensorflow/core/common_runtime/local_device.cc:25] Local device intra op parallelism threads: 8
modprobe: ERROR: ../libkmod/libkmod.c:556 kmod_search_moddep() could not open moddep file '/lib/modules/4.2.0-23-generic/modules.dep.bin'
E tensorflow/stream_executor/cuda/cuda_driver.cc:466] failed call to cuInit: CUDA_ERROR_UNKNOWN
I tensorflow/stream_executor/cuda/cuda_diagnostics.cc:98] retrieving CUDA diagnostic information for host: d578acbbc2cd
I tensorflow/stream_executor/cuda/cuda_diagnostics.cc:106] hostname: d578acbbc2cd
I tensorflow/stream_executor/cuda/cuda_diagnostics.cc:131] libcuda reported version is: Not found: was unable to find libcuda.so DSO loaded into this program
I tensorflow/stream_executor/cuda/cuda_diagnostics.cc:242] driver version file contents: """NVRM version: NVIDIA UNIX x86_64 Kernel Module 352.68 Tue Dec 1 17:24:11 PST 2015
GCC version: gcc version 5.2.1 20151010 (Ubuntu 5.2.1-22ubuntu2)
"""
I tensorflow/stream_executor/cuda/cuda_diagnostics.cc:135] kernel reported version is: 352.68
I tensorflow/core/common_runtime/gpu/gpu_init.cc:112] DMA:
I tensorflow/core/common_runtime/local_session.cc:45] Local session inter op parallelism threads: 8
It then goes on to train using cpu only.
# find /usr -name libcuda.so
/usr/lib/x86_64-linux-gnu/libcuda.so
So in the docker image, there's only the gnu cpu cuda implementation. No NVIDIA stuff. In the host ubuntu 15.10 session, I have libcuda.so installed:
$ find /usr -name libcuda.so
/usr/lib/x86_64-linux-gnu/libcuda.so
/usr/lib/i386-linux-gnu/libcuda.so
/usr/local/cuda-7.5/targets/x86_64-linux/lib
/stubs/libcuda.so
So these seem to be stubs ... not sure why.
Is there some trick to getting this to work?
Try rebuilding the Docker image directly from the Tensorflow repository (i.e. don't rely on the image on the container registry) and use https://github.com/NVIDIA/nvidia-docker to run the container (the Docker command described in the Tensorflow documentation is not portable).
I had a similar problem, though not in docker. The libcuda.so in /usr/local/cuda/lib64/stubs was a broken sym link. When I searched for libcuda.so it only turned up a file in a lib32 folder.
It seems that the problem was how I originally installed the NVIDIA device driver. At some point in the driver install process you're given the option to install the lib32 drivers. I had thought this meant in addition to lib64 drivers so I selected it. Turns out it only installs lib32 and not lib64 drivers.
I reinstalled the NIVDIA device driver, this time not selecting the lib32 'option'. Now tensorflow finds libcuda.so.
I had the same problem with running tensorflow on a Ubuntu machine after I upgraded my driver to 352.63 and 352.93. (I remember it works with 346.* but when I try to install 346., it installs 352. automatically for some reason).
I finally figured out that it's caused by permission issue. (I can run it with root) So, I changed the permission of the libcuda.so.352-63 file to executable by anyone and it works well now.
Hope this will be helpful to those still struggling with this issue.
I didn't try the docker one, but I guess it's also caused by permission setting.
Try this command
sudo apt-get install nvidia-modprobe
As mentioned here:
https://github.com/tensorflow/tensorflow/issues/394
and
http://kkjkok.blogspot.in/2016_08_01_archive.html
After I updated NVIDIA driver to 378.09 on Ubuntu 14.10 I had the same error,
although all the right for lib files were set correctly.
Thanks to #PhoenixQ, I tried to run with sudo and it worked.
After that I tried to run without sudo one more time and error disappeared. I'm not sure what ecxactly happened, but maybe something was configured during call with sudo, which was not possible withous sudo.
So the solution:
Try to run the same thing with sudo.
After this. Tryu running without sudo. Worked for me.
I am setting up Kubernetes on coreOS, on GCE. However, it is not going through due to the SDK dependency on Python. I downloaded python and tried installing it, but it is looking for a C compiler. Unfortunately I couldn't get one. Could someone help with this?
Below is the link I am following to set this up
https://github.com/rimusz/coreos-multi-node-k8s-gce/blob/master/README.md
You're probably better off using a cloud-init file that curls, installs and runs each binary for kubernetes as a systemd unit. So each would look like:
- name: kube-apiserver.service
command: start
content: |
[Unit]
Description=Kubernetes API Server
Documentation=https://github.com/GoogleCloudPlatform/kubernetes
Requires=etcd2.service setup-network-environment.service
After=etcd2.service setup-network-environment.service
[Service]
EnvironmentFile=/etc/network-environment
ExecStartPre=-/usr/bin/mkdir -p /opt/bin
ExecStartPre=/usr/bin/curl -L -o /opt/bin/kube-apiserver -z /opt/bin/kube-apiserver https://storage.googleapis.com/kubernetes-release/release/v0.18.2/bin/linux/amd64/kube-apiserver
ExecStartPre=/usr/bin/chmod +x /opt/bin/kube-apiserver
ExecStartPre=/usr/bin/curl -L -o /opt/bin/kubectl -z /opt/bin/kubectl https://storage.googleapis.com/kubernetes-release/release/v0.18.2/bin/linux/amd64/kubectl
ExecStartPre=/usr/bin/chmod 755 /opt/bin/kubectl
ExecStart=/opt/bin/kube-apiserver --portal_net=10.244.0.0/16 --etcd_servers=http://127.0.0.1:4001 --logtostderr=true --insecure_port=8080 --insecure_bind_address=0.0.0.0
Restart=always
RestartSec=10
And similar for each other binary. Just make sure you set them up to follow the chain of dependencies. This way the binaries are already compiled, compiling is something that coreos isn't exactly designed for.
I'mt trying to run beaglebone image on qemu following this tutorial. im using ubuntu 14.04 and installed qemu as shown in the tutorial
when ruining the command
qemu-system-arm -M beaglexm -drive if=sd,cache=writeback,file=Angstrom-TI-GNOME-image-eglibc-ipk-v2012.01-core-beagleboard-2012.01.11.img -clock unix -serial stdio -device usb-kbd -device usb-mouse -usb -device usb-net,netdev=mynet -netdev user,id=mynet
I got this error :
qemu-system-arm: symbol lookup error: qemu-system-arm: undefined symbol: libusb_get_port_numbers
I dont know if it's libusb version issue or what.
There is a similar bug report on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=711589
I had the same message on my system. To solve it you have, as root, to link in the correct libusb.
sudo ln -sf /lib/x86_64-linux-gnu/libusb-1.0.so.0 /usr/local/lib/libusb-1.0.so.0
Start by running (YMMV on where the 'qemu' binaries are located):
ldd /usr/bin/qemu-system-arm
You should get a lot of output indicating what runtime libs Qemu needs and where the system is finding them. The fact that you are getting a 'missing symbol' error means that a shared library is on the system, it just isn't exporting the 'libusb_get_port_numbers' function signature.
If the above is true, then either A) your distro's 'libusb' packages don't export that function (it might have been deprecated) or B) you have some other 3rd party application that installed it's own 'libusb' (MPLABX does this, puts it in /usr/local/lib and symlinks back to /opt/microchip).
Without any more OS info etc, it's hard to help.