Which version of adblock do you have installed? In OpenWrt 19.07, there were introduced a new version of adblock 4.0.3 and LuCI changes for that. I guess that update and reboot should solve it. But @dibdot should know more about it.
You’re correct. I got update for packages today that I approved but I did not know it would be advisable to reboot it. Thank you.
It’s sufficient to clear the luci caches (rm -rf /tmp/luci-*
).
Said that, I’ve tested adblock only with hbd and hbl branch aka TurrisOS 5.1.x … I’m not sure if 5.0 is sufficient …
MOX classic .5GB WiFi HBK: after long long time first successful reboot after last update:
Update notifications
• Installed version 1-1.0 of package fix-updater-v65.0-alternatives-update.
Great!
After last update Luci / Foris is inaccessible.
Luci
/usr/lib/lua/luci/dispatcher.lua:315: /etc/config/luci seems to be corrupt, unable to find section ‘main’
stack traceback:
[C]: in function ‘assert’
/usr/lib/lua/luci/dispatcher.lua:315: in function ‘dispatch’
/usr/lib/lua/luci/dispatcher.lua:208: in function </usr/lib/lua/luci/dispatcher.lua:207>
I had the same on HBL - rollback to pre-update snapshot helped.
Is the snapshot created automatically? I had automatic updates but I think it would be better to approve it and before that to create snapshot.
EDIT: It seems like it is by using
schnapps list
I see just output just for LuCI. What means “Foris is inaccesible”?
Please take a look at my post here:
We can not help you until further details are provided.
I believe it might have something to do with the last update or more precisely with missing packages.
I know I’m on HBL, but I was facing exactly the same same issue as @hello_friend, luci
throwing same error and foris
loading indefinitely, only reforis
was working partially. After roll back to snapshot before update, everything works as it should, but when I update, issues are back.
Examining what pkgupdate tries to do, there are several removals including packages like python-base, which I believe foris depends on:
pkgupdate removals:
INFO:Queue removal of luci-app-rainbow
INFO:Queue removal of luci-i18n-ahcp-cs
INFO:Queue removal of luci-i18n-adblock-cs
INFO:Queue removal of luci-i18n-transmission-cs
INFO:Queue removal of luci-proto-relay
INFO:Queue removal of luci-proto-openconnect
INFO:Queue removal of luci-app-sqm
INFO:Queue removal of luci-i18n-tinyproxy-cs
INFO:Queue removal of luci-i18n-ahcp-en
INFO:Queue removal of luci-i18n-minidlna-cs
INFO:Queue removal of luci-i18n-bcp38-en
INFO:Queue removal of luci-proto-vpnc
INFO:Queue removal of python-logging
INFO:Queue removal of luci-i18n-bcp38-cs
INFO:Queue removal of luci-app-bcp38
INFO:Queue removal of luci-i18n-upnp-en
INFO:Queue removal of luci-i18n-upnp-cs
INFO:Queue removal of luci-app-upnp
INFO:Queue removal of luci-i18n-mjpg-streamer-en
INFO:Queue removal of luci-i18n-statistics-cs
INFO:Queue removal of luci-i18n-tinyproxy-en
INFO:Queue removal of luci-app-tinyproxy
INFO:Queue removal of relayd
INFO:Queue removal of python-multiprocessing
INFO:Queue removal of python-light
INFO:Queue removal of openconnect
INFO:Queue removal of python-base
INFO:Queue removal of miniupnpd
INFO:Queue removal of bcp38
INFO:Queue removal of luci-i18n-mjpg-streamer-cs
INFO:Queue removal of luci-app-mjpg-streamer
INFO:Queue removal of tinyproxy
INFO:Queue removal of luci-app-ahcp
INFO:Queue removal of ahcpd
INFO:Queue removal of l10n_supported
INFO:Queue removal of luci-i18n-statistics-en
INFO:Queue removal of luci-app-statistics
INFO:Queue removal of luci-lib-iptparser
INFO:Queue removal of rrdtool1
INFO:Queue removal of collectd-mod-rrdtool
INFO:Queue removal of librrd1
INFO:Queue removal of collectd-mod-iwinfo
INFO:Queue removal of collectd-mod-cpu
INFO:Queue removal of collectd-mod-interface
INFO:Queue removal of collectd-mod-load
INFO:Queue removal of collectd-mod-network
INFO:Queue removal of luci-i18n-transmission-en
INFO:Queue removal of luci-app-transmission
INFO:Queue removal of collectd-mod-memory
INFO:Queue removal of luci-i18n-minidlna-en
INFO:Queue removal of luci-app-minidlna
INFO:Queue removal of minidlna
INFO:Queue removal of libexif
INFO:Queue removal of libffmpeg
INFO:Queue removal of libspeex
INFO:Queue removal of alsa-lib
INFO:Queue removal of kmod-sound-core
INFO:Queue removal of libfreetype
INFO:Queue removal of libpng
INFO:Queue removal of libid3tag
INFO:Queue removal of libflac
INFO:Queue removal of mjpg-streamer
INFO:Queue removal of libjpeg
INFO:Queue removal of vpnc
INFO:Queue removal of libgcrypt
INFO:Queue removal of kmod-tun
INFO:Queue removal of vpnc-scripts
INFO:Queue removal of libtasn1
INFO:Queue removal of libvorbis
INFO:Queue removal of libogg
INFO:Queue removal of luci-i18n-adblock-en
INFO:Queue removal of luci-app-adblock
INFO:Queue removal of adblock
INFO:Queue removal of coreutils-sort
INFO:Queue removal of libgpg-error
I’m further convinced by this, because after reinstalling those packages and restarting the router, everything worked as it should.
Make switch-branch hbk again and wait for next fixes. Updater tab is still broken but pkgupdate works.
This morning update MOX Turris 5.0.0 HBK:
##### Oznámení o chybách #####
Updater selhal:
inconsistent: Package foris-ws requires package python3-ubus that is not available.
Thanks for reporting. This happened just for Turris MOX build. There were some issues with downloading dependencies for this file and I’ve just started a new build for Turris MOX.
Another error, MOX 5.0.0 HBK:
Oznámení o chybách
Updater selhal:
inconsistent: Requested package collectd-mod-ping that is not available.
I’m working on this one. Thanks.
Ok, the package should be there since this afternoon.
After updating to 5.0.0
, when I run:
$ pkgupdate
I see:
INFO:Target Turris OS: 5.0.0
...
ERROR:
inconsistent: Package python3-flask requires package python3-werkzeug that is not available.
How can I fix that? I would like pkgupdate
to finish…
May I know which router are you using?
I see that both packages are present in HBS (Stable), HBT (Testing), HBK for all of our routers.
Turris 1.0 & Turris 1.1:
HBS and HBT are for now same until we release a new version in Testing branch:
https://repo.turris.cz/hbs/turris1x/packages/packages/python3-flask_1.0.3-3.7-1_powerpc_8540.ipk
https://repo.turris.cz/hbs/turris1x/packages/packages/python3-werkzeug_0.15.2-3.7-1_powerpc_8540.ipk
HBK:
https://repo.turris.cz/hbk/turris1x/packages/packages/python3-flask_1.0.3-3.7-1_powerpc_8540.ipk
https://repo.turris.cz/hbk/turris1x/packages/packages/python3-werkzeug_0.15.2-3.7-1_powerpc_8540.ipk
Turris Omnia:
Stable and Testing:
https://repo.turris.cz/hbs/omnia/packages/packages/python3-flask_1.0.3-3.7-1_arm_cortex-a9_vfpv3-d16.ipk
Turris MOX:
Stable and Testing:
https://repo.turris.cz/hbs/mox/packages/packages/python3-werkzeug_0.15.2-3.7-1_aarch64_cortex-a53.ipk
https://repo.turris.cz/hbs/mox/packages/packages/python3-flask_1.0.3-3.7-1_aarch64_cortex-a53.ipk
HBK:
https://repo.turris.cz/hbk/mox/packages/packages/python3-flask_1.0.3-3.7-1_aarch64_cortex-a53.ipk
Flask is being used by reForis and werkzeug is dependency for python3-flask, so we would notice that if those packages are missing.
I am using Turris Omnia (hbk branch). It looks like the packages were pulled in with an update that happened 2 hours ago. They did not show up with opkg find
before…
Flask is being used by reForis and werkzeug is dependency for python3-flask, so we would notice that if those packages are missing.
Yeah, I found that much and it was really confusing to me why it would happen that the packages were missing (opkg
correctly reported these dependencies). I did do opkg install reforis
before, so I am wondering it ended up in some half-assed state or what.
So, problem fixed. Thanks for your help.