Can't access octoprint from fresh image

What is the problem?

Fresh image of OctoPrint on Raspberry Pi 3B. After allowing pi to start for 5-10 minutes and opening browser to IP address (10.0.0.2) in chrome I get the error " This site can’t be reached".
When I ssh in to the pi: ssh pi@10.0.0.2 it gives me the prompt "pi@localhost", i.e.

Access OctoPrint from a web browser on your network by navigating to any of:

http://localhost.local
http://10.0.0.2
http://[2601:247:4003:3e80:c3e3:7f78:3bdc:4fa4]

https is also available, with a self-signed certificate.

This image comes without a desktop environment installed because it's not
required for running OctoPrint. If you want a desktop environment you can
install it via

sudo /home/pi/scripts/install-desktop

OctoPrint version : 1.3.12
OctoPi version : 0.17.0

pi@localhost:~ hostname localhost pi@localhost:~

I assume I can't access octoprint from a browser as it is hosting it to localhost.

What did you already try to solve it?

Tried to change hostname via raspi-config:
pi@localhost:~ raspi-config Script must be run as root. Try 'sudo raspi-config' pi@localhost:~ sudo raspi-config
[sudo] password for pi:
Sorry, user pi is not allowed to execute '/usr/bin/raspi-config' as root on localhost.

Have you tried running in safe mode and if so did it solve the issue?

Reproduced exactly when running in safe mode, issue persists.

Complete Logs

2020-09-27 12:10:39,728 - octoprint.filemanager - INFO - Added 0 items from storage type "local" to analysis queue
2020-09-27 12:10:39,731 - octoprint.server.util.watchdog - INFO - Running initial scan on watched folder...
2020-09-27 12:10:40,063 - octoprint.server.util.watchdog - INFO - ... initial scan done.
2020-09-27 12:11:05,147 - octoprint.plugin - ERROR - Error while calling plugin discovery
Traceback (most recent call last):
File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint/plugin/init.py", line 219, in call_plugin
result = getattr(plugin, method)(*args, **kwargs)
File "/home/pi/oprint/lib/python2.7/site-packages/octoprint/plugins/discovery/init.py", line 143, in on_startup
self.zeroconf_register("_http._tcp", self.get_instance_name(), txt_record=self._create_http_txt_record_dict())
File "/home/pi/oprint/lib/python2.7/site-packages/octoprint/plugins/discovery/init.py", line 201, in zeroconf_register
self._sd_refs[key] = pybonjour.DNSServiceRegister(**params)
File "/home/pi/oprint/local/lib/python2.7/site-packages/pybonjour.py", line 1132, in DNSServiceRegister
None)
File "/home/pi/oprint/local/lib/python2.7/site-packages/pybonjour.py", line 286, in _errcheck
raise cls(result)
BonjourError: (-65537, 'unknown')
2020-09-27 12:11:05,293 - octoprint.plugins.pi_support - ERROR - Got an error while trying to fetch the current throttle state via "/usr/bin/vcgencmd get_throttled"
Traceback (most recent call last):
File "/home/pi/oprint/lib/python2.7/site-packages/octoprint/plugins/pi_support/init.py", line 263, in _check_throttled_state
state = get_vcgencmd_throttled_state(command)
File "/home/pi/oprint/lib/python2.7/site-packages/octoprint/plugins/pi_support/init.py", line 140, in get_vcgencmd_throttled_state
raise ValueError("cannot parse "{}" output: {}".format(command, output))
ValueError: cannot parse "/usr/bin/vcgencmd get_throttled" output: VCHI initialization failed

2020-09-27 12:11:05,324 - octoprint.server - INFO - Listening on http://127.0.0.1:5000
2020-09-27 12:11:06,079 - octoprint.plugins.pluginmanager - INFO - Loaded plugin repository data from disk, was still valid
2020-09-27 12:11:20,180 - octoprint.plugins.pluginmanager - INFO - Loaded notice data from disk, was still valid
2020-09-27 12:11:21,742 - octoprint.util.pip - INFO - Using "/home/pi/oprint/bin/python2 -m pip" as command to invoke pip
2020-09-27 12:11:21,754 - octoprint.util.pip - INFO - pip installs to /home/pi/oprint/lib/python2.7/site-packages (writable -> yes), --user flag needed -> no, virtual env -> yes
2020-09-27 12:11:21,763 - octoprint.util.pip - INFO - ==> pip ok -> yes

Additional information about your setup

OctoPrint version : 1.3.12
OctoPi version : 0.17.0

Headless option only. Ubuntu PC available for troubleshooting.

can your router see the pi (client list)?
if so it will tell you the IP address to use
the IP addresses at the top of your post are examples from the author of that page
they are NOT set in concrete
most likely 192.168.1.xxx sort of style

Absolutely. I am troubleshooting over ssh using WiFi through my router. It "does" tell the IP address to use, see above, which is what I used (10.0.0.2) which comes from the DHCP server on the router. They are not "examples", they are copied and pasted from the pi login screen.

ah ok
just not the sort of values I'm used to seeing
in that case
http://10.0.0.2
on your PC should open a browser

No. That does not work.

A default install of OctoPi 0.17.0 (with OctoPrint 1.3.12) will have the hostname of octopi.

If your network supports Bonjour, then http://octopi.local should work. If you have a local DNS server and your DHCP server populates that, then http://octopi may work (add your local domain name if necessary). In your case http://10.0.0.2 should also work.

All of these URLs are from another system on your local network, OctoPi by default doesn't come with a GUI and/or a web browser installed.

In the future, use the </> icon to surround any text you cut and paste into a reply. This will prevent any unwanted/undesirable formatting from being applied.

From the octoprint.log excerpt you posted, I'm guessing that you have a corrupted install. I'd start over, reflash the SD card, etc. following the instructions at https://octoprint.org/download/. You might check your download using the MD5sum posted there. If you are writing the SD image on your Ubuntu PC, removing and reinserting the SD card after flashing should mount two partitions (on a Windows or MacOS system, only the boot partition will be visible) so make sure Ubuntu doesn't do anything to the other partition.

when you use ssh, how are you connecting to the pi?

I'm sorry if I'm being rude, but I don't think you read the original issue text, it seems like you just read the title. If you don't know the cause/fix for this issue that's ok, no need to respond.

Have you something like NoScript installed?

1 Like

@mmcp42's question is valid. SSH can be done over TCP or Serial connections (and some people do serial into rPi). We're assuming that you are SSH'ing over TCP/IP on port 22. (Running PuTTY?)

tl;dr - Suggest a new card and fresh image with Etcher, boot and what results?

If you imaged OctoPi onto a card, and booted the rPi, it sounds like you have a DHCP server handing out that 10.0.0.2.

Since you are using 10.0.0.0/8 as a private network, you likely have some sense of server/daemon management. I would make a suggestion to setup a DHCP reservation for the device, two separate IPs for it's WiFi MAC and it's wired MAC. You will likely be restarting and reloading this device to troubleshoot this issue. Relying on Bonjour and octopi.local and assuming the device gets the same IP is just going to lead to headaches.

I am understanding you are SSH'ing to the LAN IP 10.0.0.2 and getting "pi@localhost" as a response. That to me indicates that you are connected to the rPi and logged in. IIRC, only once you complete the OctoPi setup will you get a "login as:" prompt. You can also get this with a corrupted image. Ask me how I know.

Some WiFi routers will isolate either all traffic or web-based traffic between WiFi clients.

So, troubleshooting - your PC at say 10.0.0.10 can SSH to 10.0.0.2, next comes ping (with the device on and off). I've seen people have mis-identified devices before. If you cannot ping with the device off, then can once it's up - then you do have the device. If it still pings with this device off, then something else is out there.

Next, if the 10.0.0.10 cannot HTTP to 10.0.0.2 and this is a newly created OctoPi, I would redownload the current OctoPi image and write the image to a FRESH card using BalenaEtcher - no need to extract the .ZIP, it will read the compressed file and write it out.

Now, if it isn't already, hook the rPi up to your wired LAN, and then the power. Let it come up with that, then try and access it. Refer to my earlier suggestion about DHCP reservation of the wired MAC address. If you cannot SSH, ping and HTTP to the device while on your wired LAN, then we're at least ruled out wireless isolation and a bad image.

At that point, it's really up to the oddities of your own network, which are often the most difficult to troubleshot.

Hope this helps, let us know what you get.

1 Like