Pkgupdate fails when asserting string "transaction"

Software SW help
1

Hi,

I’m trying to run pkgupdate, but I get this error:

> root@turris:/# pkgupdate -e DBG

DEBUG:src/lib/events.c:580 (run_util_init):Dumping busybox to: /tmp/updater-busybox-NHFieI/busybox
INFO:src/pkgupdate/main.c:239 (main):Detected existing journal. Trying to recover it.
DEBUG:src/lib/locks.c:44 (lua_acquire):Trying to get a lock at //var/lock/opkg.lock
DEBUG:backend.lua:343 (status_parse):Parsing status file /usr/lib/opkg/status
DEBUG:src/lib/journal.c:124 (journal_open):Opening journal
line not found
line not found
line not found
line not found
DIE:src/pkgupdate/main.c:241 (main):
[string "transaction"]:365: assertion failed!
Aborted

What can I try to fix this?

2

This is happening because of invalid journal. Looking in to the issue it seems like journal content duplication. I presume that this can happen only if there were two updater instances running at the same time and that can happen only if lock was removed…

Just remove journal: /usr/share/updater/journal

Just to note: you should not remove journal in general but in this case it makes sense if it is corrupted.

3

Thank you, that worked!

But now it gets stuck forever at firewall.postinst configure

DEBUG:backend.lua:1009 (script_run):Running postinst of firewall

DEBUG:src/lib/interpreter.c:320 (lua_run_generic):Command: /usr/lib/opkg/info//firewall.postinst configure

4

This is not because of firewall postinst but package that was listed to be installed right after that one. That is known oversight that we print output from postinst only when postinst exits. You can use trace output level to see what is exactly run and what hangs.

5

Hangs here:

DEBUG:backend.lua:1021 (script_run):

DEBUG:backend.lua:1009 (script_run):Running postinst of firewall

DEBUG:src/lib/interpreter.c:320 (lua_run_generic):Command: /usr/lib/opkg/info//firewall.postinst configure

TRACE:src/lib/events.c:542 (run_command_a):Running command /usr/lib/opkg/info//firewall.postinst

6

Can you please post output of pstree -a $(pgrep pkgupdate) to see hot it hanged up?

Optionally you can try to kill that firewall postinst if it runs. I expect that it won’t because most probably it is doing something nasty that causes stdout or stderr to stay open.

You can also try to run that postinst by your self to see if anything bad is happening.

7

pkgupdate -e TRACE
-sh /usr/lib/opkg/info//knot-resolver.postinst configure -sh /usr/lib/opkg/info//knot-resolver.postinst configure
-sleep 2 root@turris:~# pstree -a $(pgrep pkgupdate) pkgupdate -e TRACE -sh /usr/lib/opkg/info//firewall.postinst configure
-sh /usr/lib/opkg/info//firewall.postinst configure -sh /etc/rc.common /etc/init.d/firewall reload
-fw3 reload |-(sh) |-(sh) |-(sh) -sh -c config() { echo “You cannot use UCI in firewall includes!” >&2; exit 1; }; . /usr/share/firewall/turris
root@turris:~# pstree -a $(pgrep pkgupdate)
pkgupdate -e TRACE
-sh /usr/lib/opkg/info//firewall.postinst configure -sh /usr/lib/opkg/info//firewall.postinst configure
-sh /etc/rc.common /etc/init.d/firewall reload -fw3 reload
|-(sh)
|-(sh)
|-(sh)
-sh -c config() { echo "You cannot use UCI in firewall includes!" >&2; exit 1; }; . /etc/firewall.d/with_reload/firewall.include.sh -sh /etc/firewall.d/with_reload//99-ucollect-fake.fw
root@turris:~# pstree -a $(pgrep pkgupdate)
pkgupdate -e TRACE
-sh /usr/lib/opkg/info//firewall.postinst configure -sh /etc/rc.common /etc/init.d/firewall restart
-fw3 restart |-(sh) |-(sh) |-(sh) -sh -c config() { echo “You cannot use UCI in firewall includes!” >&2; exit 1; }; . /usr/share/firewall/turris
root@turris:~# pstree -a $(pgrep pkgupdate)
pkgupdate -e TRACE

8

If I run /usr/lib/opkg/info//firewall.postinst myself, then it completes execution successfully

9

It seems that it hangs on our firewall. I expect that you have our data collection enabled, is that right?

Could you please check if there is following file? /tmp/turris-firewall-rules-apply.lock and what is its content? It should contain valid PID, if process with that PID is not running then you can remove that lock and try again. Possibly could you reboot router and check if that file is created once again?

10

Yes, data collection is enabled.
There is no /tmp/turris-firewall-rules-apply.lock file.
It’s not created after reboot.

I’m also getting daily e-mails like this:
During the previous day, following downtime of your router “” was recorded:
Firewall: 24 hours
uCollect: 0 hours

11

That is weird. Only other operation it might be stuck on in /usr/share/firewall/turris is possibly firewall it self. It is possible that for some reason it hangs. Is it possible that you are connected in some way that causes your connection to disconnect when firewall is reloaded but that probably won’t let you see stuck updater. Only think I can imagine now to try is to kill postinst it self. It seems that your router is some weird state where it is unable to just reconfigure firewall. Try killing postinst and otherwise I would suggest you to do factory reset and try again (maybe medkit to new version).