Adblock not creating/updating adb_list.overall (Omnia with adblock1.3.3-1)

Hello all,

I have installed adblock via LUCI. It also seems to be updating blocking sources somehow, I can see in logs,
I have also updated /etc/config/resolver with “list rpz_file ‘/etc/kresd/adb_list.overall’” in kresd" section.

Even I restat adblock service manually adb_list.overall file is not updated.

Any idea what am I doing wrong?

Honza K.

Adblock in TurrisOS repo is quite old, so you should install last release with this howto Adblock package release for turris omnia


You need to create a cron job so Adblock can check for updated blocking files. The easiest way is to paste the line below into your ‘scheduled tasks’ in the Omnia interface. The line says to reload Adblock everyday at 6:00am, this forces Adblock to update the blocking files.

0 06 * * * /etc/init.d/adblock reload

I hope this answered your question.

1 Like

Even if you install the correct version from the Lede repository, it will be overwritten again.
I installed last week the most recen version which was: adblock_2.6.2-1_all.ipk. and
Next day it got overwritten by:

Update notifications

• Installed version 1.3.3-1 of package adblock
• Installed version git-17.212.24321-49c3edd-1 of package luci-app-adblock

I don’t know what to do

Is your system updated? This seems like you encountered bug with localrepo that was in 3.9. In pre-chirstmas release 3.9.1 we fixed it. Can you please do localrepo list and cat /usr/share/updater/localrepo/localrepo.lua to let me see if that is the case?

This adblock version does not support kresd on Turris Omnia devices.
Please install & use only the latest snapshot version, see here.

I did a fresh install of adblock today with the which is brandnew in the LEDE repository, now everything seems to work fine.

root@turris:/tmp# localrepo list
adblock: 3.4.0-1
luci-app-adblock: git-17.362.62617-4f644d9-1
root@turris:/tmp# cat /usr/share/updater/localrepo/localrepo.lua
– Auto-generated updater-ng configuration
Repository(‘localrepo-auto’, ‘file:///usr/share/updater/localrepo/auto’)

What is reason for this new localrepo, and how it works? Is this functionality ( + Install command in user.lua) somehow replaced in 3.9 > ?

I think lot of people have custom packages installed and prevented that way to survive update.

Well original implementation was as you correctly pointed out using content. Original idea wasn’t that bad but when we implemented it we found out that we have to drag real package trough places where we only work with repository indexes. That complicated code and was used only for this single feature. That wouldn’t be too bad if there wasn’t easier way, just create repository directly on router. That is what localrepo is for. It creates repositories for updater/opkg on router (they are currently automatically added only to updater). So we are obsoleting content option and replacing it with localrepo for future cleanup. On note how it works, you can read code (it’s pretty short python script) or just run localrepo --help.

Not replaced, not yet, but obsoleted. I haven’t got around to updating documentation but that section will be replaced with note about localrepo. Note that localrepo just provides convenient way to create opkg repository, to have it installed you have to have install command in updater’s configuration.

You might be too much generalizing your self. In reality only few people reported problems so I suspect only tens of peoples to really have some custom packages. And that migration wasn’t that smooth is bad but in reality if you were able to install custom package then you should be able to also fix it.

1 Like

Thanks. So basically (cant test localrepo commands, as I running 3.8.4), in future, we should replace Package commang with copying .ipk into some localrepo’s directory, and keep Install command in .lua (propably slightly modified to differentiate local and turris repo), correct?

I am find with it, as long you document this approach (I mean, how to keep custom packages during update) before it will change status from obsolete to removed :slight_smile:

I still miss repeater ([PACKAGE] Ultra VNC Repeater) in turris repo, also some collectd packages, newest adblock, and more importantly (as already mentioned propably comes with LEDE merge?), I am depending to specific MySQL version, so I need to know, that updater doesnt touch my custom packages; even if they are avaible newer in turris repo)

That wasn’t possible before with content as that just simply added given package version (I might be wrong. I don’t remember everything and I am using localrepo for about a half year for now). Now with localrepo you can specify source repository with ease in install command (Install("pkg", {repository = "localrepo-NAME"})).

Well yes and no. You don’t want to do that manually but you should use localrepo (as that script handles index creation and simply copying to correct directory won’t create new repository index). But overall yes. Even if you were using opkg wrapper (just opkg command) to install them then it should be migrated automatically (all content fields in auto.lua are automatically migrated).

There will be a section for it in updater’s documentation before we drop it. It’s not the first obsoleted feature and won’t be last. If you run new version of updater from cli it will tell you if you are using some obsoleted syntax or option.

That wasn’t possible before with content as that just simply added given package version (I might be wrong. I don’t remember everything and I am using localrepo for about a half year for now)

To stay within topic, this works always without problem for me (ie. no rewrite with outdated turris repo version, through multiple updates of Turris OS):

Package(“adblock”, { content = “file:///root/upravy/packages/adblock_3.1.1-1_all.ipk” })
Package(“luci-app-adblock”, { content = “file:///root/upravy/packages/luci-app-adblock_git-17.340.61105-78ebfba-1_all.ipk” })

so I dont have problems as @GS01. I always manually check / correct .lua files, as I want to have control over the router - so I am using my path for example, not generated via auto.lua.

Although and again, I stay on 3.8.4, when I saw “custom packages problems” with 3.9. Should be fixed on 3.9.1, but I think I will wait for 4.0 :slight_smile:

Outdated no, but newer yes. You were also talking about new versions with mysql. That is what I was reacting on.
@GS01 problem was that localrepo was broken so updater didn’t know about never version of package.

That might be farther than you think. After 3.9 there won’t be immediately 4.0 but 3.10. Also updating to version 4.0 will be headache just from latest version. So you can be sure that I will be very angry if you come with some problem while updating from 3.8.4 (just small heads up that I probably will be very harsh).

Thanks for heads up :slight_smile:

Outdated no, but newer yes.

Ah! Thats unfortunate… So, with new feature / localrepo, that behauviour will be the same (newer overwrites custom)? I guess I could just change the name of the package to something different, would that help?

updating to version 4.0 will be headache just from latest version
Please, no :slight_smile: But, I get you point, I monitoring forum, so I hope I catch all “possible blockers” before hand (the same as previously updater-ng note, which force me to update one time just to be cautious about future update problems)…

In the other hand (and sorry to be that offtopic), the newly bought Omnia on original firmware should be also be upgradable, so I am hoping it will not be any major problems. Bottom line is, that I dont neet any updates beside security ones (OpenVPN, KRACK, etc.), and every update takes a portion of my time - recovering my .conf files, reviewing possible changes on updated packages with my configuration / possible new parameters for the newer version of package etc., so I trying to keep those updates on lowest (safe) number possible.

No you missed the point. It wasn’t possible with content but is possible with localrepo. I even gave you an exact way in one of my previous posts.

Yes but those have one version of firmware. Any other version can have problems. And also we do sometime sneaky stuff such as that we override some configurations or force restart router when you have way old version of firmware (which is fine if you are updating from old version of factory but not if you do the same with live router).

I have this entry in Scheduled tasks:

0 6 * * * /etc/init.d/adblock reload

anyway it is not working.
If run “/etc/init.d/adblock reload” manualy it says:

adblock[25709] info : adblock installation finished successfully, 'opkg' currently locked by package installer

then if I run opkg update it finished sucessfully, then I am able to run /etc/init.d/adblock reload and it is updated. Any hint to that?

Other thing is that file adb_list.overall is not created in /etc/kresd. Any idea where it is created?

Thx all

This message comes from the ancient adblock 1.3.3 version - which does not support turris omnia! Please install latest snapshot version (link already posted by me above in this thread)