Nix installation problems: sqlite3_error_offset

The problem

I’m providing some software via a nix flake. This requires users to install nix.

A couple of users tried it on a machine running Ubuntu 22.04. I was not present to see this, but the user reports that the nix (multi-user) installer completed without issuing any warnings or errors. Thereafter, any attempt to use any nix command gave the error:

nix: symbol lookup error: /nix/store/....... undefined symbol: sqlite3_error_offset

At this stage, IIUC, they installed sqlite via apt-get. Nix complained about the version being too old. So they installed a more recent version, by hand, into /usr/local/bin (or some such) and pointed LD_LIBRARY_PATH at it.

Problems continued.

Thereafter, I watched a complete removal of nix, following these instructions. The multi-user Nix installer ran without any complaint.

Thereafter nix profile install or nix shell appear to work without any problem, but trying to run just about anything installed with either of these, crashes, although in slightly different ways:

  • runs successfully

    • hello
  • segfault

    • direnv
    • cachix
  • /nix/store/ir0j7zqlw9dc49grmwplppc7gh0s40yf-bash-5.2-p15/bin/bash: /usr/lib/x86_64-linux-gnu/ version `GLIBC_2.36' not found (required by /nix/store/ir0j7zqlw9dc49grmwplppc7gh0s40yf-bash-5.2-p15/bin/bash)
    • cowsay


  • Does the nix installer really rely on the target system having a pre-installed and specific version of sqlite3?

  • Why on earth does /nix/store/.../bin/bash appear to be looking for an out-of-store libc?

  • What can be done to get these users out of this hole?


I have a few more details about what was done before I stared observing directly:

  • install nix (using the line from the readme)
  • nix complains about sqlite
  • we try an older version of nix
  • the installer fails without saying anything meaninful
  • install sqlite
  • reinstall nix
  • nix complains about permissions
  • sudo chown -R $USER /nix
  • seems to work

… thereafter, I observed a complete removal of nix, including /nix so the chown ... /nix should be irrelevant to the latest observations.

1 Like

Some more observations:

We have now tried this

  • On a different machine (also running Ubuntu 22.04, but where nobody has ever tried to install Nix before)
  • Using the Determinate Nix Installer

The installer claims to have installed Nix successfully, but running

nix --help

once again gives

undefimed symbol: sqlite3_error_offset

running it through strace gives a bit more information

symbol lookup error: /nix/store/3wqasl97rjiza3vd7fxjnvli2w9l30mk-nix-2.17.0/lib/ undefined symbol: sqlite3_error_offset

At this stage I’m starting to suspect an error in the installer or in Nix itself, but then I’d expect the internet to be replete with complaints about it, and I don’t find very much beyond

The latter

  • Reports the same problem, also on Ubuntu 22.04. (But I struggle to see how this could depend on a specific host OS version.)
  • Suggests (thanks @abathur) that going back to nix-2.12.0 avoids the problem. (But this was reported when Nix 2.13.0 was “very recent” (6 months ago) and we are now on 2.17, so it seems unlikely that this problem would have gone unfixed for so many versions.)

Anyway, we’ll try this when the user is available again.

Given that the Determinate Nix Installer provides a simple command to revert everything it did, I would prefer to continue using it, rather than the official installer. But there doesn’t seem to be a way to tell it to use an older version of Nix, other than downgrading DNI itself.

1 Like

Tried the official nix installer for 2.12, like this

sh <(curl -L
) --daemon 

and now nix --help gives this error.

nix: error while loading shared libraries: __vdso_gettimeofday: invalid mode for dlopen(): Invalid argument 

None of this is helping me convince users that Nix is a good tool for helping them avoid installation troubles :frowning:

1 Like

Additional dot-connecting:

I’m not as versed in troubleshooting Linux install problems, so I wasn’t really sure why the reddit user was seeing the issue.

In retrospect, I think I was ~tricked by the fact that the code using this symbol was very new, but that detail was probably a red herring. The symbol error is probably an issue with the runtime environment causing Nix to run against the system’s sqlite instead of the one the installer adds as part of the store bootstrap:

$ curl -L -o tmp.tar.xz
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 21.1M  100 21.1M    0     0  2342k      0  0:00:09  0:00:09 --:--:-- 2531k

$ mkdir flarf

$ tar -xJf tmp.tar.xz -C flarf

$ find flarf -name "*sqlite*"

This misconfiguration could (as well as adding /usr/local/bin to LD_LIBRARY_PATH) probably cause it to pick up other incorrect library versions. Setting aside any change you might have made to try and fix the sqlite error, were LD_LIBRARY_PATH or LD_PRELOAD already set (probably via a shell init file, assuming you’ve rebooted or started a new shell during this testing)?

1 Like


These users’ .bashrcs were polluting the environment with all sorts of toxic waste. Remove all this hazmat, and Nix starts working properly.

Clearly, I was being naive about the extent to which Nix can be immune to this.

There remains one problem that I’m still aware of: as much as I dislike using nix profile install, it does seem to be the most expedient way of giving these users a sensible version of direnv. Unfortunately, this doesn’t work, complaining that /nix/var/nix/profiles/per-user/<user> does not exist.

I suspect that this is the consequence of the repeated attempts to install and uninstall Nix, which messed up something along the way?

How can this be fixed?

But perhaps this should be asked in a separate topic.

1 Like

A static build of Nix is probably a little more ~durable against this sort of chaos, though I don’t think there’s an official one.

Was your last install with detsys? I recall this coming up. Does the discussion in After removing 0.8.0 and installing 0.9.0, many `nix profile` commands fail · Issue #477 · DeterminateSystems/nix-installer · GitHub lead to a solution?

1 Like

It was.

I am not in a position to check at the moment. But, AFAICT without access to the machine, it does look promising.

1 Like

Confirmed: Removing the user’s .nix-profile seems to have solved the problem.

1 Like