I am installing CUDA on my GPU machines. While at it, I need to disable Nouveau Kernel Driver.
I did find a solution here: https://askubuntu.com/questions/841876/how-to-disable-nouveau-kernel-driver
But update-initramfs is not found on CentOS.
I am looking for an equivalent of sudo update-initramfs -u in CentOS
If your goal is to install the latest nvidia driver to run with cuda. The best way to disable nouveau is indeed to rebuild the initramfs, as written by Gediz. Since, as spotted here (https://forums.centos.org/viewtopic.php?t=68800), it is only a 5 steps process I think it deserves to be right here :
grubby ––update-kernel=ALL ––args="rd.driver.blacklist=nouveau nouveau.modeset=0"
mv /boot/initramfs-$(uname -r).img /boot/initramfs-$(uname -r).img.bak
echo "blacklist nouveau" > /etc/modprobe.d/nouveau-blacklist.conf
dracut /boot/initramfs-$(uname -r).img $(uname -r)
reboot
I believe Nouveau driver can be easily unloaded using modprobe:
modprobe -r nouveau
Also there is an option -b which blacklists it.
-b, --use-blacklist Apply blacklist to resolved alias.
In the web address you attached there is :
option nomodeset
I guess it is a kernel option not to load !ANY display drivers.You wont always need to update initramfs, only if module is included in initramfs you need to update it.
You can check it using one of initramfs-tools by :
lsinitramfs /boot/initrd.img-4.9.0-5-amd64 |less
However if you need to update or rebuild initramfs there is a way shown in CentOs Wiki :
https://wiki.centos.org/TipsAndTricks/CreateNewInitrd
Related
After exporting .Ova file, containing .ovf and .vhd resources, I'am facing errors during
boot of the VM in VirtualBox/VmwarePlayer. Output ad follow
'''
root (hd0,0)
Filesystem type is ext2fs, partition type 0x83
kernel /vmlinuz-2.6.18-419.el5xen ro root=/dev/VolGroup00/LogVo100 console=xvc0
Error 13: Invalid or unsupported executable format
'''
I found the problem. It is related to the custom Xen kernel.
A fix can be found by installing a new kernel, disabling console on /etc/inittab and enabling tty.
Current kernel installed packages
<code># rpm -qa | grep ‘kernel’'</code>
Download the latest RPM
In my case I had to find it because the CentOs is very old
Checking the RPM signature
<code>#rpm -K *rpm</code>
Install/Update non-kernel RPMs (optional in my case)
<code> rpm -Uvh mkinitrd.rpm SysVinit.rpm initscripts.rpm </code>
(optional, for kernel developers)
<code>#rpm -Uvh kernel-headers.rpm kernel-source.rpm</code>
Install Kernel
<code>#rpm -ivh kernel-2.6.18-420.el5.x86_64.rpm</code>
*Note: Use ivh option "install" because Uvh option "Update" will delete previous installed kernel, which may need in case of any unsuccessful update.
Creating Initial RAM disk (optional, only if system has SCSI controllers/SCSI hard drive)
<code>#ls -l /boot/initrd-* </code>
If you can find an image for the currently running kernel, you need to proceed with this command for creating new initrd image for the new kernel:
<code>#mkinitrd /boot/initrd-2.2.17-14.img 2.2.17-14</code>
Verify the grub configuration "/etc/grub.conf"
Grub will be automatically configured with the new kernel upon RPM installation
Anyway if multiple kernels are avaible, you could specify on boot which one you want to use.
In grub.conf, the value “0” to “default” indicates that it will boot from the first kernel mentioned.
Edit /etc/inittab , This file defines three important items for the init process:
The system's default run level
What processes to start, monitor, and restart if they terminate
What actions to be taken when the system enters a new run level
Initializes console and identifies the terminal type
We are going to comment console line and uncomment text-only terminals as follows
##comment this##co:2345:respawn:/sbin/agetty xvc0 9600 vt100-nav
1:2345:respawn:/sbin/mingetty tty1
2:2345:respawn:/sbin/mingetty tty2
3:2345:respawn:/sbin/mingetty tty3
4:2345:respawn:/sbin/mingetty tty4
5:2345:respawn:/sbin/mingetty tty5
6:2345:respawn:/sbin/mingetty tty6
Reboot the Macchine
In my case, after this operations I've been able to export and start the Vm on VirtualBox avoiding the previous error mentioned.
I cannot execute any command using sudo. I get this error
-sh: sudo: command not found
First: if you are already root, you do not need sudo.
Second: if this is a yocto-based image as the question tag suggests, then there is no apt-get either. This is the "debianoid" way of installing things and does not apply to prebuilt-image based distributions as yocto provides them. So you have two options:
Change to ubuntu or debian (or any derivative thereof), then this approach will apply.
Use the yocto/OpenEmbedded way of installing things. This is unfortunately not exactly trivial, so you better get started here then: Yocto Projct Quick Start
Maybe you need to check the user you log in.
If you are the root user, you have the super access right yet.
If not, you need to change your configuration in your yocto project like this
EXTRA_USERS_PARAMS = "\
usermod -p 'passowrd' root; \
"
I need to update DBus on my Raspberry Pi, in order to upgrade to the latest Bluez version (and I hope for performance benefits). I can't use a package install, as the latest packaged version is old, so I "configure/make/make install".
The problem with this is that it appears to install alongside the old version, but in a different directory. So, if I run dbus-daemon --version, I see the old version number following the install.
The original version (and launch path) is /usr/bin, whereas my install is going to /usr/arm-linux-gnueabi/bin. I did try editing the path for launch in /lib/systemd/system/dbus.service, but after this, Linux failed to start.
So now I have two versions of dbus on my Pi, with the old one booting.
Any help would be greatly appreciated.
Here is what I did to successfully have D-Bus 1.10.18 on my Raspberry Pi 3 with Raspbian Jessie Lite Fresh (release 2017-04-10) :
[I use aptitude instead of apt-get. You can substitute one by another.]
sudo aptitude install -y libapparmor1
cd ~
wget http://ftp.fr.debian.org/debian/pool/main/d/dbus/libdbus-1-3_1.10.18-1_armhf.deb
sudo dpkg --auto-deconfigure -i libdbus-1-3_1.10.18-1_armhf.deb
wget http://ftp.fr.debian.org/debian/pool/main/d/dbus/dbus_1.10.18-1_armhf.deb
sudo dpkg -i dbus_1.10.18-1_armhf.deb
sudo reboot
and after reboot :
pi#RasPi3-Tests:~ $ dpkg -l dbus
Souhait=inconnU/Installé/suppRimé/Purgé/H=à garder
| État=Non/Installé/fichier-Config/dépaqUeté/échec-conFig/H=semi-installé/W=attend-traitement-déclenchements
|/ Err?=(aucune)/besoin Réinstallation (État,Err: majuscule=mauvais)
||/ Nom Version Architecture Description
+++-=======================-================-================-===================================================
ii dbus 1.10.18-1 armhf simple interprocess messaging system (daemon and ...
and :
pi#RasPi3-Tests:~ $ dbus-daemon --version
D-Bus Message Bus Daemon 1.10.18
Copyright (C) 2002, 2003 Red Hat, Inc., CodeFactory AB, and others
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Before answering your question, share the failure log from "journalctl -xe" or "systemctl status dbus". Following might solve your problem,
Make sure to stop the dbus before update it. "systemctl stop dbus"
systemctl daemon-reload (Needs to run after changing service file of any daemon)
Start dbus again, systemctl start dbus.
check the binary path available in "echo $PATH", if not, export it. In your case, export PATH=/usr/arm-linux-gnueabi/bin:$PATH should help
Note: Many applications will stop working when you stop dbus.
sudo apt-get install python3-dbus
I am trying to configure LIRC to work with my Raspberry 2B and a circuit I build with a transistor and a IR transmitter as explained in this tutorial
After the installation of LIRC, I followed all the steps and I added these two lines in /etc/modules
lirc_dev
lirc_rpi gpio_out_pin=36
Then I typed this in /etc/lirc/hardware.conf
LIRCD_ARGS="--uinput"
LOAD_MODULES=true
DRIVER="default"
DEVICE="/dev/lirc0"
MODULES="lirc_rpi"
LIRCD_CONF=""
LIRCMD_CONF=""
After rebooting, I added the configuration of my Samsung remote (BN59-00516A) to /etc/lirc/lircd.conf
Then I restarted LIRC again but when I run a command to send a IR frequency
irsend SEND_ONCE Samsung_BN59-00865A KEY_POWER
it complains with the following error:
irsend: could not connect to socket
irsend: No such file or directory
I am guessing this is a problem with my device socket, because in the hardware.conf file I set
DEVICE = "/dev/lirc0"
(just because the tutorial states it), but lirc0 file isn't within the folder.
I couldn't find any other question related to this problem and google didn't help me much either. Does anyone have any hint on this?
After googling a lot, I found out an update is needed to have everything working properly. In my case I did:
apt-get update, apt-get upgrade, rpi-update
Also, as pointed out in this other tutorial, depending on the Raspberry firmware, you might need to add this to /boot/config.txt
dtoverlay=lirc-rpi,gpio_in_pin=XX,gpio_out_pin=YY
Substitute X and Y for whatever pins you're using!
I had a similar problem and I solved it with this command:
sudo lircd --device /dev/lirc0
If you set the value of LIRCD_ARGS in /etc/lirc/hardware.conf to "--device /dev/lirc0", it should start lircd appropriately, when /etc/init.d/lirc is started at boot.
you need to run lircd. It will create two files (lircd and lircd.pid) at /var/run/lirc/:
lircd
I got the same error messages. But had all configurations done. The restart of the lirc daemon solved this issue by typing
$ sudo /etc/init.d/lirc restart
I think is useful to say that the gpio_in_pin=XX,gpio_out_pin=YY part of the /etc/modules can be double checked with
dmesg | grep lirc
which results in something like
[ 3.437499] lirc_dev: IR Remote Control driver registered, major 244
[ 5.472916] lirc_rpi: module is from the staging directory, the quality is unknown, you have been warned.
[ 6.621156] lirc_rpi: auto-detected active high receiver on GPIO pin 22
[ 6.622515] lirc_rpi lirc_rpi: lirc_dev: driver lirc_rpi registered at minor = 0
[ 6.622528] lirc_rpi: driver registered!
for /etc/modules containing
lirc_dev
lirc_rpi gpio_in_pin=23 gpio_out_pin=22
This is really frustrating me. I have a DO VPS with ubuntu 14.04 (64) installed.
I installed VestaCP as control panel on that and have hosted some PHP based personal project.
I also installed meteor on it but never used, now when I am trying to create a project and run it ('meteor create rt' then 'cd rt' then 'meteor')
It is giving the following error :
[[[[[ /home/admin/code/rt ]]]]]
=> Started proxy.
Unexpected mongo exit code 1. Restarting.
Unexpected mongo exit code 1. Restarting.
Unexpected mongo exit code 1. Restarting.
Can't start Mongo server.
root#RD:/home/admin/code/rt#
Could anyone please help? Please ask me for more informations if required.
**** EDIT ****
I created a fresh DigitalOcean server and it is giving the same error on that. Some issue with Digital Ocean? File System of Digital Ocean? I am confused. I am trying it on different flavours of Linux and same result. All are fresh linux installations.
I finally got the solution. Posting it here for others.
This was the problem as a few environment variables which mongodb looks for while starting was not set
Set the variables LC_ALL and LANG and it works fine (mostly setting LC_ALL will do)
first, type locale command and see the output, you will see that it will say something about LC_ALL not set.
Now, add these two lines in /etc/environment and it worked.
LC_ALL=en_US.UTF-8
LANG=en_US.UTF-8
This solution is for Ubuntu 12.04 +
Other variants may require similar work.
Unexpected mongo exit code 1 is still an uncaught exception as far as i think.
You can try by updating your c/c++ compilers uptodate. Have a look here.
It says :
sudo add-apt-repository ppa:ubuntu-toolchain-r/test
sudo apt-get update
sudo apt-get install gcc-4.6
sudo apt-get install g++-4.6
All the best!
So we have narrowed the issue down to meteor's mongo installation on your box (though I think we were pretty sure of this all along). Let's attempt to debug that a bit. The way I have done this in the past is to try to open meteor's mongo with the mongod provided by meteor. You will perform these procedures without running the meteor server. This should give you the warning that is causing Mongo to exit. First you need to find this. In my instance installed on Mint (which should be similar to Ubuntu) it is at:
~/.meteor/packages/meteor-tool/.1.1.3.4sddkj++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/dev_bundle/mongodb/bin/mongod
You can look at that location on your Ubuntu box or you can run something like this to get the location:
find ~/.meteor/ -name mongod
Once you find the location then go to the directory of your meteor project you are attempting to run and in that directory you should find this location:
<your meteor project>/.meteor/local
cd into that directory and run the following command:
~/.meteor/packages/meteor-tool/.1.1.3.4sddkj++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/dev_bundle/mongodb/bin/mongod --dbpath ./
From there you can analyze the output (or update the question so we can see the output) and this should show you the mongo error you are receiving on startup and allow you to fix it.
I've got the same issues trying to start a meteor app and exactly the mongodb server is being terminated in an unexpectly manner. Generally the virtual linux server from some dealers like the one you mentioned are coming without a swap partition (check in /etc/fstab file) so if you have not enough memory to allocate MongoDB server then meteor app can't be started. You can create a swap partition or instal swapspace
sudo apt-get install swapspace
After that I was able to start the meteor app... Just be patient as swap memory is not as faster as RAM.
Since due some "smart" StackExchange policy I cannot up-vote or comment to working solution...)
Quoted answer works also on Digital Ocean on CentOS 7 x64 vmlinuz-3.10.0-123.8.1.el7.x86_64
first, type locale command and see the output, you will see that it will say something about LC_ALL not set.
Now, add these two lines in /etc/environment and it worked.
I changed the locale setting to match my needs.
Fixed on my Debian 8 with the following bash command, (use sudo if needed)
localedef -i en_US -f UTF-8 en_US.UTF-8