error on NanoPi

hi guys, I’m stuck here (I’m a novice user). I use a nano pi neo, how can I fix it?


What are you trying to do and did you already changed something?

no, it appears after the first boot

linking the related GitHub issue https://github.com/MichaIng/DietPi/issues/4663

It has been fixed in the meantime by Armbian :slight_smile:.

Hi.
I am still having this issue.

However this fix from github saved me:

https://github.com/MichaIng/DietPi/issues/4663

“solved in this way: select subshell from menu, edit /etc/apt/sources.list.d/armbian.list , change from https to http
I hope it will be useful to someone in the future.”

Not sure how often this has been fixed by Armbian guys :roll_eyes:
Looks like it’s reoccurring again and again.

We are still investigating the issue. It seems to be some sort of response caching that kicks in after a while. The implementation of the router has several layers: Nginx proxy on the host, terminating HTTPS, forwarding to an uWSGI Docker container which again includes an Nginx uWSGI proxy, forwarding to the uWSGI server which wraps the final Flask app. I tried to replicate it (same setup): Even without the recently included final proxy header recognition, the Flask app detects the request scheme/protocol correctly, so the container seems to do a header translation already which made our recent change irrelevant. Locally, even with a long running request loop I couldn’t replicate the case that the scheme is after a while wrong in the redirect. Also a dedicated status page keeps returning the correct scheme also on Armbian, even that it’s exactly the same script which handles the status page and the redirect with the same function.

We always thought that a change fixed it because reloading the uWSGI server fixes it for a while, and the last change with the proxy headers detection seemed so logic, but I should have been sceptic as also before it worked for a while already, which would have been impossible if the headers were not respected/translated before.

We need to find out where this caching happens and either disable it or assure that it respects the request scheme and/or the proxy headers set by the host’s Nginx instance.

sounds like someone from Armbian guys is hosting the package repository locally at home :slight_smile:

Or it is a VPS. It shows that sometimes the additional complexity and layers that come with packed containers are not always the best solution. It is a black box for everyone who does not have a deep look into it to understand the internals, so that it is hard to identify issues within and solve them.