Updater failing (conflicts?)

I replaced dnsmasq by dnsmasq-full to get DNSSEC support. Now the updater fails. Is there a way to fix this?

Error notifications

Updater failed:
[string “transaction”]:285: [string “transaction”]:132: Collisions:
• /etc/dnsmasq.conf: dnsmasq (new), dnsmasq-full (existing)
• /etc/config/dhcp: dnsmasq (new), dnsmasq-full (existing)
• /etc/init.d/dnsmasq: dnsmasq (new), dnsmasq-full (existing)
• /usr/sbin/dnsmasq: dnsmasq (new), dnsmasq-full (existing)
• /etc/hotplug.d/iface/25-dnsmasq: dnsmasq (new), dnsmasq-full (existing)

I got another issue with the updater. I removed transmission and tinyproxy, and the updater reinstalled the packages. That is a bit annoying. Ideas?


This is happening because updater ensures that all software we list is installed.
So just removing it doesn’t ensure that it won’t be installed back on next
updater run unless updater is configured so. opkg wrapper script handles this, but
you encountered bug it seems.

Current workaround would be to put some code to /etc/updater/user.lua. It should
say something like this:

Unistall "dnsmasq" {priority = 60}
Unistall "tinyproxy" {priority = 60}

This ensures that updater won’t install some package. You have to specify
priority higher that 50, because that is default one and you want to override
Install rule with that priority. Se this link
for some documentation about updater configuration language.

Disclaimer, I haven’t tested if you can do what you are trying to do and if it
will fully work.

In depth, updater is using lists of software. You can enable them or disable
trough Foris. All lists are in fact updater configuration so it contains Install
commands. When you installed dnsmasq-full, opkg wrapper script added line
Install "dnsmasq-full" to /etc/updater/auto.lua (please never ever edit this
file). Collision you encountered is just that updater tries to install both of
those packages because it is what it in fact got specified.


I’ll add just two important pieces of information:

  • The version of updater released to public doesn’t yet handle this, it’ll be possible to do in the next version.
  • Unless you changed a lot of configuration, dnsmasq doesn’t do DNS for you. It is done by knot resolver and it checks DNSSEC out of the box (unless you told it not to).

It worked. Thanks! Also, I am back to knot. Did not know it was active by default. Good to see DNSSEC out of the box.

I would like to also disable re-installing package which I don’t want, I tried the command in user.lua
Unistall "tinyproxy" {priority = 60}
but I am getting this message

I also tried the Install command and that is working fine.

Weafyr, see vorner’s post. I made mistake and referred to functionality that is
not yet released. Updater in current released version doesn’t support it yet. I am
sorry to confuse you. This will work in future.

I see, I got confused by danrl.

Anyway is there any other way to bypass update for 1 package now? But without disable whole updater.

Yeah, sorry, I meant an other updater issue when I shouted “It worked!”. Was not about the uninstall.

Wondering the same thing (planning to replace wondershape by SQM)

1 Like

This seems to be a good temporary solution.

That will unneccesarily wear out the internal flash. So not a really good solution I think…

There should be a blacklist you can define with packages that the updater doesnt touch.

1 Like

As you can see in previous posts, it will be implemented probably in next version of updater.

I would appretiate info, which packages are core (routing, switch, wifi/device drivers, IPv4, IPv6, firewall), and which are optional, installed as “addition” (like VPN, collect, proxy). The best would be have one “core” snapshot avaible.

It is good practice to me, have only things, which I really need. From times 640kB, but still today its good to have nice clean OpenWRT with OpenVPN and LUCi running smoothly on 4MB TP-Link router.

And my experiences are, more stuff = morelike something broke eventually.

Could I ask developers or experience users, to list all necessary packages, which comes with “routing, networking”? I would like to uninstall all others, and install only few which I really needs add to router (OpenVPN, Samba/NAS, SQM and wakelan in my case). I dont want bloated OS, with software I dont want to use.

And also in that case future updates will be much more easy and smooth, log will be less overwhelmed… I like this situation in my todays router… stability! :slight_smile:

I was thinking, that Omnia comes clean from factory, and we can install whatever we want more, but according fresh users posts I am little bit dissapointed thats not the case (?) :head_bandage:. For example, why is there dnsmasq, when kresd/unbound is used for real stuff, etc.

dnsmasq is used as the dhcp server. So … bad example :wink:

Good info, thanks. I am used that dnsmasq do dns resolv and dhcp… not sure how is it in omnia, but there are three programs doing same kind of things then?

If you mean DNS wise, yes. We want DNSSEC, so dnsmasq is out because of some bugs regarding that. Then there are knotd which is a cz.nic creation and unbound, which is not so “exotic”. You can switch between them by editing the etc/config/resolver file.

Yes, that was my original point. I would like to have “clean” snapshot, with only needed (networking) packages, and not more packages to the same thing. We can modify conf. easily, I dont think thats good idea to install more “choices” by factory default.

I am far from expert, so basically my common sense is: dnsmasq didnt suite us (although I would live fine without DNSSEC, but I am willing to take DNSSEC as basic routing core package, no problem here), lets replace it by XY. XY should ideally replace dnsmasq funct. entirelly, and we shouldnt then use dnsmasq between default packages at all (replaced by XY). Lets say that ideal XY doesnt exists. Ok, we leave here XY + dnsmasq, with divided functionality (or XY + YZ). (and maybe in this case write about it a few words on blog or something, bcoz dnsmasq are so widely spreaded via wrt…optionall). You know what I mean? I love possibilities of OpenWRT, dont get me wrong. But its essencial to keep core features as minimal as they can be. Otherwise, regular user dont have experience to differentiate between core parts of system, and additional parts which are added just for “lets add some sugar to this candy”. And I am afraid that I will end in try remove and watch if something needed is broken… or not? I just dont know all packages to review, if they are needed or not :frowning:

Writing a few www pages about opkg install XYZ with some sauce is much much better (and keep door opened) than include things with duplicite functionallity, or not needed things by default (reasons above).

Personally, I will install DB, samba, OpenVPN there, and I looking forward to it. But I expect to install it as additional of clean Turris OS. And in my eyes, DB, collect, multiple DNS resolvers, VPN and so on… all that belongs to “allow to install” category. Not default. On the other hand iptables, DNS resolv, DHCP, SQM, luci, http for www interface of router etc., are essentionally packages, which should be in the default factory snapshot.

More things, lesser chance to stability, more painfully updates and better chance to “catch a bug”… Keep it simple and clean… Thats my opinion, I believe its correct :slight_smile: (but who not to think that :slight_smile:

Newbie. Just unpacked and tested for about 24 hours… Great work with your project. Keep it up till you meet all your set out goals and promises from the pitch/campaign.

I agree with some of the earlier posters. To enable or disable (permanently) modules should be functionality out of the box and in the GUI. If i choose too “remove” (since the “remove”-option is there, in the GUI) a package the box (your distro) should assume I actually do not want that package (ever again…). Anything else is just broken… I spend about an hour to “clean” up my router (not wanting it to be a torrent client, DNLA-device, webcam-whatever etc.) just to have all of it re-installed today when the router updated. WTF!? I thought I bought a good, self-maintained router/firewall with better security than your typical consumer product… It seems to have potential to be but right now it’s nowhere near that state…

I also read in another thread that documentation was “just for idiots”… I beg to differ. Documentation is key to not have to answer 20 questions from each user trying to set the unit up for his/her needs. All high quality, professional tech projects offer documentation (WiKi-style is fine, no need for printer hardbacks).

Do not forget what the project set out to supply. Something far better than “all the dumb, not updated, useless and difficult to control consumer routers out there”. When making such a pitch you have to assume you will get quite a few “not necessarily linux-prone, router technician”-customers… People that loves and breaths OpenWRT are already running it on standard PC-hardware. This box is for all of us that like when someone else makes the OpenWRT solution easily digestible and easy to use without having to consider “script things to automatically be uninstalled after being installed even though they were removed”…

Any progress on when the revised Updater will be released - I am getting regular email notifications telling me the updater failed after I have installed dnsmasq-full which I would rather not get… I don’t want to disable updates or emails - so would be good to get a timescale :slight_smile:


i have similar issue with vsftpd vs vsftpd-tls and ngircd vs ngircd-ssl. Updater.sh try to update/install no-tls/no-ssl package first and always fails on conflict. Above mentioned workaround in user.lua fixed “vsftpd” and , manual remove/reinstall “ngircd” issue.

[update] as i was fixing some other stuff, playing with my router (openvpn, honeypot, ssh forwarding/port-nock) … i removed several services, force-reinstall those i want back, remove many *-opkg configs, cleanup lot of images via schnaps … later router announced new updates for kernel. And after restart/update i had to reinstall few luci-app packages. Schnaps-it! Restart and voila all seems to be fine. (only lxc was still having some issues, but that’s another story from another thread)