I am currently working on centos running on intel atom board. I mistakenly renamed lic-2.17.so to _libc-2.17.so
library on my board, when I reboot the board it is giving me below error.
[ OK ] Reached target Initrd Default Target.
systemd-journald[136]: Received SIGTERM
Kernel panic - not syncing: Attempted to kill init! exitcode=0x00007f00
Is there any possible way to get back to the original state.
I entered into grub prompt and able to see cat /lib64/_libc-2.17.so. Not Sure,
how to rename this to original name
Thanks in advance.
Can you enter run-level 3 from grub?
if so,
sudo mv /lib64/_libc-2.17.so /lib64/libc-2.17.so
if you can't enter run-level 3, you can try using a live DVD/USB to run the above command, you're just going to have to manually search for the right partition which the incorrectly named file is located.
Otherwise, I'm afraid you're going to need to reinstall the OS.
Related
We are running the latest raspibian on the raspberry pi board and have a kernel driver for a USB peripheral which is added externally (sudo insmod driverx.ko) after boot-up by connecting to the hardware using ssh (its a headless system).
The problem is as follows:
If the device is already connected to the system upon power-up then running sudo insmod driverx.ko leads to the terminal getting stuck (no response, Ctrl+C doesn't work). Running lsmod by starting another ssh session shows that the module is in use even though there is no code running that will use it.
If I plug the USB device after the system boots up then sudo insmod driverx.ko works normally, (the terminal is still active). Running lsmod subsequently shows that that module is loaded but not in use by anyone. I can then run my user code and everything is fine. Upon running my user code lsmod shows the kernel module is in use and the number of users is 1.
In our system the USB device will always be plugged in. The kernel version and the driver version are the same.
I can fill in more details but do not wish to bias or make this query un-readble.
Please advise on what could the problem be.
Thank you for your time and help.
Possibility is that, the device is already attached into some other driver during startup. If it’s the case, the device credential of your specific device has to be removed from the startup driver.
Check the USB device list before to insert your driver.
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
I just installed CentOS 6.3 on a new computer and am unable to SSH to it from our computer running Fedora 16. They are both on the same network.
Some facts:
- I can ping it from the Fedora machine.
- I can SSH to the CentOS computer to itself on the CentOS computer.
- I have looked into hosts allow and deny, I have set selinux to be permissive, I tried with iptables disabled on the Fedora computer
I am fresh out of ideas...
Thanks
Do you have fail2ban running?
Do you have denyhosts running?
Do you have iptables allowing TCP 22?
Do you have a line in your sshd_config that refers to "AllowUsers"? (most dont but some do, and if yours does, you need your account listed on that line)
Can you run this command tail -f /var/log/secure on that machine at the same time while trying to login from the second machine and spot the issue? If not, paste the output from that log here for me to comment on.
A long shot, but you might try service sshd restart and try again to see if that helps. Go ahead and run tail /varlog/messages while restarting that daemon to see if you spot anything unusual while doing that. If you spot the issue great, if you dont, post the output here for me to comment on.
Last, do this cp /etc/ssh/sshd_config /etc/ssh/sshd_config.back and then take a good known working sshd_config from another machine and place it over the top of yours and then restart the daemon again & try again.
My money is on seeing something that helps us in /var/log/secure.
I am currently taking an operating systems class and I need to use qemu to run a small operating system that my professor provided. I am trying to use qemu within an ubuntu 12.04 virtual machine on virtualbox on my macbook air 5.2. I know the problems I am having probably have to do with nested virtualization but the specific error I get when I try to run qemu is:
Could not access the KVM kernel module: No such file or directory
failed to initialize KVM: no such file or directory
Back to tcg accelerator.
qemu does start up the os but the window flickers quite a lot and I would like to fix the KVM problem if possible. I've done research but I can't find a solution I can understand or that works so any help would be greatly appreciated.
Also for the ubuntu virtual machine in virtualbox I have both Enable VT-x/AMD-V and Enable Nested Paging checked under Hardware Virtualization. I've also tried using
modprobe kvm-intel
and I get this error:
FATAL: Error inserting kvm_intel (/lib/modules.3.5.0-22-generic/kernel/arch/x86/kvm/kvm-intel.ko): Operation not permitted.
In my case, the virtualization was disabled.
So sudo modprobe kvm-intel kept giving me the following error
could not insert 'kvm_intel': Operation not supported
I just had to go in the BIOS and enable Virtualization.
Try with sudo modprobe kvm-intel.
In order to have the module automatically loaded at the startup of the virtual machine, do the following:
Edit the corresponding file from the shell with sudo vim /etc/modules.conf
Possibly enter your username password.
Press the key G to go to the end of the document and then o to begin inserting.
Write kvm-intel and press Enter, producing a new line.
Press Esc to return to the Normal mode of vim. "--INSERT--" will disappear from
the bottom.
Save the file and exit vim by writing :wq.
You are done. Try to reboot and load the nested virtual machine.
When I start the `Paste' web server in daemon mode, it seems to kill off it's ability to reload when the timestamp of a source file is updated.
Here is how I start the daemon...
cd ${project} && ../bin/paster serve --reload --daemon development.ini; cd ..;
...which defeats one of the main points of using Paste (for me).
Has anyone come across this or know what I'm doing wrong?
To be complete, the file that I'm changing is a controller file.
The version is `PasteScript 1.7.3'
I believe that the two options are essentially incompatible, since the reloader stops the server with a SIGTERM and the daemon-ized server is impervious to that -- and since daemon is intended for running in a production environment, and reload for a development/debugging environment, I guess that their incompatibility is not seen as a big loss. I imagine a customized reloader, tailored to properly stop and restart the daemonized server, could certainly be developed, but I don't know of any existing one.
I had a similar problem and circumvented the problem. I currently have paster running on a remote host, but I am still developing, so I needed a means to restart paster, but manually by hand was too time consuming, and daemon didnt work. So I always had to keep a shell window open to the server and running paster without --daemon in there. Once I finished my work for that day, and i closed the shell, paster died, which is bad.
I circumvented that by running paster non daemonized in a "screen".
Simply type "screen" in your shell of choice, you will usually depending on your linux be presented with a virtual terminal, that will keep running even when you log out your remote session. Start paster as usually in your new "window" (the screen) with --reload but without daemon, and then detach the window, so you can return to your normal shell (detach = CTRL-A, then press D). You can re-enter that screen by typing "screen -r". If you would like to kill it, reconnect it (screen -r) and inside the screen type CTRL-A, then press K.
Hope that helps.