Updater fails with "More than one candidate with a virtual package ip"

Hi!

I’m trying to setup my Turris Omnia Router but the update fails in the setup wizard as well as when started in the console. The error message is the same in the web frontend and shell: “inconsistent: More than one candidate with a virtual package ip”

root@turris:~# updater.sh
DIE:
inconsistent: More than one candidate with a virtual package ip
uci: Entry not found
uci: Entry not found
uci: Entry not found

I did several 3-led factory resets which do not help.

I’m currently running 3.2.1 but I want to update to the newest version.
Can you help me please?

Dear Marc,
perhaps going through /tmp/updater_crash.log
helps?

M
Stack Traceback
===============
(2) Lua function '?' at line 64 of chunk '"logging"]'M
Local variables:M
 err = More than one candidate with a virtual package ip  {msg:More than one candidate with a virtual package ip, tp:error, reason:inconsistent (more...)}M
 err2string = Lua function '?' (defined at line 45 of chunk "logging"])M
 msg = string: "\
inconsistent: More than one candidate with a virtual package ip"M
 (*temporary) = table: 0x2127340  {msg:
inconsistent: More than one candidate with a virtual package ip}M
(3)  C function 'function: 0xdebbf0'M
(4) upvalue C function 'error'M
(5) Lua global 'pkg_aggregate' at line 266 of chunk '"postprocess"]'M
Local variables:M
 (for generator) = C function: 0xb6ecb140M
 (for state) = table: 0xddb950  {kmod-video-gspca-vc032x:table: 0x175f1d0, gnunet-social:table: 0x1d4b350 (more...)}M
 (for control) = string: "ip"M
 name = string: "ip"M
 pkg_group = table: 0x1dd7070  {virtual:true, modifiers:table: 0x1dd7120, candidates:table: 0x1dd70f0}M
(6) Lua field 'run' at line 339 of chunk '"postprocess"]'M
Local variables:M
 repo_errors = nilM
(7) Lua function '?' at line 56 of chunk '"updater"]'M
Local variables:M
 entrypoint = string: "internal:entry_lua"M
 tlc = table: 0xdea430  {env:table: 0xded2d0, level_check:function: 0xdeaa20, tp:context, sec_level:Full (more...)}M
 ep_uri = table: 0xdeddd0  {ok:function: 0xdeb7e0, tp:uri, cback:function: 0xdee110, callbacks:table: 0xdefc10 (more...)}M
 ok = boolean: trueM
 tls = string: "-- Do not edit this file. It is the entry point. Edit the user.lua file.\
\
local branch = \"\"\
local lists\
if uci then\
-- If something is really broken, we could be unable to load the uci dynamic module. Try to do some recovery in such case and hope it works well the next time.
\
local cursor = uci.cursor()\
branch = cursor:get(\"updater\", \"override\", \"branch\")\
if branch then\
WARN(\"Branch overriden to \" .. branch)\
branch = branch .. \"/\"\
else\
branch = \"\"\
updater_crash.logend\
lists = cursor:get(\"updater\", \"pkglists\", \"lists\")\
else\
ERROR(\"UCI library is not available. Not processing user lists.\")\
end\
\
-- Guess what board this is.\
local base_model = \"\"\
if model then\
if model:match(\"[Oo]mnia\") then\
base_model = \"omnia/\"\
elseif model:match(\"[Tt]urris\") then\
base_model = \"turris/\"\
end\
end\
\
local base_url\
if base_model then\
base_url = \"https://api.turris.cz/updater-defs/\" .. turris_version .. \"/\" .. base_model .. branch\
end\
\
-- Reused options for remotely fetched scripts\
local script_options = {\
security = \"Remote\",\
ca = \"file:///etc/ssl/updater.pem\",\
crl = \"file:///tmp/crl.pem\",\
pubkey = {\
\"file:///etc/updater/keys/release.pub\",\
\"file:///etc/updater/keys/standby.pub\",\
\"file:///etc/updater/keys/test.pub\" -- It is normal for this one to not be present in production systems\
}\
}\
\
if base_url then\
-- The distribution script. It contains the repository and bunch of basic packages. The URI is computed based on the branch and the guessed board\
Script(\"base\",  base_url .. \"base.lua\", script_options)\
end\
\
-- Some provided by the user\
Script \"user-src\" \"file:///etc/updater/user.lua\" { security = \"Local\" }\
-- Some auto-generated by command line\
Script \"auto-src\" \"file:///etc/updater/auto.lua\" { security = \"Local\" }\
\
:local base_url\
if base_model then\
base_url = \"https://api.turris.cz/updater-defs/\" .. turris_version .. \"/\" .. base_model .. branch\
end\
\
-- Reused options for remotely fetched scripts\
local script_options = {\
security = \"Remote\",\
ca = \"file:///etc/ssl/updater.pem\",\
crl = \"file:///tmp/crl.pem\",\
pubkey = {\
\"file:///etc/updater/keys/release.pub\",\
\"file:///etc/updater/keys/standby.pub\",\
\"file:///etc/updater/keys/test.pub\" -- It is normal for this one to not be present in production systems\
}\
}\
\
if base_url then\
-- The distribution script. It contains the repository and bunch of basic packages. The URI is computed based on the branch and the guessed board\
Script(\"base\",  base_url .. \"base.lua\", script_options)\
end\
\
-- Some provided by the user\
Script \"user-src\" \"file:///etc/updater/user.lua\" { security = \"Local\" }\
-- Some auto-generated by command line\
Script \"auto-src\" \"file:///etc/updater/auto.lua\" { security = \"Local\" }\
\
if uci and base_url then\
-- Go through user lists and pull them in.\
if type(lists) == \"string\" then\
lists = {lists}\
end\
if type(lists) == \"table\" then\
for _, l in ipairs(lists) do\
-- TODO: Make restricted security work\
Script(\"userlist-\" .. l, base_url .. \"userlists/\" .. l .. \".lua\", script_options)\
end\
end\
end\
"M
 err = table: 0xdefdc0  {sec_level:Full, tp:context, flags:table: 0xdf0680, name:, hierarchy:table: 0xdf05f0 (more...)}M

~
(END)root@turris:/tmp# 

This listing is mine, its what I get trying to update my freshly unpacked

Turris Omnia - RTROM01
with
Turris OS version 3.2.1
Kernel version 4.4.13-05df79f63527051ea0071350f86faf76-7
Firmware Version OpenWrt omnia 15.05 r49274 / LuCI 3200f7dc985b1ac048a62a96ffae783b3c285448 branch (git-16.212.24666-3200f7d)

with an empty
/etc/updater/user.lua file.
Perhaps this gives you (and me?) a hint on
the duplicate candidate(s) with “a virtual package ip”?
best, bernd.

btw: after 4 hours going through config, manuals, …: I have to say: I love that box! Thank you, CZ.nic!

Ugh. Sorry, this is probably bug on our side in configuration pulled from server. I will look into to it as soon as possible.

1 Like

Dear Marc,
the weekend has passed so I had a chance to talk to my dear collegue, who already runs a Turris Omnia - RTROM01 successfully.
Here is the fix he applied (successfully) to getting away from Turris OS version 3.2.1:

Turris Documentation
https://repo.turris.cz/omnia/medkit/omnia-medkit-latest.tar.gz
in short:
copy the tar.gz-file to a USB-stick (FAT filesystem and a few others are ok).
plug the USB-stick into the front-panel USB-port
keep the reset-button pressed exactly as long until exactly 4 LEDs are lit
the “recovery image” from the github repository (allegedly updated frequently)
then is applied to your box.
A piece of advice: make sure to have any configuration backed
up before you go through that process, if you should want to keep any of it.

Thanks Wolfgang for your help! I am now at version 3.9!

1 Like

Amazing! Thanks! I’ll see whether I can try as as soon as possible.

Just to update. I looked in to it few days after I wrote here, I just didn’t reported it here. From my findings I had no problems with updating from 3.2.1. Only explanation I could come up with is that you had to install package ip explicitly by downloading it and installing it by hand. That would add that package to updater’s configuration in form of Install("ip", {content="PATH"} ). In that case you would really have candidate for virtual package ip. Another option is that you are using some older version of you repositories (either trough updater’s configuration or trough putting it to /etc/opkg/customfeeds.conf. In 3.9 there was a change done (to be more compatible with lede) where original package ip become virtual and instead of it there is a package ip-full. If you add repositories from archive to updater before you are updated to 3.9 then you encounter this problem.

I faced the same error message “Updater failed: inconsistent: More than one candidate with a virtual package ip” with a new device.

Disabling and reenabling of the automatic updated resolved the problem for me.

Hello guys,
from time to time some of you has this issue, who hasn’t connected Omnia from campaign and we’d like to solve this issue. It’s really hard fix something, which we can’t reproduce.

We need:

  • all files from folder /etc/updater
  • all files from folder /usr/lib/opkg

and if it is possible output of this command:

  • pkgupdate -e DBG 2>&1 | tee log

All these files send by email to tech.support(at)turris.cz. Thank you for cooperation.

Then you can medkit it to have the latest version, which will solve this issue.

// Post edited based what @mearon said.

Hey,

I’m also facing this issue. (@Pepe, I wrote with you on IRC turris )
updater.sh -e trace or updater.sh -e debug throws another error for me:

Unknown parameter -e. Continuing anyway, as a compatibility measure for the old updater.
Unknown parameter trace. Continuing anyway, as a compatibility measure for the old updater.

** @medkit **
@Pepe, could you tell me please how I can verify the signature of the medkit image? I found the .sig file here:
https://repo.turris.cz/omnia/medkit/
… and a public key file in the parent directory – but how do I verify it? I’m only used to GPG keys. Thanks!

1 Like

Hi,
Can you try this command?

pkgupdate -e DBG 2>&1 | tee log

//EDIT medkit:
You need to do this on Turris router(s). Otherwise it is necessary to download public key from gitlab and compile usign, which is openwrt sign binary. For Windows it’s very hard to do it and on Linux you need to cross-compile it.

curl -sO https://repo.turris.cz/omnia/medkit/omnia-medkit-latest.tar.gz
curl -sO https://repo.turris.cz/omnia/medkit/omnia-medkit-latest.tar.gz.sig
usign -V -p /etc/updater/keys/test.pub -x omnia-medkit-latest.tar.gz.sig -m omnia-medkit-latest.tar.gz

Looking forward to hearing from you,

1 Like

Hey,

@debugging:
Unfortunately I have already flashed via medkit, sorry!

@signatures:
Thanks for the explanation!
I’ve successfully verified the image on my omnia :slightly_smiling_face:
But it seems it doesn’t add much in security, since I got the key from the same place, where I got the signature and the image from:
https://repo.turris.cz/omnia
GPG signatures would be better, since there a web of trust can be established, thus it’s much easier to make sure the key does really belong to you! E.g. right now, what would prevent an evil sysadmit to just change the medkit image, the signature AND the key file - since it’s all lying on the same server?

Thanks again.

BTW I’m really happy with my router,

THANK YOU TURRIS :sunny:

1 Like

Just some hints about the signatures:

Public keys are installed in the Router from the factory so it can be securely verified from the working router really simple. This verification is native for openwrt packages and it is used to install and update Turris OS packages.

If you don’t have working Router, it is quite tricky to verify it because you need to compile the openwrt usign tool as @Pepe mention above. There is also a possibility to verify it with OpenBSD signify tool (which is available i.e in Debian repositories) . Public keys can be found in our repositories at gitlab for that case.

If you are worried about confidence of the files in the git, the commits are GPG-signed so you are able to verify it as well.

Switching it to native GPG is an option but this will need a lot of changes in the build and deploy process.

cheers :rocket:

UPDATE:
So this simple verification process works on debian-like (stretch at least?) distro:

sudo apt install signify-openbsd
curl -sO https://repo.turris.cz/omnia/medkit/omnia-medkit-latest.tar.gz
curl -sO https://repo.turris.cz/omnia/medkit/omnia-medkit-latest.tar.gz.sig
curl -sO https://gitlab.labs.nic.cz/turris/turris-os-packages/raw/test/cznic/cznic-repo-keys/files/test.pub
signify-openbsd -V -p test.pub -x omnia-medkit-latest.tar.gz.sig -m omnia-medkit-latest.tar.gz
3 Likes

Hey,

thank you very much for the insight on your development process and pointing me to the git repo!
That helps me!

//EDIT:
@vojtech.myslivec, why is the key named ‘test.pub’ in the git repo, which is also used for signing latest medkit images?

Thanks!

It’s a bit tricky.

Medkits are signed during build process (the corresponding key has name test based on the name of the git branch) but not the deploy (release key) when user lists, packages, etc. are signed.

We should probably sign it with release key as well to not confuse users. I will discuss it with my colleagues responsible for the process.

1 Like

Okay, thank you again.

The key test.pub also appears in the stable branch from what I can see, but I as I don’t know much about your internals and git in general, I think I’m satisfied for now :slight_smile:

Though I’m looking forward to a more transparent signing procedure :slight_smile:

Thanks.

How long does the medkit reflash process take? my turris omnia is stuck with the full fixed red led for a while now… and the light on the usb stick is off now; is it normal?

@cynerd was able to reproduce this issue. Thank you guys for help.
Right now he is finding way how to fix this issue! :slight_smile:

//EDIT: Fixed in Turris OS version 3.9.6.


Medkit can take up to 3 minutes.

Maybe you entered rescue shell? We have also video how to do re-flash, which you can see here.

2 Likes

Thank you @Pepe, it was just a matter of bad USB drive. I changed it and recovered the Turris.

Fixed in the Turris OS version 3.9.6, which we released just now.