On Sat, 7 Oct 2023 22:14:03 +0000 (4 days, 8 hours, 32 minutes ago) Kejvan Redjamand kejvan@chalmers.se wrote:
Hi,
I have had problems installing nav 57.1-2 on a Debian 11 from NAV repository with 'apt install nav'.
Hi there,
I suppose you mean 5.7.1-2bullseye.
I found that the symlinks are setup somehow wrong for nav binaries installed. I'm not a good python programmer but probably the virtual env is not setup or configured as it should.
/opt/venvs/nav/bin# ls -l python* lrwxrwxrwx 1 root root 16 Sep 18 14:09 python -> /usr/bin/python3 lrwxrwxrwx 1 root root 6 Sep 18 14:09 python3 -> python lrwxrwxrwx 1 root root 6 Sep 18 14:09 python3.9 -> python
This is perfectly normal for a virtualenv built on a standard Debian Bullseye distribution, which comes with Python 3.9.
because in my case: /usr/bin/python3 -> python3.11
Now that's a pickle. Debian 11 doesn't provide Python 3.11. Did you install Python 3.11 from some backports repository?
I have tried to drop the database, creating new database, changing the password, set the password other ways, uninstall nav and reinstall but without any results.
I am out of ideas and any help is appreciated.
The Debian package will generate a random database password and modify /etc/nav/db.conf at installation time. If re-running the package config at a later date, it will assume the database has already been initialized if the password is already there in db.conf. In your case, that is probably not true, since the database scripts crashed, so now the package init is likely trying to access a non-existant database.
I would verify that there is a password set in the `userpw_nav` option of /etc/nav/db.conf (if set, just leave it. If not, make up your own), and then just attempt to reset the whole database from scratch using navsyncdb as the postgres user, thus:
sudo -u postgres navsyncdb --drop-database -c