No module named nanodb

AI & Data Science AI Foundation Models and Endpoints
1

Hello

I followed the link above as it is.
However, after entering the container, I entered the command below and the phrase ‘/usr/local/bin/python3: No module named nanodb’ appeared. Can’t I run the nanodb tutorial?

jetson-containers run $(autotag nanodb)
python3 -m nanodb
–path /data/nanodb/coco/2017
–server --port=7860

2 Likes
2

Did you solve it ?

3

I didn’t solve it. I’m sorry I couldn’t help you

4

I used IMAGE ID instead of $(autotag nanodb)

jetson-containers run 8118ef4e5cab

You can get the IMAGE ID via running sudo docker image ls

I use dustynv/nanodb:r36.2.0 image btw.

You can find it here GitHub

5

Thank you for your help. I’ll do it if I have time.:)

6

I also get the same error message when trying to start the Gradio server:
/usr/local/bin/python3: No module named nanodb

Due to this install.sh script failing:
git clone GitHub - dusty-nv/jetson-containers: Machine Learning Containers for NVIDIA Jetson and JetPack-L4T
bash jetson-containers/install.sh
with this error message:
ubprocess.CalledProcessError: Command ‘sudo DOCKER_BUILDKIT=0 docker build --network=host --tag nanodb:r36.4.2-python --file /home/ken/jetson-containers/packages/build/python/Dockerfile --build-arg BASE_IMAGE=nanodb:r36.4.2-cudnn_9.4 --build-arg PYTHON_VERSION_ARG=“3.10” /home/ken/jetson-containers/packages/build/python 2>&1 | tee /home/ken/jetson-containers/logs/20250108_082057/build/nanodb_r36.4.2-python.txt; exit ${PIPESTATUS[0]}’ returned non-zero exit status 127.
nanodb_r36.4.2-python.txt (7.8 KB)

‘sudo docker image ls’ shows an incomplete installation:

REPOSITORY       TAG                       IMAGE ID       CREATED         SIZE
<none>           <none>                    fb4900030dde   16 hours ago    6.91GB
nanodb           r36.4.2-cudnn_9.4         4d73a710a23c   16 hours ago    6.91GB
nanodb           r36.4.2-cuda_12.6         57f6b38b7dd0   16 hours ago    5.91GB
nanodb           r36.4.2-pip_cache_cu126   efca951b50f6   16 hours ago    723MB
nanodb           r36.4.2-build-essential   be8f81cd8a0f   16 hours ago    723MB
ubuntu           22.04                     981912c48e9a   3 months ago    69.2MB
dustynv/nanodb   r36.2.0                   8118ef4e5cab   10 months ago   16GB
7

Hi All,

It seems like the best way to get help and a fix for this is by raising an issue on GitHub - dusty-nv/jetson-containers: Machine Learning Containers for NVIDIA Jetson and JetPack-L4T. The team there are really responsive. Hope this helps.
Thanks!

8

Hi @kenluebbert, apologies everyone for not seeing this thread earlier - the latest container image for this is here: dustynv/nanodb:r36.4.0

9

When using the r36.4.0 container pulled from:
https://hub.docker.com/r/dustynv/nanodb/tags

  1. There is an issue with the r36.4.0 indexing process where the validation step returns a warning for each image being validated:
22:15:22 | WARNING | incorrect or duplicate index [9999]  indexes=[-1 -1 -1 -1 -1 -1 -1 -1]  distances=[-3.4028235e+38 -3.4028235e+38 -3.4028235e+38 -3.4028235e+38
 -3.4028235e+38 -3.4028235e+38 -3.4028235e+38 -3.4028235e+38]

Search queries using this index return an incorrect list of images all with similarity values of 0.0237

  1. using the r36.2.0 container also pulled from:
    https://hub.docker.com/r/dustynv/nanodb/tags
    results an indexing process that runs 4x faster (than r36.4.0) and generates an index that is validated with few warnings or errors. The index query results are correct.

similar to my comparison of r36.4.2 to r36.2.0 indexing at the tail end of:

10

Yes, the tests were identical, and run on the same jetson orin nano.

I decided to test again from the beginning by flashing with sdkmanager, and then building r36.4.0 (instead of pulling the container from the hub) and got the same results.

1 Like
11

Hi were you able to solve it for 36.4.0? I am running dustynv/nanodb:r36.4.0 and I am getting the same error. search queries return incorrect result.

result
result772×778 97.2 KB

result_img
result_img684×569 82.1 KB

12

My test of r36.4.0 continues to return an invalid index and runs 4x slower than r36.2.0 (which returns a valid index).

1 Like
13

I noticed this too, Have you tried using the ViT-L/14@336 in the 36.4.0 ?

15

I would recommend pulling r36.2.0 container from:
https://hub.docker.com/r/dustynv/nanodb/tags

and lookup the (image id of nanodb) using:
sudo docker image ls

and then run the image for r36.2.0 using
jetson-containers run (image id of nanodb)

These steps will allow you to test nanodb functionality without waiting for the issues with r36.4.0 to be resolved.

1 Like
16

running [dustynv/nanodb:r36.2.0] in r36.4.0 sometimes gives Segmentation fault (core dumped), other times it works… uses 100% of cpu resources (check jtop).
Also sometimes I am unable to download ‘ViT-L/14@336px’ model. I get checksum error after download.
Most likely is because the L4T version mismatch.

17

please refer to Nanodb r36.4.0 Search queries return an incorrect list of images