Bootloader no longer loads OctoPrint/TouchUI and gives a refused to connect message

[revjkramer]

I don't know a lot about python and whatnot, but it looks like the new OctoPrint 1.4.0 is no longer compatible with this plugin since they dropped python 2 support because it is EOL as of January 2020. I don't know what it would take to make this work again, but I would love to see it work with the new version.

[TheNore]

I get the following screen when booting up with octoprint 1.40

[nachosan100]

same here!

[TheMrCaveman]

Same here, hope this will be fixed soon

[hmasing]

Samesies. Bummer, since I just got the touchui interface working on my printer last week!

[jamestb2]

Hey guys, I just had this and fingered it out for me at least where you see Hypercube.local use your own hostname.local I also used Port 80 probably a cleaner approach but too lazy tonight to dig and looked for the quick win go to the TouchUI-Autostart folder cd TouchUI-autostart/ nano chromium.xinit go to the very bottom of the doc find the section that looks like this and replace the variables with your box name.local I commented out the original section ex. CHROME_ARGS=" --no-first-run --kiosk $TOUCHUI_ARGS $TOUCHUI_DEBUG --dns-prefetch-disable --disable-sync-pre$ --disable-java --disable-plugins --disabl$ --user-agent='TouchUI (X11, Chrome $CHROM$ --start-maximized --window-position=0,0 -$ http://hypercube.local/"

http://localhost:$TOUCHUI_PORT/"

and the last change is below for the port, set your port here, also I used port 80 and commented out the changed section

Start local web server to host the startup page to avoid CORS problems $

python $TOUCHUI_DIR/helpers/server.py \ --dir $TOUCHUI_DIR/bootloader/ \ --port 80 &

$TOUCHUI_PORT &

then do a control-x and y to save it

then sudo service touchui restart

Have fun, this pissed me off for 45 mins and spent too much time at work today to dig for the real fix in the config files pulled but this got my :11 connection refused white screen gone :) J

[jamestb2]

oh btw if Octoprint also won't start just copy the backup.yaml to the config.yaml. Replace back whatever you need like autologin. The auto-updater from the UI effed that up for me too.. Saw that in browser and almost threw the laptop. Had the white screen then too btw James

[bolsoncerrado]

Same issue here-. Will check for james solution slower now... thanks.

EDIT: Apparently it partially solves the issue for me but it keeps octoprint process at 100+% usage on the Pi, overheating it :????

On a second Pi where I have the plugins disabled, the process is between 9 and 50% usage at most.

I don't get it.

[jamestb2]

Hey bolsoncerrado-- I checked via Top and I am running maybe 3-6% CPU (with all loaded and running) and I have a TON of plugins and also running Klipper firmware on a Pi 4 2GB box. Thats with a cam running full time as well, if that helps any. Using the official 7" and official v2 Camera. I would start with the Octoprint log for clues on the plugins gone wonky perhaps followed by a top command and review the output, then perhaps dig deeper into the config files loading vars for chromium.xinit file and the config.yaml file for OctoPrint. If you look at the top of the chromium.xinit-- it will tell you the paths to the backing files pulled to populate vars used in that file. I'm by no means an expert here as I haven't read all the related code bases but if you post some outputs I know that even if I can't be of help that we have an awesome community here with lots of knowledge. Final note-- don't give up-- even if you have to install over, you won't lose anything! I had to do it a couple versions back, luckily not this time. Shouldn't ever need to reflash the SD card with a new image. All things can be repaired.. I hope that helps you some, I agree very odd the 2 different results. Hang in there bud!

[bolsoncerrado]

Thats the weird point... Im working on a fresh install of 0.16 with almost no plugins installed other than a few by Gina and 2 or 3 more... Running on Pi3B tho. It's not normal anyway I agree.

[bolsoncerrado]

So Pi4+0.17 is quite stable then?

[jamestb2]

For me the Pi4 has been very stable, I rarely have to ssh into it ever. It just works for me, luckily.

[BillyBlaze]

Thanks for reporting. I'll have a look at this as soon as possible.

[OutsourcedGuru]

Guys, v1.4 does not remove Python 2 support. It just opens up Python 3 for those who decide to change the underlying virtual environment. So in this new v1.4 phase, plugin authors are encouraged to update their own code so that it is both compatible with Python 3 and it advertises this fact in two places within their code.

Some of the support incidents I've seen appear to be trying to connect to the IPv6 version of the localhost IP address. I would recommend just connecting to the word "localhost" rather than an IP address and drop the square brackets.

[darkspawn91]

Sorry guys, I have log in page on reboot. what I can do?

[jamestb2]

If you mean the Rpi login-- Check your config.yaml in ~/.octoprint/ and make sure the autologin part is there example from a old reference, it was at the top of the file btw accessControl: autologinAs: pi autologinLocal: true enabled: false I know that helped me in the past for it not logging into the cli If the TouchUI part, I totally forgot how I did it but I used/launched Chromium on the box but and filled in the forms, saving to the local profile, then rebooted. Then I used it 1 time and it showed the items cached like you expect in the browser with the dropdown suggestion deal, told it to remember me and I never saw the login page again. After I did that, no more usb micro keyboard. Before then, i had to have it after every reboot when just using the Pi and official 7" Hope that helps to get you back to printing man

[foosel]

Just chiming in to say that the title of this issue is as factually wrong as can be, as already pointed out by @OutsourcedGuru. OctoPrint did not "drop python 2 support", it runs perfectly fine on it, and the issue with the TouchUI bootloader (not the plugin mind you), appears to stem from the server.py either not running or not binding to v6 and hence Chromium not being able to connect to it. OctoPrint isn't even involved at the point of failure as far as I understand the workflow, and the workaround posted here also just seems to solve the issue by bypassing the bootloader.

I'm not deep enough into the code of TouchUI to be able to say more, the only thing I've figured out so far is that merely running server.py alongside 1.4.0 works flawlessly, so that can't be it (and considering that as far as I can see the bootloader server isn't even fired up in the venv it can't really see how it even could be influenced by OctoPrint).

I don't have a local display install to test against myself, but if you want to ping me about anything @BillyBlaze, I'm happy to help however I can.

[foosel]

Ok, I installed a VNC server on one of my Pis and can now reproduce. It's not the bootloader after all, it's the redirect from the bootloader to OctoPrint that's causing an issue here. I'm sadly currently unable to coax out the details of where chromium tries to go out of it. But considering that a simple curl "http://[::1]" works just fine in connecting to the OctoPrint server or rather haproxy which then connects to the OctoPrint server, Chromium should actually be able to reach the server as well.

[foosel]

Changing

content.setAttribute("src", prefix);

here to

window.location.href = prefix;

(edit or window.location.replace(prefix)) makes everything work also against 1.4.0, at the cost of reload in the browser now no longer restarting the bootloader.

@BillyBlaze is there a particular reason why you went for content.setAttribute instead of window.location.href? I don't know WHAT Chromium does differently between the former vs the latter, but something in it makes Chromium think it can't reach a server that's perfectly reachable. Maybe some weird caching issues? CORS headers? I have no clue and also wasn't able to find anything about the attribute reassigment approach. I've only ever used window.location.href myself tbh.

[bolsoncerrado]

I'm not sure if this could be related, probably not, but it's only happening in locale and way before 1.4.0 release...

The LOCAL instances of TouchUI (i run many octoprints+touchuis+Prusas on Pi3B+Hyperpixel4Touch screens) have to be continuosly refreshed manually because they end up being outdated...

This happens only locally, not in any other LAN computer. Is that the particular reason the REFRESH TOUCHUI button was created? It's a bit annoying and dimishes any reason for touchui to coexist with a touch screen actually...

[foosel]

Can't say anything about that, but what I just found out with tcpdump and Wireshark is that even though Chrome claims it can't reach the server, it actually DOES reach the server:

This is what chrome requests and receives in the "broken" case.

Working one (window.location.replace(prefix)) is this (and a ton more requests for fetching CSS and JS and whatnot since Chrome actually executes the page):

The only difference I can currently spot is Sec-Fetch-Mode: nested-navigate (broken) vs Sec-Fetch-Mode: navigate (working). Here's the docs on that header. So apparently CORS related, but I don't see an OPTIONS header or anything preceding the request either. Note that the response ETag is identical, so OctoPrint responds the same in both cases, but for some reason in one case Chromium decides to go "nah, that ain't working".

edit TCP stream for 1.3.12:

We have a winner I guess. X-Frame-Options: sameorigin. Security measure suggested during an audit and added in 1.4.0 (protection against clickjacking, see also here and here). Not an issue with an actual in browser location change, but an issue on a src change it seems.

[bolsoncerrado]

If you mean the Rpi login-- Check your config.yaml in ~/.octoprint/ and make sure the autologin part is there example from a old reference, it was at the top of the file btw accessControl: autologinAs: pi autologinLocal: true enabled: false I know that helped me in the past for it not logging into the cli If the TouchUI part, I totally forgot how I did it but I used/launched Chromium on the box but and filled in the forms, saving to the local profile, then rebooted. Then I used it 1 time and it showed the items cached like you expect in the browser with the dropdown suggestion deal, told it to remember me and I never saw the login page again. After I did that, no more usb micro keyboard. Before then, i had to have it after every reboot when just using the Pi and official 7" Hope that helps to get you back to printing man

BTW I get to the login page too and I do have autologin enabled on config.yaml -- touchui used to login automatically BEFORE commiting the changes to chromium.xinit file, this makes no sense :??

[BillyBlaze]

@OutsourcedGuru thanks for the valuable feedback!

@foosel thank you very much for your investigation/feedback; The bootloader will first starting 'pinging' a touchui endpoint to see if it has started. Then when started it set the source of a hidden iframe to OctoPrint and attached an onload event handler so that when OctoPrint loaded it will show TouchUI without seeing the loading stages (e.g. Flash of Unstyled Content).

Telling this story and looking into releases tab I realised that this was changed and is the suspected culprit:

X-Frame-Options is not set to sameorigin unless configured otherwise

[foosel]

Yeah, seems we wrote concurrently ^^

Setting

server:
  allowFraming: true

in OctoPrint should make it work out of the box again.

edit confirmed

edit2 Easy to do from the command line, on OctoPi:

~/oprint/bin/octoprint config set --bool server.allowFraming true
sudo service octoprint restart
sudo service touchui restart

Adjust path to octoprint executable for installs that aren't OctoPi and restart OctoPrint & TouchUI

edit3 This is now also covered in an FAQ entry.

[jansenchua]

Yeah, seems we wrote concurrently ^^

Setting

server:
  allowFraming: true

in OctoPrint should make it work out of the box again.

edit confirmed

edit2 Easy to do from the command line, on OctoPi:

~/oprint/bin/octoprint config set --bool server.allowFraming true
sudo service octoprint restart
sudo service touchui restart

Adjust path to octoprint executable for installs that aren't OctoPi and restart OctoPrint & TouchUI

edit3 This is now also covered in an FAQ entry.

works like magic again.. even though i very much wanted to install Octoscreen because it looks so beautiful but I just can't it installed properly I figured if touchui works I just stay :)

[rogodra]

Yeah, seems we wrote concurrently ^^

Setting

server:
  allowFraming: true

in OctoPrint should make it work out of the box again.

edit confirmed

edit2 Easy to do from the command line, on OctoPi:

~/oprint/bin/octoprint config set --bool server.allowFraming true
sudo service octoprint restart
sudo service touchui restart

Adjust path to octoprint executable for installs that aren't OctoPi and restart OctoPrint & TouchUI

edit3 This is now also covered in an FAQ entry.

The solution works, but the touchscreen has stopped working

[jansenchua]

Yeah, seems we wrote concurrently ^^ Setting

server:
  allowFraming: true

in OctoPrint should make it work out of the box again. edit confirmed edit2 Easy to do from the command line, on OctoPi:

~/oprint/bin/octoprint config set --bool server.allowFraming true
sudo service octoprint restart
sudo service touchui restart

Adjust path to octoprint executable for installs that aren't OctoPi and restart OctoPrint & TouchUI edit3 This is now also covered in an FAQ entry.

The solution works, but the touchscreen has stopped working

I just tested my screen works fine

[foosel]

The solution works, but the touchscreen has stopped working

This solution cannot possibly make your touchscreen stop working, it's a configuration setting inside OctoPrint which neither knows nor cares about your touchscreen.

I really wish y'all would stop blaming everything that ever goes wrong in a complex setup of several components on OctoPrint, the past 48h it's been made responsible for invalid configuration files, file corruption due to undervoltage, wrong installation procedures executed by the user, clogging nozzles and now breaking touchscreens, and frankly it's a bit frustrating 😕

[bolsoncerrado]

C'mon @foosel every1 here knows Octoprint is the cause for climate change...

All those tiny CPUs overheating due to Octoprint clogging them!! :P

[bolsoncerrado]

Yeah, seems we wrote concurrently ^^

Setting

server:
  allowFraming: true

in OctoPrint should make it work out of the box again.

edit confirmed

edit2 Easy to do from the command line, on OctoPi:

~/oprint/bin/octoprint config set --bool server.allowFraming true
sudo service octoprint restart
sudo service touchui restart

Adjust path to octoprint executable for installs that aren't OctoPi and restart OctoPrint & TouchUI

edit3 This is now also covered in an FAQ entry.

Even with this I still land on the Please login screen and IDK why. Autologin is set as per .yaml:

accessControl: autologinAs: admin autologinLocal: true

what else am I missing?

Ty!

[foosel]

I have

accessControl:
    autologinAs: test
    autologinLocal: true

and it works just fine 🤷‍♀️

---

Side note for @BillyBlaze: the install script mangled my yaml and turned it into

accessControl:
    autologinAs: test
    autologinLocal: true
      salt: foo

or something (sorry, forgot to note that down). So the indentation was off and that caused the server to no longer start. Easy fix really, but just remembered it and thought I'd mention.

[foosel]

@bolsoncerrado open a ticket on OctoPrint's repo please.

[bolsoncerrado]

OK let me see if its just me as someone above reported everything works fine for him; if @BillyBlaze fixes this finally and i keep having autologin issues, i certainly will. Ty.

[BillyBlaze]

@foosel, thanks, I wasn't aware of that. Perhaps you have tips how to do this from the command line? Currently I use sed and replace the accessControl: key with a new one. (See code here) and assumes some things like indentation is always 2 spaces.

[rogodra]

I really wish y'all would stop blaming everything that ever goes wrong in a complex setup of several components on OctoPrint, the past 48h it's been made responsible for invalid configuration files, file corruption due to undervoltage, wrong installation procedures executed by the user, clogging nozzles and now breaking touchscreens, and frankly it's a bit frustrating 😕

I don't know why it gets like this, this solution has corrupted my touch screen. I will check that it could go wrong. I have restored the microSD in the previous state and now everything works.

[BillyBlaze]

@bolsoncerrado, try out these steps/tips from Chris Riley https://youtu.be/rqy3dVZ4JH4?t=669

[foosel]

@foosel, thanks, I wasn't aware of that. Perhaps you have tips how to do this from the command line? Currently I use sed and replace the accessControl: key with a new one. (See code here) and assumes some things like indentation is always 2 spaces.

If you are running against recent OctoPrint versions (as in, not older than maybe 2 years or so - not sure when exactly I introduced these things but it was ages ago) you can use the config sub command.

~/oprint/bin/octoprint config set --bool accessControl.autologinLocal true
~/oprint/bin/octoprint config set accessControl.autologinAs <username>

[rogodra]

I have tried again after restoring the copy of the SD and now it works perfectly. Thank you.

[BillyBlaze]

@foosel, Yeah I was thinking about using that, but I cant assume that octoprint is installed in ~/oprint/bin/ for non OctoPi builds...

[lightmagick]

So I've been trying to get this working as I've only just added a touchscreen to my printer setup and of course I'm having this issue y'all are talking about here. I'm trying the fix as Foosel wrote above but I am getting a weird result, see below. Any help would be appreciated.

pi@octopi:~ $ ~/oprint/bin/octoprint config set --bool server.allowFraming true Error parsing the configuration file, it appears to be invalid YAML. The parser reported an error on line 6, column 3. There was a fatal error initializing the settings manager.

[foosel]

@foosel, Yeah I was thinking about using that, but I cant assume that octoprint is installed in ~/oprint/bin/ for non OctoPi builds...

You could depend on OctoPrint running already, grep the current processes for it and extract the executable path from that.

pi@octopi:~ $ ~/oprint/bin/octoprint config set --bool server.allowFraming true Error parsing the configuration file, it appears to be invalid YAML. The parser reported an error on line 6, column 3. There was a fatal error initializing the settings manager.

So what's in ~/.octoprint/config.yaml at line 6, column 3? Looks like whatever it is, it's what's causing a broken config.

[BillyBlaze]

@lightmagick open ~/.octoprint/config.yaml and check if the indentention is still correct like foosel https://github.com/BillyBlaze/OctoPrint-TouchUI/issues/368#issuecomment-595784265 said in the below part of her comment.

The config should like this:

accessControl:
    autologinAs: test
    autologinLocal: true
    salt: foo

and not like this:

accessControl:
    autologinAs: test
    autologinLocal: true
      salt: foo

[BillyBlaze]

@foosel, yeah sounds like a good idea! thanks

[lightmagick]

@lightmagick open ~/.octoprint/config.yaml and check if the indentention is still correct like foosel #368 (comment) said in the below part of her comment.

The config should like this:

accessControl:
    autologinAs: test
    autologinLocal: true
    salt: foo

and not like this:

accessControl:
    autologinAs: test
    autologinLocal: true
      salt: foo

Well I was about to give up because nothing was working but I just ran the touchui install helper again and then tried the fix which gave a similar parsing error but after I removed duplicated lines of the "autologinAs:" and "autologinLocal:" and tried the fix again it seems to be working for now. Thank you for the assistance.

[robdenuto]

Came across this as I started having seemingly related issues after the last update, unrelated to TouchUI specifically. I would previously load my two octoprint instances in side by side frames so I could work with/monitor both simultaneously, but after the most recent update it's not happy.

Refused to display 'http://192.168.1.182/' in a frame because it set 'X-Frame-Options' to 'sameorigin'.
Refused to display 'http://192.168.1.183/' in a frame because it set 'X-Frame-Options' to 'sameorigin'.

[bolsoncerrado]

@robdenuto did u try the above yet?

~/oprint/bin/octoprint config set --bool server.allowFraming true sudo service octoprint restart sudo service touchui restart

[robdenuto]

@robdenuto did u try the above yet?

~/oprint/bin/octoprint config set --bool server.allowFraming true sudo service octoprint restart sudo service touchui restart

I had prints going so I couldn't at the time, but I just tried that and am back up and running! Thx

[darkspawn91]

Nothing for me. "This site can't be reached" "localhost refused to connect". I did everything. I don't know what go wrong.

[nledenyi]

just wanted to comment that "config set --bool server.allowFraming true" fixed the issue for me. Thanks for the quick turnaround!

[BillyBlaze]

This issue has been resolved in the installer.

For anyone that has currently have this issue, you can fix this with the following command or by updating the bootloader and running install again:

~/oprint/bin/octoprint config set --bool server.allowFraming true
sudo service octoprint restart
sudo service touchui restart

If you have any issues after this, then please create another ticket.

[BillyBlaze]

Also big thanks to @foosel for her help/tips with this issue!