How to fix: vorta doesn't open after upgrade; either silently fails or error about peewee.py, uncaught exception, database disk image is malformed

[CouldBeThis]

Description

Looks like Vorta was upgraded this weekend from the AUR: vorta 0.8.12-3 -> 0.9.1-1 according to my record. After this, Vorta does not open but just throws an error.

Am pretty sure this is duplicate of #1851, #1364 and others. Am mainly posting to share clear instructions about how to solve to assist other users. Was confusing to piece it together from various issues.

How I fixed this

Hopefully someone who understands more of what is going on can verify if this is good general advice.

It never hurts to make a copy of everything first in case you need to walk back.

1. Use task manager to make sure Vorta is not running at all
2. Go to your user's vorta configuration directory. According to the Vorta FAQ,
   • flatpak installations use the directory ~/.var/app/com.borgbase.Vorta/data/Vorta/
   • pip installations use ~/.local/share/Vorta (as does my distro, manjaro)
   • Mac OS location? unknown to me.
3. Trash the file settings.db
4. There is also file named something like settings_v20_2024-01-13-195827.db (it is a backup of the local config database). Rename it to settings.db.
5. Open Vorta

Result: Now I can start Vorta with no loss of settings. Working as previously. :) Did not have to reconfigure everything as was suggested in some of the threads.

Reproduction

• I tried to reproduce the issue.
• I was able to reproduce the issue.

OS

manjaro linux 66.10-1 + xfce 4.18

Version of Vorta

Vorta 0.9.1 (aur/vorta 0.9.1-2)

What did you install Vorta with?

Other

Version of Borg

Borg 1.2.7 (extra/borg 1.2.7-1)

Logs

- root - CRITICAL - Uncaught exception, file a report at https://github.com/borgbase/vorta/issues/new/choose
Traceback (most recent call last):
  File "/usr/lib/python3.11/site-packages/peewee.py", line 3251, in execute_sql
    cursor.execute(sql, params or ())
sqlite3.DatabaseError: database disk image is malformed

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/bin/vorta", line 8, in <module>
    sys.exit(main())
             ^^^^^^
  File "/usr/lib/python3.11/site-packages/vorta/__main__.py", line 81, in main
    init_db(sqlite_db)
  File "/usr/lib/python3.11/site-packages/vorta/store/connection.py", line 82, in init_db
    ).execute()
      ^^^^^^^^^
  File "/usr/lib/python3.11/site-packages/peewee.py", line 1971, in inner
    return method(self, database, *args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/site-packages/peewee.py", line 2042, in execute
    return self._execute(database)
           ^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/site-packages/peewee.py", line 2560, in _execute
    cursor = database.execute(self)
             ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/site-packages/peewee.py", line 3259, in execute
    return self.execute_sql(sql, params)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/site-packages/peewee.py", line 3249, in execute_sql
    with __exception_wrapper__:
  File "/usr/lib/python3.11/site-packages/peewee.py", line 3019, in __exit__
    reraise(new_type, new_type(exc_value, *exc_args), traceback)
  File "/usr/lib/python3.11/site-packages/peewee.py", line 192, in reraise
    raise value.with_traceback(tb)
  File "/usr/lib/python3.11/site-packages/peewee.py", line 3251, in execute_sql
    cursor.execute(sql, params or ())
peewee.DatabaseError: database disk image is malformed

[m3nu]

This error doesn't look normal:

peewee.DatabaseError: database disk image is malformed

[CheariX]

I'm experiencing the same error.

Details:

 sqlite3 ~/.var/app/com.borgbase.Vorta/data/Vorta/settings.db "PRAGMA integrity_check;"
*** in database main ***
Tree 25 page 4 cell 2: Rowid 147 out of order
row 1 missing from index archivemodel_repo_id
row 2 missing from index archivemodel_repo_id
row 3 missing from index archivemodel_repo_id
row 4 missing from index archivemodel_repo_id
row 5 missing from index archivemodel_repo_id
row 6 missing from index archivemodel_repo_id
row 7 missing from index archivemodel_repo_id
row 8 missing from index archivemodel_repo_id
row 9 missing from index archivemodel_repo_id
row 10 missing from index archivemodel_repo_id
row 11 missing from index archivemodel_repo_id
row 12 missing from index archivemodel_repo_id
row 13 missing from index archivemodel_repo_id
row 14 missing from index archivemodel_repo_id
row 15 missing from index archivemodel_repo_id
row 16 missing from index archivemodel_repo_id
row 17 missing from index archivemodel_repo_id
row 18 missing from index archivemodel_repo_id
row 19 missing from index archivemodel_repo_id
row 20 missing from index archivemodel_repo_id
row 21 missing from index archivemodel_repo_id
row 22 missing from index archivemodel_repo_id
row 23 missing from index archivemodel_repo_id
row 24 missing from index archivemodel_repo_id
row 25 missing from index archivemodel_repo_id
row 26 missing from index archivemodel_repo_id
row 27 missing from index archivemodel_repo_id
row 28 missing from index archivemodel_repo_id
row 29 missing from index archivemodel_repo_id
row 30 missing from index archivemodel_repo_id
row 31 missing from index archivemodel_repo_id
wrong # of entries in index archivemodel_repo_id
NULL value in repomodel.name
row 1 missing from index repomodel_url
NULL value in repomodel.name
row 2 missing from index repomodel_url
wrong # of entries in index repomodel_url

I could fix it by copying the backup:

cp settings_v20_2024-01-12-134523.db settings.db

[CouldBeThis]

@m3nu well idk what any of it means tbh. agree it isn't normal because vorta doesn't start in the circumstance. but it's fixed! I checked the log and it all looks fine since i restored backup as described.

@CheariX the output is totally different though? not that i can make much meaning out of it.

copying your command on the old db file:

sqlite3 ~/.local/share/Vorta/settings.db-original "PRAGMA integrity_check;"
Error: stepping, database disk image is malformed (11)

and again on the current, functional file:

sqlite3 ~/.local/share/Vorta/settings.db "PRAGMA integrity_check;"       

ok

now that I think about backing up my backup utility... [Edit: removed to discussions due to being a ponderous digression from topic #1897]

[HcgRandon]

Chiming in to say I also experienced this as well! Let me know if I can share anything to help track down the issue

[m3nu]

A new feature that takes a DB backup before upgrades was merged recently. That's all I can think of. I never saw any damaged SQLite file personally in any app.

[m3nu]

This is the PR in question. I just copies the file, but won't touch the original. Not sure this is to blame. #1848

[real-yfprojects]

This is the PR in question. I just copies the file, but won't touch the original. Not sure this is to blame. #1848

Reading OP it seems more like that this PR actually allowed for an easy recovery after corrupting th db.

Since the backup of database (schema) version 20 works. One of the following migrations might have caused the problem:

vorta/src/vorta/store/migrations.py

Lines 231 to 251 in d8cce25

	if current_schema.version < 21:
	_apply_schema_update(
	current_schema,
	21,
	migrator.add_column(
	ArchiveModel._meta.table_name,
	'trigger',
	pw.CharField(null=True),
	),
	)
	if current_schema.version < 22:
	_apply_schema_update(
	current_schema,
	22,
	migrator.add_column(
	RepoModel._meta.table_name,
	'name',
	pw.CharField(default=''),
	),
	)

However after restoring the backup the migrations should be run again and obviously the issue didn't persist. This is a mystery I don't have an explanation for.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[github-actions]

This issue was closed because it has been stalled for 7 days with no activity.