Luci inaccessible

Indeed. Rebooting makes the Foris interface working again after a reboot when applying the workaround

Thank you for working workaround.

+1 affected here.

Thanks for the workaround. Likely there was an update to my Turris OS 5.0 HBT - LuCi and Foris were working until something has changed today. Foris just hang, LuCi reported issue with the config (section ‘main’).

I have tried to restart rpcd, no luck. Reboot, no luck. Only after I have applied the workaround and rebooted, both Foris and LuCi are working again.

just had the same issue… and after figuring it out and reporting it i just found this thread… murphy at his best :wink:

anyway reported it here foris & luci unreachable on 5.0 (#597) · Issues · Turris / Turris OS / Turris OS packages · GitLab but don’t know whether that’s the correct repo. just couldn’t find a turris-os repo anywhere…

Been reported previously [python2] removal renders LuCI inaccessible due to missing binary path (#142) · Issues · Turris / Turris OS / Turris Build · GitLab

Reported but dismissed. :frowning:

Not dismissed. The issue was already present in HBT and it is present there as well. See reports in HBT thread. There is a missing conversation as it was deleted by the OP. More details are included in the issue

  • So far, on support we received only one diagnostics as I requested them directly in that issue.
  • If there any bugs, documentation for Getting help should be followed
1 Like

I’ve noticed that most of the problems begin after I try to login to Luci. If I restart and try foris, it works. But as soon as I try logging into Luci, problems begin.

I’ve also noticed /sbin/rpcd -s /var/run/ubus.sock -t 30 throttles 13% CPU once I try logging into Luci.

thanks, I had the same error in luci, symlinking and restarting rpcd (and lighthttpd just in case) did solve it for luci your solution

I have not rebooted yet as for foris I’ll can wait for a proper/official fix but being without luci was kind of hindering

I was trying to debug it but looking at the completely wrong places.

Hi, I too encountered the issue.

For now my workaround was to reinstall python 2.7 via ssh:

opkg install python

and reboot (although i did not test if it was mandatory):


Maybe this is useful for users of the HBT/HBK-branch until the missing dependencies on python 2 are resolved.

why is it being implemented then python3-python: add new package (815a080c) · Commits · Turris / Turris OS / Turris OS packages · GitLab?

There is still internal discussion ongoing and will be explained. It is on review, wait for it.

Guys, maybe it’s not a problem with TurrisOS 5. Maybe it’s a problem with how we installed it. I’ve sent diagnostics to @Pepe and he found out I did the install wrong.

After you rollback to factory (or get to a clean state using any other way), you open up the setup guide, set WAN connection, and you right-away ssh to the router and call switch-branch hbt. If you first finish the guide and then call switch-branch hbt, you get a crippled install.

With the correct installation process, I got a TurrisOS 5 version where Luci, Foris and reForis all work great.

1 Like

The last time done a medkit reset been with TOS4.x and since then only used with switch-branch, probably a few other users done so as well.

crippled to which extent?

To the extent Luci doesn’t work? :slight_smile: I don’t know exactly, maybe @Pepe could add his five cents.

Maybe there’s a problem with the upgrade from TOS 4. Could someone else try to get TOS 5 medkit and set up the router as described in my previous post?

The culprit has been probably found. No need to create the python3 link.

1 Like

There is likely more to it since the exec path in the file usr/libexec/rpcd/ seems to be the same in TOS4.x as in TOS5.x and therefore somehow falls short as explanation of why upgrade installations from TOS4.x -> TOS5.x are impacted but clean TOS5.x installation are not.

Bug was identified and examined! This is going to be fixed in RC3 version of Turris OS 5.0. We would like to thank you anyone who helped us in the issue, which was mention here.


Are you going to stick with the symlink package anyway? If not anyone having currently implemented the sysmlink should probably remove it then.

As fallback solution in any case it will stay there although with upcoming version of OpenWrt 20.xx and many distributions the symlink is introduced. The only exception is OpenWrt 19.07.

1 Like