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:
opkg.conf:
dest root /
dest ram /tmp
lists_dir ext /var/opkg-lists
option overlay_root /overlay
option check_signature
opkg\customfeeds.conf:
# add your custom package feeds here
#
# src/gz example_feed_name http://www.example.com/path/to/files
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:
Install("python")
and
Install("foris-pakon-plugin")
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.
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
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!
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 8.8.8.8 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!
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.