I rebooted my rpi 4b with the following command: sudo systemctl reboot, and it did turn off, but wasn't rebooting after about an hour and a half (i had rebooted it perfectly before) so I decided to cut the power off and on, and try to login via ssh, but the green LED it blinked quickly and stopped after a long blink. I tried looking up answers but didn't find anything, I also tried removing and re-creating the FAT32 partitions, but I got the same LED pattern. Thanks in advance.
If you are just trying to reboot the raspi then you simply need reboot or sudo reboot. systemctl is something else entirely and responsible for running services on your pi.
Related
I'm trying to set ElasticStack but I had problems with Kibana and Logstash, I could solve Kibanas issue, but after some days, my CentOS 7 machine don't recognise logstash.service.
I think that this is not a logstash issue, instead is a CentOS7 or a Systemd issue.
How do you think I can make my logstash.service appear again?
I had erase and reinstall logstash many times.
This is my "systemctl -a":
● logstash.service not-found inactive dead logstash.service
EDIT: This problem is solved! the problem was a script running on the pi, which occupied the SCL pin (in my case a script listening for a shutdown button). So it was not able to read the rtc.
I'm currently following this tutorial to connect my Raspberry Pi Zero W running Jessie Lite to the RTC DS1307.
The rtc is being recognized when running sudo i2cdetect -y 1 with "UU", so everything fine until this point.
But when entering sudo hwclock -D -r I'm getting an error:
Does anybody have any experience or hints with this error? I was researching for 1 1/2 day now, but could not find a working solution. Any help is appreciated.
Back then I was not able to answer my own question. I have already edited the main post, but to close this question:
This problem is solved! the problem was a script running on the pi, which occupied the SCL pin (in my case a script listening for a shutdown button). So it was not able to read the rtc.
I face a problem that I can ping to correct IP address, it have no loss. And also I use nmap ping the pi address, and I get it correctly. Then I using VNC viewer to try access to pi, but it always show up "The connection was refused by the host computer"
Did u all have any idea ?
Your problem indicates that your Raspberry Pi was reached by the connection attempt, but that no service was running on the relevant port and hence the connection was refused. I think, this is because the VNC service is not running on your Raspberry Pi.
Update 1
Raspbian now comes with the server by default thanks to a partnership with RealVNC, it just needs to be enabled.
Original
You must enable VNC Server on your Raspberry Pi using terminal
sudo apt-get update
sudo apt-get install realvnc-vnc-server
or you can also enable VNC Server on the command line using the sudo raspi-config command.
Advanced Options->VNC:Yes
Now you can connect to the VNC Server using a application such as VNC Viewer.
I have been having this issue with my Raspberry Pi Zero W even though it worked perfectly beforehand. This page https://www.realvnc.com/en/connect/docs/raspberry-pi.html should help.
I ran vncserver in a ssh window after verifying the interface settings in raspi-config.
It started the VNC Server and gave me the VNC Server catchphrase and the IP address with Port Number as shown in the photo linked below.
vncserver output
After running that command I was able to get the VNC Viewer on my windows machine to connect to the pi.
I then ran sudo systemctl enable vncserver-x11-serviced.service in the ssh window so that it would start automatically on subsequent reboots.
I've had this same problem but found a different reason. I found three ways to get around this error message.
Plug a mouse or keyboard into the Raspberry Pi zero, waking up the screen and the VNC connection.
Wait about 5 - 10 minutes which is the amount of time for the screen saver to kick in which seems to wake up VNC connection. but don't wait to long other wise run this command to get things going via ssh "systemctl start vncserver-x11-serviced.service".
I am hoping the new update they just published will fix this problem. I don't see this as much with the Raspi B3+ as with the Zero H.
The last was plug in both monitor and mouse and that for sure fixes the VNC issues but defeats the headless connection. It seems that running headless and the screen/saver are somehow related but just not smart enough to figure it out.
For people using newer version of Raspberry, VNC option is found under:
Config>Interface Options
pinging to any service will only tells us that whether the server is currently listening on that port or not. It will not tell you the possible result to connection request asked by client.
It seems that, you have installed VNC server but not started it properly. Use this command to start it...
# vncserver start
Also recheck the port number is correct or not.
With the Rasp Pi 4 - had connecting fail after rebooting both the server and client (both Rasp Pi 4s).
Took a while to realize that I have two clients: One named "VNC Client", the other "VNC Viewer for Google Chrome".
The former works, the latter doesn't.
I'm running Jessie 8.0 on a raspberry pi 2 B and it doesn't boot completely anymore after installing upstart
sudo apt-get install upstart
FYI: Apache, PHP, MySQL, KODI were installed upfront
What can I do? Could I try to uninstall upstart?
Thanks in advance
Just ran into this headache this morning on my Raspberry Pi 3. You can use Recovery / Single User Mode to fix this.
Plug in a keyboard and HDMI connection to the Pi.
Repeatedly press shift while booting to get to the recovery console.
Press 'e' to edit config, use tab and arrow keys to navigate to cmdline.txt
Add "init=/bin/bash" to the end as the last argument
Press "OK", and then hit the escape key to continue booting
After the boot sequence looks like it has stopped (mine looked like it had frozen mid-boot, don't worry), try pressing enter to get a CLI prompt
Type /etc/init.d/mountall.sh
Type mount -n -o remount,rw / (This mounts the root of SD Card)
At this point most commands should be functional, now you can use Escounda's answer and type: sudo apt-get purge --auto-remove upstart
After a reboot everything should be back to normal with no OS reinstall required! Don't forget to remove "init=/bin/bash" from your cmdline.txt when you're finished.
I'm probably late to the party, but I had the same issue yesterday (Pi won't boot, no way to use apt to remove upstart)
So I installed Ubuntu in a VM and chrooted into my SD Card (See https://raspberrypi.stackexchange.com/a/24011/13597 for more informations about this)
Then removed upstart just like in Escounda's second post
I managed to boot again by removing upstart:
sudo apt-get purge --auto-remove upstart
This command will also automatically reinstall systemd-sysv
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.