Command-not-found PureOS 9 librem13

Did a clean install of PureOS9 on librem 13
(had been on Mint for a good while and all worked well).

Hoping I could use xfce4 after install fully done and working
(gnome makes me…crazy).

Did the update after install too.

Now any reference to a command that is not known
gets an error
davea@q4:~$ xxx
Could not find the database of available applications, run update-command-not-found as root to fix this
Sorry, command-not-found has crashed! Please file a bug report at:
Please include the following information with the report:

command-not-found version: 0.3
Python version: 3.7.3 final 0
Distributor ID: PureOS
Description: PureOS
Release: 9.0
Codename: amber
Exception information:

local variable ‘cnf’ referenced before assignment
Traceback (most recent call last):
File “/usr/share/command-not-found/CommandNotFound/”, line 23, in crash_guard
File “/usr/lib/command-not-found”, line 93, in main
if not cnf.advise(args[0], options.ignore_installed) and not options.no_failure_msg:
UnboundLocalError: local variable ‘cnf’ referenced before assignment

this error is a debian bug, and the relevant database
is not on my install at all!
None of the tricks from other non-pureOS have helped.
I guess I’ll reinstall fresh. Maybe I did something?

Any ideas?

I just “sudo apt remove command-not-found” for my pureos installs since I don’t need it anyway

1 Like

It’s a bug in the command-not-found package, supposed to be fixed in command-not-found version 20.10.1-1:

PureOS 10 (byzantium) has the fixed version, so if you upgrade to byzantium that might help. See

Otherwise, you could simply remove the command-not-found package as @lo0 says, things should work fine without it.

1 Like

Thanks for the suggestions.

First install even ‘sudo apt remove’
refused to work after a while, complaining of
a lock something held.

After reinstall, for some reason, things went better
and removing command-not-found was easy.
I also installed xfce4 and now I’m a happy camper.
with that desktop.

I will check sources.list and add the amber lines
if they are not already present.

Thanks again for the assistance.

That I think is nothing to worry about, all you need to do is wait a few minutes to let the other process, the one holding the lock, finish what it is doing.

Most likely, it started a process checking for updates in the background, that could take a minute or two and it holds that lock while it is running. So if you open a terminal and try “apt update” or “apt install” or “apt remove” or similar there while the background process is running, it will complain about the lock. It does not necessarily mean anything is wrong, you just need to wait to let the other process finish.

To be sure it never happens you would need to turn off the automatic checking for updates, I think.