Python and foris-pakon-plugin packages no longer available

These two notifications routinely pinging me of late:

inconsistent: Requested package foris-pakon-plugin that is not available.
inconsistent: Requested package python that is not available.  

Started maybe a few weeks ago, and has been non stop.

From reFrois:

Device	Turris Omnia
Serial number	47244708159
reForis version	1.1.2
Turris OS version	5.4.4
Turris OS branch HBS
Kernel version	4.14.294Device	Turris Omnia

In case it helps from Luci:


dest root /
dest ram /tmp
lists_dir ext /var/opkg-lists
option overlay_root /overlay
option check_signature


# add your custom package feeds here
# src/gz example_feed_name


src/gz turrisos_core
src/gz turrisos_base
src/gz turrisos_cesnet
src/gz turrisos_luci
src/gz turrisos_node
src/gz turrisos_packages
src/gz turrisos_routing
src/gz turrisos_sidn
src/gz turrisos_telephony
src/gz turrisos_turrispackages

What gives? Something changed?

Check your and delete the lines about that packages or try to manually delete them.

Python is out of life in the place of python3 and foris-plugin is also depreciated in the place of reforis-plugin

Edit: /etc/updater/conf.d/opkg-auto.lua

1 Like

Where is

locate returns nothing not even after updatedb


# ls -lr /etc/opkg*
-rw-r--r--    1 root     root           108 Sep 12 20:59 /etc/opkg.conf

drwxr-xr-x    1 root     root           160 Oct  1 01:13 keys
-rw-r--r--    1 root     root           728 Oct  1 01:14 distfeeds.conf
-rw-r--r--    1 root     root           103 Sep 12 20:59 customfeeds.conf


find /etc -name returns nothing

I see I have both pythons (am mighty glad python 3 is on now, as indeed python2 is deprrecated:

## python --version; python3 --version
Python 2.7.18
Python 3.7.13

Though it is time that python mapped to python3 and python2 was the old version.

Still, not sure how to remove it.

I checked /etc/updater/conf.d/opkg-auto.lua alas it is headed:

-- A file with auto-generated Install commands. Do not edit.

suggesting there is a source for this information more fundamental than this file. But I do see in there:




suggesting we’re in the right direction. We just need to know how this file is autogenerated, from what source.

It also begs the question how and why auto updates have caused such inconsistency to begin with (surely their job to do these fixes whatever they end up being).

I have been waiting patiently and with hope for a pakon performance boost as it has forever been so non-performant as to be sadly useless. Perhaps this change will bring one, as one was promised a while back ;-). I have kids and so would love to see a functional pakon.

Just delete those lines and run pkgupdate.

Pakon is fully functional with python3 and reforis-plugin.

The problem might appear because you might have ran opkg install python in the past and it stayed there as manually installed

And just to be sure run opkg remove python and the pakon plugin

Well, that (pkgupdate) kick-started an upgrade to 6.03. It just took a schnapps snapshot (good move!) and is respecting my configs (nice) if I’m lucky all will be working again after …

Well that broke everything … thank heavens for schnapps. Rolled back and am up again. Will have to diagnose upgrade paths later, too late now, just glad to be operational again. Methinks the upgrade wreaks havoc with my configs after all. But for another day when I have more time to look at it.

I kept a log of the output, and I have pre and post snapshots to compare ;-). Gotta love schnapps!

    # | Type      | Size        | Date                      | Description
  469 | time      |    56.86MiB | 2022-10-30 01:05:01 +1100 | Snapshot created by cron
  470 | time      |    51.97MiB | 2022-11-06 01:05:02 +1100 | Snapshot created by cron
  471 | time      |   128.11MiB | 2022-11-13 01:05:01 +1100 | Snapshot created by cron
  472 | time      |    55.35MiB | 2022-11-20 01:05:01 +1100 | Snapshot created by cron
  473 | time      |    47.35MiB | 2022-11-27 01:05:02 +1100 | Snapshot created by cron
  474 | pre       |   448.00KiB | 2022-11-27 22:22:44 +1100 | Automatic pre-update snapshot (TurrisOS 5.4.4)
  475 | post      |   956.00KiB | 2022-11-27 22:31:44 +1100 | Automatic post-update snapshot (TurrisOS 6.0.3)
  476 | rollback  |     3.73MiB | 2022-11-27 23:03:42 +1100 | Rollback to snapshot 474

But your issue with updater and missing packages was solved right? Mark that as solution and join complaining about TOS 6.0.3 here Turris OS 6.0.3 is now released - #50 by Mannshoch :smiley:

Not sure if it was solved, no time to check, but I imagine it was ;-). Thanks for the link. It did another autoupdate overnight and broke everything again. Schnapps to the rescue. Will turn off autoupdates for the moment. I’ll take a look at the snapshot differences later as time permits. There were only 3.73MB in the rollback snapshot, which is encouraging, or maybe not, maybe rollback snapshots are so small as they refer to a prior larger one. BTRFS rocks!

Had the same problem.

Solved it like this:

  1. Removed the Install("foris-pakon-plugin") and Install("pakon") /etc/updater/conf.d/opkg-auto.lua
  2. Ran pkgupdate via ssh, rebooted the box
1 Like

Thanks tried that and on step 2 it died with:

DIE:Failed to fork command //etc/updater/hook_preupdate/ Out of memory

Dang. Will reboot the router and try again.

Perhaps you can try to rollback to a different checkpoint in the past in schnapps, and try it from there?

Alas this killed my system effectively again. I traced it provisionally without explanation and it’s in a space I wish I understood better. But here’s what happens. After pkgupdate my router updates from 5.4.4 to 6.3 and much breaks.

I can no longer reach the router. But if I configure my desktop to use a static IP (not DHCSP) then I do succeed. Conclusion, the DHCP server dies in the upgrade.

But then I cannot reach the WAN from any LAN device. But I can from the router. So on the Omnia ping is happy but from any LAN device not.

Still not time for deep diagnostics so I do indeed roll back with schnapps to a known safe snapshot. DHCP comes good, but WAN forwarding is still broken. Alas, this does not fix it. I try another earlier one. DHCP is good but still WAN forwarding broken.

the MUST be a firewall issue. So I scan /etc/config/firewall but it big and unclear. So instead in Lucy I go here:

See anything suspicious? I do, that last line. I delete it. Save and Apply. All WAN forwarding works again.

Twilight zone material.

So I rollback again and confirm I see the same. This time I take a copy of /etc/config/firewall then delete that line and save and Apply and I see many changes but none that explain that blank line. In fact I copy the old /etc/config/firewall back, reload Luci and thee is no blank line on that Firewall page. There were lost of changes mind you, Save and Apply trashed a pile of my port forward rules. They all came back when I restored /etc/config/firewall.

Conclusion: that blank line comes from some other config file, not /etc/config/firewall. As yet unidentified. And oddly is restored broken from sound tested snapshots!

Twilight zone.

Did you reboot the router after the upgrade?

Yep. Alas, it killed the DHCP service, which I would need to diagnose, which I lack for time now and it added this odd empty line on the firewall config that I’d also like to better understand. So I’m rolled back to 5.4.4. for now with that last odd line in the firewall config (which appears magically from some unknown source, even though I’d rolled back to a clean snapshot that has been tested in past) deleted. I hope some day to make time to diagnose all this and upgrade the route successfully. Fortunately, schnapps offers all the diagnostics to make that possible with enough time invested into diff analyses.