Updater failing - "repo"?

i just get an error:
[string “postprocess”]:388: attempt to index field ‘repo’ (a nil value)

i don’t want to do a factory default reboot.

how can i fix it?

LE: in the meantime i’ve run a “opkg upgrade” - although i know is discouraged it went alright and router rebooted with the new kernel.
so if other get this issue you could try “opkg upgrade” - on your own responsibility ! - of course !

I’m also having that error, but i’ll wait till further information has been given.

My TO is in a bad shape right now.
I get the same error message.
I did a manual uninstall of the river and then manual install of ath10k-firmware-qca988x.

When doing a:
opkg update; opkg install ath10k-firmware-qca988x; reboot

I get the Signature check passed.
Package ath10k-firmware-qca988x (2016-09-13-b063774393b184c6e1626dec81cf5270cc213c69-1) installed in root is up to date.

I also noticed that my LED setup have changed and as soon as I press Save in the LED setup
the Luci and Foris becoms unreachable. After a while it comes back up but crashes again and again.
I still have SSH access though.

Any ideas? Schnapps reverting?

A schnapps reverting to previous worked out perfectly.
A few missing things but nothing that could not be reconfiged in a minute or two.

Now I have a freshly saved config and a working TO again. Thanks for reminding me about it.

Will keep my itchy fingers from the TO for a day or two now. :slight_smile:

My Wifi have been pretty stable.
I did initially have some problem with the 5GHz band when I used it set to the DFS channels.
But after I did move it down to channel 48 it became stable. It might been that I’m on a airport fly zone and the radars was poking it too much.
There’s also occational military air defence systems running the same frequencies military C-band and I would guess they do mees with the DFS channels too.

Regarding my repo error I continue to get after schnappsing back I’m going to ignore and do nothing about it. I’m touching that area for a while.

We are going offtopic (although i am mostly to blame XD).

About the photo lib service, have you asked around on different forums?

thanks for hijacking my thread :unamused:

Any time bro. If you have started another thread give me a PM so i can gather my pirate crew to start hijacking. :joy:

Just kidding bro.

@davey, lets delete our messages and start a PM conversation.

1 Like

I think that this is known bug. It happens when in specific configuration there is package from repository and locally installed one. This fixes updater version 48, which isn’t released yet, but it is in “rc” branch. See: https://www.turris.cz/doc/en/howto/test_branches.

still got errors:

  • sleep 1
  • mkdir -p /tmp/update
  • get-api-crl
  • cat /tmp/opkg-update-timestamp
  • LAST_UPDATE=1481986683
  • date +%s
  • DATE_NOW=1481987324
  • [ -z 1481986683 ]
  • expr 1481987324 - 1481986683
  • [ 641 -gt 86400 ]
  • do_journal
  • [ -f /usr/share/updater/journal ]
  • echo get list
  • uci get updater.pkglists.lists
  • get_list_pack base core luci-controls nas printserver netutils definitions
  • echo 3/0000000B
  • curl --compress --cacert /etc/ssl/updater.pem --crlfile /etc/ssl/crl.pem -T - https://api.turris.cz/getlists.cgi -X POST -f
  • uci -q get updater.override.branch
  • [ -z ]
  • echo 0000000B0000D822
  • sed -e s/…//
    % Total % Received % Xferd Average Speed Time Time Time Current
    Dload Upload Total Spent Left Speed
    0 0 0 0 0 0 0 0 --:–:-- --:–:-- --:–:-- 0+ SERIAL=0000D822
  • echo 0000D822
  • mkdir -p /tmp/updater-lists
  • [ base ]
  • [ -f /tmp/updater-lists/base ]
  • HASH=-
  • echo base -
  • shift
  • [ core ]
  • [ -f /tmp/updater-lists/core ]
  • HASH=-
  • echo core -
  • shift
  • [ luci-controls ]
  • [ -f /tmp/updater-lists/luci-controls ]
  • HASH=-
  • echo luci-controls -
  • shift
  • [ nas ]
  • [ -f /tmp/updater-lists/nas ]
  • HASH=-
  • echo nas -
  • shift
  • [ printserver ]
  • [ -f /tmp/updater-lists/printserver ]
  • HASH=-
  • echo printserver -
  • shift
  • [ netutils ]
  • [ -f /tmp/updater-lists/netutils ]
  • HASH=-
  • echo netutils -
  • shift
  • [ definitions ]
  • [ -f /tmp/updater-lists/definitions ]
  • HASH=-
  • echo definitions -
  • shift
  • [ ]
    100 106 0 0 0 106 0 421 --:–:-- --:–:-- --:–:-- 424
    curl: (22) The requested URL returned error: 500 Internal Server Error
  • die Could not download list pack
  • echo error
  • echo Could not download list pack
  • echo Could not download list pack
    Could not download list pack
  • echo Could not download list pack
  • my_logger -p daemon.err
  • logger -t updater -p daemon.err
  • kill -SIGABRT 26205
  • rm -rf /tmp/update /tmp/update-state/pid /tmp/update-state/lock /usr/share/updater/packages /usr/share/updater/plan
  • exit 1
  • rm -rf /tmp/update /tmp/update-state/pid /tmp/update-state/lock /usr/share/updater/packages /usr/share/updater/plan
  • exit 1

@maurer what Turris you have please? I thought that you have TO? But this looks like legacy updater, one still running on Turris 1.x.

I have the TO and get the same repo errors.
So I browsed the updater paths and found a stray ath9 ipk from the december 8 in two locations.

/root/ath9k-htc-firmware_2016-09-21-42ad5367dd38371b2a1bb263b6efa85f9b92fc93-1_mvebu.ipk
/usr/share/updater/local-pkgs/ath9k-htc-firmware_2016-09-21-42ad5367dd38371b2a1bb263b6efa85f9b92fc93-1_mvebu.ipk

I deleted the one it root but that did not help.
After deletion of the one in /local-pkgs/ the updater ran through its course.

Restart is needed

The OS kernel has been updated to version 4.4.38+1-1-34abcd5e548fc8ed5390269f3a31d173-1. Please reboot the device.

Lets see how this works out :smiley:

Yes, because you removed local package and now it secretly fails and uses one from repository. Bug was in code that should decide what package should be installed when there was local one (from content field in configuration) and one from repository with same version. Then it should check repository order, but local one had no repository, so nil fail.

But you definitely also have some line like this:

Install "ath9k-htc-firmware"
{content="/usr/share/updater/local-pkgs/ath9k-htc-firmware_2016-09-21-42ad5367dd38371b2a1bb263b6efa85f9b92fc93-1_mvebu.ipk"}

in /etc/updater/auto.lua. You should remove it, because in future versions of updater this will be invalid and that content will be reported as missing.

If you really want to have local package installed, then as I wrote you must have updater version 48 and that version is now in “rc” branch. So wait for release or try “rc” branch.

i have TO - 1gb no wifi version.
i actually installed an intel 7260 and forced installed kmod-iwlwifi because firmware was missing back then.

So is that only output you see if you run updater.sh? If so, you have legacy updater installed. Did you installed package updater using opkg?

Let me explain. In Turris 1.x was updater as just a shell script downloading some precomputed lists and installing packages from those lists. So in background opkg was used. But opkg, if I put it strait, is very bad peace of software. For example it doesn’t check for collisions between packages, so it can install package with file that is already provided by some other package and what is worst it overrides that file. This is probably what you have encountered. If you download package updater, it should collide with package updater-ng, because they both provide file updater.sh. But opkg instead just overrides that file, breaking updater in the process. So my colleague decided that it will be less work to write something from scratch than fixing opkg. That is how new updater was created. Yes it has some new born problems, but what software doesn’t, but in core it is much more resilient piece of software than opkg.

In your case if you really did installed package updater, then unistall it and reinstall updater-ng. And if you were trying to get new version of updater, then be aware that updater-ng is for historical reasons in two packages. Executables are in package opkg-trans and support scripts are in updater-ng.

Really thanks for your help !!!

uninstall, reinstall, switched to rc - still the same error
root@turris:~# updater.sh
WARN:Branch overriden to rc
WARN:Script revision-specific not found, but ignoring its absence as requested
WARN:Script serial-specific not found, but ignoring its absence as requested
DIE:
[string “postprocess”]:388: attempt to index field ‘repo’ (a nil value)
uci: Entry not found
uci: Entry not found

Sorry, my common mistake. It is in master, not in “rc” yet (I thought that we pushed it to “rc” already so ups). But it is down the line. I won’t suggest moving your router to master, so you should probably just wait.

Edit: Updater 49 is now in “rc”. Use previously mentioned workaround by @davey and run updater.sh. Lets see if it solves your problem.

Same error here:
Got this error message form my router today (by mail)

Error notifications
Updater failed:
unreachable: https://api.turris.cz/updater-defs/3.5.1/omnia/base.lua: curl: (60) SSL certificate problem: CRL has expired More details here: https://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a “bundle”
of Certificate Authority (CA) public keys (CA certs). If the default bundle file isn’t adequate, you can specify an alternate file using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in the bundle, the certificate verification probably failed due to a problem with the certificate (it might be expired, or the name might not match the domain name in the URL).
If you’d like to turn off curl’s verification of the certificate, use the -k (or --insecure) option.

when I run updater.sh on my router I get the following messages:

root@turris:~# updater.sh
WARN:Script revision-specific not found, but ignoring its absence as requested
WARN:Script serial-specific not found, but ignoring its absence as requested
WARN:Lock on //var/lock/opkg.lock released by garbage collector

The latests updates weren’t installed my current version is:

Device Turris Omnia - RTROM01
Serial number blablabla
Turris OS version 3.5.1
Kernel version 4.4.39-80079e1c1e5f9ca7ad734044462a761a-3

Thank you

Same error? You have completely different error. See here: Errors in api.turris.cz's CRL

Ou. That links sounds more likely. I’m sorry for the confusion. As I red there this problem is already fixed. Thank you for the link