Struggling to install huggingface_hub

Dyno108 · November 24, 2025, 10:34pm

very beginner, following many online tutorials and have been able to overcome my problems until this one. im dont understand the problem so not sure what info to give as a starting point

John6666 · November 25, 2025, 6:40am

Python 3.8 might no longer be supported.

You are running into a dependency problem, not a “you did something wrong” problem.

From the screenshot, the important part is:

Collecting hf-xet...
Installing backend dependencies ... error
pip install ... -- puccinalin
ERROR: Could not find a version that satisfies the requirement puccinalin (from versions: none)

So:

huggingface_hub → depends on hf-xet (PyPI)
hf-xet → needs another tool called puccinialin to build its Rust code (PyPI)
puccinialin is only built for Python ≥ 3.9 (PyPI)
Your virtual environment is Python 3.8 (/home/rui/.venv/lib/python3.8/... in the error), so pip can’t find any compatible puccinialin, and the whole install fails.

On top of that, current huggingface_hub itself also officially requires Python ≥ 3.9. (PyPI)

So the core issue is: your Python version (3.8) is too old for the version of huggingface_hub you’re trying to install and its new Rust-based dependency chain (hf-xet → puccinialin).

Fix 1 (recommended): use Python ≥ 3.9 in a fresh environment

If you can install a newer Python (3.10 or 3.11 is ideal), this is the cleanest fix.

A. Create a new virtual environment with the newer Python

Example for Linux once you have python3.10 installed:

# check what version you have
python3.10 --version

# create a new env (choose any folder you like)
python3.10 -m venv ~/hf-env

# activate it
source ~/hf-env/bin/activate

# upgrade pip (always a good idea)
pip install --upgrade pip

If python3.10 doesn’t exist yet, your options are:

Install a newer Python via your OS packages (e.g. on Ubuntu using a PPA such as “deadsnakes”), or
Install Miniconda/Anaconda and create a conda env:

# after installing miniconda
conda create -n hf python=3.10
conda activate hf
pip install --upgrade pip

B. Install `huggingface_hub` inside that new env

pip install "huggingface_hub"

This should now work, because:

huggingface_hub is happy (Python ≥ 3.9). (PyPI)
hf-xet can install its Rust helper puccinialin, which also needs Python ≥ 3.9. (PyPI)

C. Test that it actually imported

Once the install succeeds, test like this:

python -c "from huggingface_hub import hf_hub_download; print('import OK')"

If you see import OK, the library is installed and usable.

Fix 2 (workaround): stay on Python 3.8 but use an older `huggingface_hub`

Only do this if you absolutely cannot upgrade Python.

Older versions of huggingface_hub (≤ 0.30.2) did not depend on hf-xet yet, so they avoid the Rust + puccinialin chain. (GitHub)

Inside your existing 3.8 virtualenv:

# make sure old broken attempt is cleared
pip uninstall -y huggingface_hub hf-xet

# install a version before the hf-xet dependency
pip install "huggingface_hub<0.31"

Then test:

python -c "from huggingface_hub import hf_hub_download; print('import OK')"

Important limitations of this workaround:

You won’t get newer features that expect recent huggingface_hub versions.
Some tutorials written against very new versions might not match exactly.

But for basic things like hf_hub_download, an older 0.2x/0.3x version is usually fine.

One more thing: that `from: can't read /var/mail/huggingface_hub` line

At the very top of your screenshot there is:

from huggingface_hub import hf_hub_download
from: can't read /var/mail/huggingface_hub

That error is unrelated to the installation itself. It means:

You typed from huggingface_hub import hf_hub_download directly in the shell.
The shell (bash) doesn’t understand Python syntax, so it thinks from is a command.

To run Python code you must either:

Start a Python prompt:

python

Then inside the Python prompt:

from huggingface_hub import hf_hub_download

Or put Python code in a .py file and run python your_script.py.

Suggested next steps for you

In a new terminal, check Python:
```
python3 --version
```
If it’s 3.8: choose either
- upgrade path (Fix 1, new env with Python 3.10+), or
- workaround (Fix 2, pip install "huggingface_hub<0.31").

After installation, verify with:

python -c "from huggingface_hub import hf_hub_download; print('OK')"

Useful references

Official huggingface_hub installation docs (lists requirements & extras). (Hugging Face)
huggingface_hub on PyPI (shows that it requires Python ≥ 3.9 and depends on hf-xet). (PyPI)
hf-xet package on PyPI (Hugging Face’s Rust-based storage helper). (PyPI)
puccinialin package on PyPI (Rust bootstrap helper, requires Python ≥ 3.9). (PyPI)
GitHub issue showing when hf-xet became a dependency, explaining why older huggingface_hub versions avoid it. (GitHub)

Short summary

The red error text is not “Hugging Face is broken”; it’s pip failing to install puccinialin, a Rust helper that hf-xet needs.
puccinialin and recent huggingface_hub both require Python ≥ 3.9, but your env is Python 3.8, so pip finds no compatible version.
Best fix: create a new env with Python 3.10+ and reinstall huggingface_hub there.
If you cannot upgrade Python, install an older huggingface_hub version (<0.31) that doesn’t depend on hf-xet / puccinialin.
Remember to run Python code (like from huggingface_hub import hf_hub_download) inside Python, not directly in the shell.

Dyno108 · November 26, 2025, 1:25pm

Thanks so much for your very detailed response, I had little faith my problem would be even worth a response.

However I have run into an issue when updating my version of python, where dpkg returned an error:

Screenshot by Lightshot (not allowed to upload more than 1 piece of embedded media as a new user)

Assuming dpkg was broken, i tried to fix it only for it to return the same error code:

bash dump below

rui@Rui-AI-Desktop:~$ python3 -V
Python 3.8.10
rui@Rui-AI-Desktop:~$ sudo add-apt-repository ppa:deadsnakes/ppa
 This PPA contains more recent Python versions packaged for Ubuntu.

Disclaimer: there's no guarantee of timely updates in case of security problems or other issues. If you want to use them in a security-or-otherwise-critical environment (say, on a production server), you do so at your own risk.

Update Note
===========
Please use this repository instead of ppa:fkrull/deadsnakes.

Reporting Issues
================

Issues can be reported in the master issue tracker at:
https://github.com/deadsnakes/issues/issues

Supported Ubuntu and Python Versions
====================================

- Ubuntu 22.04 (jammy) Python3.7 - Python3.9, Python3.11 - Python3.13
- Ubuntu 24.04 (noble) Python3.7 - Python3.11, Python3.13
- Note: Python 3.10 (jammy), Python3.12 (noble) are not provided by deadsnakes as upstream ubuntu provides those packages.

Why some packages aren't built:
- Note: for jammy and noble, older python versions requre libssl<3 so they are not currently built
- If you need these, reach out to asottile to set up a private ppa

The packages may also work on other versions of Ubuntu or Debian, but that is not tested or supported.

Packages
========

The packages provided here are loosely based on the debian upstream packages with some modifications to make them more usable as non-default pythons and on ubuntu.  As such, the packages follow debian's patterns and often do not include a full python distribution with just `apt install python#.#`.  Here is a list of packages that may be useful along with the default install:

- `python#.#-dev`: includes development headers for building C extensions
- `python#.#-venv`: provides the standard library `venv` module
- `python#.#-distutils`: provides the standard library `distutils` module
- `python#.#-lib2to3`: provides the `2to3-#.#` utility as well as the standard library `lib2to3` module
- `python#.#-gdbm`: provides the standard library `dbm.gnu` module
- `python#.#-tk`: provides the standard library `tkinter` module

Third-Party Python Modules
==========================

Python modules in the official Ubuntu repositories are packaged to work with the Python interpreters from the official repositories. Accordingly, they generally won't work with the Python interpreters from this PPA. As an exception, pure-Python modules for Python 3 will work, but any compiled extension modules won't.

To install 3rd-party Python modules, you should use the common Python packaging tools.  For an introduction into the Python packaging ecosystem and its tools, refer to the Python Packaging User Guide:
https://packaging.python.org/installing/

Sources
=======
The package sources are available at:
https://github.com/deadsnakes/

Nightly Builds
==============

For nightly builds, see ppa:deadsnakes/nightly https://launchpad.net/~deadsnakes/+archive/ubuntu/nightly
 More info: https://launchpad.net/~deadsnakes/+archive/ubuntu/ppa
Press [ENTER] to continue or Ctrl-c to cancel adding it.

Get:1 file:/var/cudnn-local-tegra-repo-ubuntu2004-8.6.0.166  InRelease [1,575 B]
Get:1 file:/var/cudnn-local-tegra-repo-ubuntu2004-8.6.0.166  InRelease [1,575 B]
Hit:2 http://ppa.launchpad.net/deadsnakes/ppa/ubuntu focal InRelease                                                                 
Hit:3 https://repo.download.nvidia.com/jetson/common r35.5 InRelease                                                                 
Hit:4 https://repo.download.nvidia.com/jetson/t234 r35.5 InRelease                                          
Get:5 https://pkgs.tailscale.com/stable/ubuntu focal InRelease                 
Hit:6 https://repo.download.nvidia.com/jetson/ffmpeg r35.5 InRelease                                            
Hit:7 http://ports.ubuntu.com/ubuntu-ports focal InRelease                                
Hit:8 http://ports.ubuntu.com/ubuntu-ports focal-updates InRelease
Hit:9 http://ports.ubuntu.com/ubuntu-ports focal-backports InRelease
Hit:10 http://ports.ubuntu.com/ubuntu-ports focal-security InRelease
Fetched 6,581 B in 2s (3,495 B/s)
Reading package lists... Done
rui@Rui-AI-Desktop:~$ sudo apt-get update
Get:1 file:/var/cudnn-local-tegra-repo-ubuntu2004-8.6.0.166  InRelease [1,575 B]
Get:1 file:/var/cudnn-local-tegra-repo-ubuntu2004-8.6.0.166  InRelease [1,575 B]
Hit:2 http://ppa.launchpad.net/deadsnakes/ppa/ubuntu focal InRelease                                                                 
Hit:3 http://ports.ubuntu.com/ubuntu-ports focal InRelease                                                                           
Hit:4 http://ports.ubuntu.com/ubuntu-ports focal-updates InRelease                                                                 
Hit:5 https://repo.download.nvidia.com/jetson/common r35.5 InRelease                             
Hit:6 http://ports.ubuntu.com/ubuntu-ports focal-backports InRelease                             
Hit:7 http://ports.ubuntu.com/ubuntu-ports focal-security InRelease            
Hit:8 https://repo.download.nvidia.com/jetson/t234 r35.5 InRelease             
Get:9 https://pkgs.tailscale.com/stable/ubuntu focal InRelease
Hit:10 https://repo.download.nvidia.com/jetson/ffmpeg r35.5 InRelease          
Fetched 6,581 B in 1s (4,705 B/s)
Reading package lists... Done
rui@Rui-AI-Desktop:~$ apt list | grep python3.10

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

libqgispython3.10.4/focal,now 3.10.4+dfsg-1ubuntu2 arm64 [installed]
rui@Rui-AI-Desktop:~$ sudo apt-get install python3.10 
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Note: selecting 'libqgispython3.10.4' for regex 'python3.10'
Note: selecting 'libpython3.10-stdlib' for regex 'python3.10'
libqgispython3.10.4 is already the newest version (3.10.4+dfsg-1ubuntu2).
The following packages were automatically installed and are no longer required:
  apt-clone archdetect-deb bogl-bterm busybox-static cryptsetup-bin dpkg-repack gir1.2-timezonemap-1.0 gir1.2-xkl-1.0 grub-common
  libdebian-installer4 libpaps0 libtimezonemap-data libtimezonemap1 os-prober paps python3-icu python3-pam rdate tasksel
  tasksel-data
Use 'sudo apt autoremove' to remove them.
0 to upgrade, 0 to newly install, 0 to remove and 4 not to upgrade.
5 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] 
Setting up nvidia-l4t-bootloader (35.5.0-20240613202628) ...
3701--0005--1--jetson-orin-nano-devkit-
Info. Installing mtdblock.
Info. Active boot storage: mmcblk1
Info. Legacy mode: false
TNSPEC 3701-501-0005-G.0-1-0-jetson-orin-nano-devkit-
COMPATIBLE_SPEC 3701--0005--1--jetson-orin-nano-devkit-
TEGRA_LEGACY_UPDATE false
TEGRA_BOOT_STORAGE mmcblk1
TEGRA_EMMC_ONLY false
TEGRA_CHIPID 0x23
TEGRA_OTA_BOOT_DEVICE /dev/mtdblock0
TEGRA_OTA_GPT_DEVICE /dev/mtdblock0
Info: Write TegraPlatformCompatSpec with 3701--0005--1--jetson-orin-nano-devkit-.
INFO. Dump slots info:
Current version: 35.4.1
Capsule update status: 0
Current bootloader slot: A
Active bootloader slot: A
num_slots: 2
slot: 0,             status: normal
slot: 1,             status: normal
INFO. Dump nv_boot_control.conf:
TNSPEC 3701-501-0005-G.0-1-0-jetson-orin-nano-devkit-
COMPATIBLE_SPEC 3701--0005--1--jetson-orin-nano-devkit-
TEGRA_LEGACY_UPDATE false
TEGRA_BOOT_STORAGE mmcblk1
TEGRA_EMMC_ONLY false
TEGRA_CHIPID 0x23
TEGRA_OTA_BOOT_DEVICE /dev/mtdblock0
TEGRA_OTA_GPT_DEVICE /dev/mtdblock0
ERROR. 3701--0005--1--jetson-orin-nano-devkit- does not match any known boards.
dpkg: error processing package nvidia-l4t-bootloader (--configure):
 installed nvidia-l4t-bootloader package post-installation script subprocess returned error exit status 1
Setting up nvidia-l4t-kernel (5.10.192-tegra-35.5.0-20240613202628) ...
Using the existing boot entry 'primary'
3701--0005--1--jetson-orin-nano-devkit-
Info. Installing mtdblock.
Info. Active boot storage: mmcblk1
Info. Legacy mode: false
TNSPEC 3701-501-0005-G.0-1-0-jetson-orin-nano-devkit-
COMPATIBLE_SPEC 3701--0005--1--jetson-orin-nano-devkit-
TEGRA_LEGACY_UPDATE false
TEGRA_BOOT_STORAGE mmcblk1
TEGRA_EMMC_ONLY false
TEGRA_CHIPID 0x23
TEGRA_OTA_BOOT_DEVICE /dev/mtdblock0
TEGRA_OTA_GPT_DEVICE /dev/mtdblock0
Info: Write TegraPlatformCompatSpec with 3701--0005--1--jetson-orin-nano-devkit-.
Starting kernel post-install procedure.
Rootfs AB is not enabled.
ERROR. Procedure for A_kernel update FAILED.
Cannot install package. Exiting...
dpkg: error processing package nvidia-l4t-kernel (--configure):
 installed nvidia-l4t-kernel package post-installation script subprocess returned error exit status 1
dpkg: dependency problems prevent configuration of nvidia-l4t-kernel-headers:
 nvidia-l4t-kernel-headers depends on nvidia-l4t-kernel (= 5.10.192-tegra-35.5.0-20240613202628); however:
  Package nvidia-l4t-kernel is not configured yet.

dpkg: error processing package nvidia-l4t-kernel-headers (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of nvidia-l4t-display-kernel:
 nvidia-l4t-display-kernel depends on nvidia-l4t-kernel (= 5.10.192-tegra-35.5.0-20240613202628); however:
  Package nvidia-l4t-kernel is not configured yet.

dpkg: error processing package nvidia-l4t-display-kernel (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of nvidia-l4t-kernel-dtbs:
 nvidia-l4t-kernel-dtbs depends on nvidia-l4t-kernel (= 5.10.192-tegra-35.5.0-20240613202628); however:
  Package nvidia-l4t-kernel is not configured yet.

dpkg: error processing package nvidia-l4t-kernel-dtbs (--configure):
 No apport report written because the error message indicates it's a follow-up error from a previous failure.
                                                                                                             No apport report written because MaxReports has already been reached
                                           No apport report written because MaxReports has already been reached
                                                                                                               dependency problems - leaving unconfigured
Errors were encountered while processing:
 nvidia-l4t-bootloader
 nvidia-l4t-kernel
 nvidia-l4t-kernel-headers
 nvidia-l4t-display-kernel
 nvidia-l4t-kernel-dtbs
E: Sub-process /usr/bin/dpkg returned an error code (1)
rui@Rui-AI-Desktop:~$ sudo update-alternatives --install /usr/bin/python3 python3 /usr/bin/python3.8 1
rui@Rui-AI-Desktop:~$ sudo update-alternatives --install /usr/bin/python3 python3 /usr/bin/python3.10 2
update-alternatives: error: alternative path /usr/bin/python3.10 doesn't exist
rui@Rui-AI-Desktop:~$ sudo update-alternatives --install /usr/bin/python3 python3 /usr/bin/python3.10 1
update-alternatives: error: alternative path /usr/bin/python3.10 doesn't exist
rui@Rui-AI-Desktop:~$ sudo dpkg --configure -a
Setting up nvidia-l4t-bootloader (35.5.0-20240613202628) ...
3701--0005--1--jetson-orin-nano-devkit-
Info. Installing mtdblock.
Info. Active boot storage: mmcblk1
Info. Legacy mode: false
TNSPEC 3701-501-0005-G.0-1-0-jetson-orin-nano-devkit-
COMPATIBLE_SPEC 3701--0005--1--jetson-orin-nano-devkit-
TEGRA_LEGACY_UPDATE false
TEGRA_BOOT_STORAGE mmcblk1
TEGRA_EMMC_ONLY false
TEGRA_CHIPID 0x23
TEGRA_OTA_BOOT_DEVICE /dev/mtdblock0
TEGRA_OTA_GPT_DEVICE /dev/mtdblock0
Info: Write TegraPlatformCompatSpec with 3701--0005--1--jetson-orin-nano-devkit-.
INFO. Dump slots info:
Current version: 35.4.1
Capsule update status: 0
Current bootloader slot: A
Active bootloader slot: A
num_slots: 2
slot: 0,             status: normal
slot: 1,             status: normal
INFO. Dump nv_boot_control.conf:
TNSPEC 3701-501-0005-G.0-1-0-jetson-orin-nano-devkit-
COMPATIBLE_SPEC 3701--0005--1--jetson-orin-nano-devkit-
TEGRA_LEGACY_UPDATE false
TEGRA_BOOT_STORAGE mmcblk1
TEGRA_EMMC_ONLY false
TEGRA_CHIPID 0x23
TEGRA_OTA_BOOT_DEVICE /dev/mtdblock0
TEGRA_OTA_GPT_DEVICE /dev/mtdblock0
ERROR. 3701--0005--1--jetson-orin-nano-devkit- does not match any known boards.
dpkg: error processing package nvidia-l4t-bootloader (--configure):
 installed nvidia-l4t-bootloader package post-installation script subprocess returned error exit status 1
Setting up nvidia-l4t-kernel (5.10.192-tegra-35.5.0-20240613202628) ...
Using the existing boot entry 'primary'
3701--0005--1--jetson-orin-nano-devkit-
Info. Installing mtdblock.
Info. Active boot storage: mmcblk1
Info. Legacy mode: false
TNSPEC 3701-501-0005-G.0-1-0-jetson-orin-nano-devkit-
COMPATIBLE_SPEC 3701--0005--1--jetson-orin-nano-devkit-
TEGRA_LEGACY_UPDATE false
TEGRA_BOOT_STORAGE mmcblk1
TEGRA_EMMC_ONLY false
TEGRA_CHIPID 0x23
TEGRA_OTA_BOOT_DEVICE /dev/mtdblock0
TEGRA_OTA_GPT_DEVICE /dev/mtdblock0
Info: Write TegraPlatformCompatSpec with 3701--0005--1--jetson-orin-nano-devkit-.
Starting kernel post-install procedure.
Rootfs AB is not enabled.
ERROR. Procedure for A_kernel update FAILED.
Cannot install package. Exiting...
dpkg: error processing package nvidia-l4t-kernel (--configure):
 installed nvidia-l4t-kernel package post-installation script subprocess returned error exit status 1
dpkg: dependency problems prevent configuration of nvidia-l4t-kernel-headers:
 nvidia-l4t-kernel-headers depends on nvidia-l4t-kernel (= 5.10.192-tegra-35.5.0-20240613202628); however:
  Package nvidia-l4t-kernel is not configured yet.

dpkg: error processing package nvidia-l4t-kernel-headers (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of nvidia-l4t-display-kernel:
 nvidia-l4t-display-kernel depends on nvidia-l4t-kernel (= 5.10.192-tegra-35.5.0-20240613202628); however:
  Package nvidia-l4t-kernel is not configured yet.

dpkg: error processing package nvidia-l4t-display-kernel (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of nvidia-l4t-kernel-dtbs:
 nvidia-l4t-kernel-dtbs depends on nvidia-l4t-kernel (= 5.10.192-tegra-35.5.0-20240613202628); however:
  Package nvidia-l4t-kernel is not configured yet.

dpkg: error processing package nvidia-l4t-kernel-dtbs (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 nvidia-l4t-bootloader
 nvidia-l4t-kernel
 nvidia-l4t-kernel-headers
 nvidia-l4t-display-kernel
 nvidia-l4t-kernel-dtbs
rui@Rui-AI-Desktop:~$ sudo apt install -f
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages were automatically installed and are no longer required:
  apt-clone archdetect-deb bogl-bterm busybox-static cryptsetup-bin dpkg-repack gir1.2-timezonemap-1.0 gir1.2-xkl-1.0 grub-common
  libdebian-installer4 libpaps0 libtimezonemap-data libtimezonemap1 os-prober paps python3-icu python3-pam rdate tasksel
  tasksel-data
Use 'sudo apt autoremove' to remove them.
0 to upgrade, 0 to newly install, 0 to remove and 4 not to upgrade.
5 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Setting up nvidia-l4t-bootloader (35.5.0-20240613202628) ...
3701--0005--1--jetson-orin-nano-devkit-
Info. Installing mtdblock.
Info. Active boot storage: mmcblk1
Info. Legacy mode: false
TNSPEC 3701-501-0005-G.0-1-0-jetson-orin-nano-devkit-
COMPATIBLE_SPEC 3701--0005--1--jetson-orin-nano-devkit-
TEGRA_LEGACY_UPDATE false
TEGRA_BOOT_STORAGE mmcblk1
TEGRA_EMMC_ONLY false
TEGRA_CHIPID 0x23
TEGRA_OTA_BOOT_DEVICE /dev/mtdblock0
TEGRA_OTA_GPT_DEVICE /dev/mtdblock0
Info: Write TegraPlatformCompatSpec with 3701--0005--1--jetson-orin-nano-devkit-.
INFO. Dump slots info:
Current version: 35.4.1
Capsule update status: 0
Current bootloader slot: A
Active bootloader slot: A
num_slots: 2
slot: 0,             status: normal
slot: 1,             status: normal
INFO. Dump nv_boot_control.conf:
TNSPEC 3701-501-0005-G.0-1-0-jetson-orin-nano-devkit-
COMPATIBLE_SPEC 3701--0005--1--jetson-orin-nano-devkit-
TEGRA_LEGACY_UPDATE false
TEGRA_BOOT_STORAGE mmcblk1
TEGRA_EMMC_ONLY false
TEGRA_CHIPID 0x23
TEGRA_OTA_BOOT_DEVICE /dev/mtdblock0
TEGRA_OTA_GPT_DEVICE /dev/mtdblock0
ERROR. 3701--0005--1--jetson-orin-nano-devkit- does not match any known boards.
dpkg: error processing package nvidia-l4t-bootloader (--configure):
 installed nvidia-l4t-bootloader package post-installation script subprocess returned error exit status 1
Setting up nvidia-l4t-kernel (5.10.192-tegra-35.5.0-20240613202628) ...
Using the existing boot entry 'primary'
3701--0005--1--jetson-orin-nano-devkit-
Info. Installing mtdblock.
Info. Active boot storage: mmcblk1
Info. Legacy mode: false
TNSPEC 3701-501-0005-G.0-1-0-jetson-orin-nano-devkit-
COMPATIBLE_SPEC 3701--0005--1--jetson-orin-nano-devkit-
TEGRA_LEGACY_UPDATE false
TEGRA_BOOT_STORAGE mmcblk1
TEGRA_EMMC_ONLY false
TEGRA_CHIPID 0x23
TEGRA_OTA_BOOT_DEVICE /dev/mtdblock0
TEGRA_OTA_GPT_DEVICE /dev/mtdblock0
Info: Write TegraPlatformCompatSpec with 3701--0005--1--jetson-orin-nano-devkit-.
Starting kernel post-install procedure.
Rootfs AB is not enabled.
ERROR. Procedure for A_kernel update FAILED.
Cannot install package. Exiting...
dpkg: error processing package nvidia-l4t-kernel (--configure):
 installed nvidia-l4t-kernel package post-installation script subprocess returned error exit status 1
dpkg: dependency problems prevent configuration of nvidia-l4t-kernel-headers:
 nvidia-l4t-kernel-headers depends on nvidia-l4t-kernel (= 5.10.192-tegra-35.5.0-20240613202628); however:
  Package nvidia-l4t-kernel is not configured yet.

dpkg: error processing package nvidia-l4t-kernel-headers (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of nvidia-l4t-display-kernel:
 nvidia-l4t-display-kernel depends on nvidia-l4t-kernel (= 5.10.192-tegra-35.5.0-20240613202628); however:
  Package nvidia-l4t-kernel is not configured yet.

dpkg: error processing package nvidia-l4t-display-kernel (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of nvidia-l4t-kernel-dtbs:
 nvidia-l4t-kernel-dtbs depends on nvidia-l4t-kernel (= 5.10.192-tegra-35.5.0-20240613202628); however:
  Package nvidia-l4t-kernel is not configured yet.

dpkg: error processing package nvidia-l4t-kernel-dtbs (--configure):
 dependency problems - leaving unconfigured
No apport report written because the error message indicates it's a follow-up error from a previous failure.
                                                                                                            No apport report written because MaxReports has already been reached
                                          No apport report written because MaxReports has already been reached
                                                                                                              Errors were encountered while processing:
 nvidia-l4t-bootloader
 nvidia-l4t-kernel
 nvidia-l4t-kernel-headers
 nvidia-l4t-display-kernel
 nvidia-l4t-kernel-dtbs
E: Sub-process /usr/bin/dpkg returned an error code (1)
rui@Rui-AI-Desktop:~$

I figure id rather update python now to prevent future problems rather than downgrade my huggingface_hub install.
Thanks again

Edit: for some reason when tinkering with newer python versions than 3.10 or 3.11, I have managed to update to python 3.9.5 (?) and followed the rest of your instructions successfully, so thank you.
But if you know a good fix and its not too much to ask id still be happy to know how to fix this problem to prevent more in the future.

John6666 · November 26, 2025, 2:13pm

Oh, Jetson environment? Seems like it has some pretty specific conventions?

You’ve already done the important part (getting to Python 3.9.5 and using a venv).
The remaining question is: what’s the “right” way to fix and avoid those scary dpkg / nvidia-l4t-* errors on your Jetson so they don’t keep coming back?

I’ll first recap what’s actually wrong, then give you:

The clean, recommended fix (reflash JetPack / Jetson Linux).
A short-term workaround if you can’t reflash yet.
A few habits to avoid similar problems in the future.

1. What the error really is (and why it’s not your fault)

From your logs:

Setting up nvidia-l4t-bootloader (35.5.0-20240613202628) ...
...
ERROR. 3701--0005--1--jetson-orin-nano-devkit- does not match any known boards.
dpkg: error processing package nvidia-l4t-bootloader (--configure):
  installed nvidia-l4t-bootloader package post-installation script subprocess returned error exit status 1
...
dpkg: error processing package nvidia-l4t-kernel (--configure):
  installed nvidia-l4t-kernel package post-installation script subprocess returned error exit status 1
...
E: Sub-process /usr/bin/dpkg returned an error code (1)

Key points:

These packages come from NVIDIA’s Jetson Linux / L4T stack:
- nvidia-l4t-bootloader
- nvidia-l4t-kernel
- nvidia-l4t-kernel-headers
- nvidia-l4t-display-kernel
- nvidia-l4t-kernel-dtbs
When apt tries to install or upgrade them, their own post-install scripts run.
Those scripts:
- Read the board ID (TNSPEC, COMPATIBLE_SPEC), and
- Decide how to update the bootloader/kernel stored on QSPI / eMMC.
On your board, the script prints:
```
3701--0005--1--jetson-orin-nano-devkit- does not match any known boards.
```
That means “this ID string isn’t in the list of supported boards in this updater”, so the script refuses to continue and exits with status 1.
dpkg is not actually corrupt. It just reports: “the post-install script failed, so I can’t mark these packages as configured”.

This is a known Jetson behavior: NVIDIA explicitly warn that partial upgrades or mismatched Jetson Linux packages can cause firmware/bootloader configuration problems, and that those packages are tightly coupled to the board hardware and JetPack release. (NVIDIA Docs)

So:

The problem is a stuck Jetson firmware/kernel update, not anything you did with Python or pip.

2. “Good” fix: reflash to a clean, matching JetPack

The robust, recommended way to fix this so it doesn’t haunt future apt commands is:

Reflash the Jetson with a JetPack / Jetson Linux image that:
- Matches your board (Jetson Orin Nano devkit) and
- Has a consistent set of nvidia-l4t-* packages that know your board ID. (NVIDIA Docs)

This is exactly what NVIDIA’s SDK Manager (or the official SD-card image) is designed for.

2.1. Why reflashing fixes it

Reflashing:

Writes a new, known-good bootloader + kernel that match the root filesystem.
Installs a fresh set of nvidia-l4t-* packages marked as fully configured.
Resets any half-applied OTA/apt upgrades that confused the updater script.

After a clean flash, sudo apt update && sudo apt upgrade should no longer hit the “does not match any known boards” error, because the firmware updater now recognises the board.

2.2. High-level steps (when you’re ready)

Back up your data
Copy off anything you care about from /home (projects, notebooks, models, etc.).
On a separate Ubuntu x86_64 machine, install NVIDIA SDK Manager. (NVIDIA Docs)
Put the Jetson into recovery mode and connect via USB-C to the host PC (SDK Manager docs show the exact button sequence for Orin Nano).
In SDK Manager:
- Select your Jetson model (Jetson Orin Nano devkit).
- Select the JetPack version you want (e.g. a JetPack 5.1.x or 6.x that matches what you plan to use).
- Flash the OS. Optionally let it install CUDA/cuDNN and extra components.
Boot the Jetson, run the first-boot wizard.
On the Jetson, run:
```
sudo apt update
sudo apt upgrade
```
You should no longer see errors from nvidia-l4t-bootloader or nvidia-l4t-kernel.

That’s the “clean slate” option: safest, fully supported, and it prevents this particular problem from reappearing unless another partial firmware upgrade happens.

3. Short-term workaround if you can’t reflash yet

Sometimes you can’t reflash immediately (no spare host, don’t want to wipe the board yet, etc.), but apt keeps complaining.

The goal of the workaround is:

Leave your current bootloader/kernel alone (board is already booting fine).
Stop the broken nvidia-l4t-* scripts from failing every time dpkg runs.
Let apt install for normal packages (like Python libs) succeed.

This is more advanced and not officially recommended by NVIDIA, but it’s a common pragmatic fix used by experienced users when they’re in a bind.

3.1. Idea

Each problematic package has a script like:

/var/lib/dpkg/info/nvidia-l4t-bootloader.postinst
/var/lib/dpkg/info/nvidia-l4t-kernel.postinst
(similar for ...-headers, ...-display-kernel, ...-kernel-dtbs)

Those scripts do the check that fails. You can:

Back them up, then
Make them immediately exit 0 before they do anything, so dpkg thinks configuration succeeded.

3.2. Concrete steps

Go to the dpkg info directory:
```
cd /var/lib/dpkg/info
```

Back up the post-install scripts:

sudo cp nvidia-l4t-bootloader.postinst nvidia-l4t-bootloader.postinst.bak
sudo cp nvidia-l4t-kernel.postinst nvidia-l4t-kernel.postinst.bak

(You can back up the others too if they have .postinst files and also fail.)

Prepend exit 0 to short-circuit them:

sudo sed -i '1s/^/exit 0\n/' nvidia-l4t-bootloader.postinst
sudo sed -i '1s/^/exit 0\n/' nvidia-l4t-kernel.postinst

What this does: the script now returns success before it hits the board-ID logic.

Re-run configuration:
```
sudo dpkg --configure -a
```
Now dpkg should mark those packages as configured instead of erroring out.
(Optional) run:
```
sudo apt update
sudo apt upgrade
```
You should no longer see the nvidia-l4t-bootloader / “does not match any known boards” messages, because those scripts now exit successfully.

Important consequences:

Your Jetson keeps using whatever firmware/kernel it already had.
Those specific nvidia-l4t-* packages won’t actually update the bootloader anymore, because you’ve disabled the code that does it.
Whenever you do want to cleanly move to a new JetPack version, the right path is still to reflash; at that point you can restore the .bak versions or just let the fresh install provide new scripts.

So this is best treated as “get apt out of the way for now”, not a permanent solution.

4. How to avoid similar headaches in the future

4.1. Treat Jetson like an appliance OS, not like stock Ubuntu

NVIDIA’s docs explicitly say partial upgrades of Jetson Linux components can cause trouble, because boot firmware, kernel, and user-space libraries are tightly coupled. (NVIDIA Docs)

Practical rules:

Do not run:
- sudo do-release-upgrade
- sudo apt dist-upgrade or big “full” upgrades without reading Jetson release notes.
It’s generally fine to:
- sudo apt update
- sudo apt install <normal package> (e.g. python3.9, vim, git, etc.)
When you want to move to a new JetPack (e.g. 5.1 → 6.1):
- Follow NVIDIA’s JetPack / Jetson Linux upgrade instructions (Debian-based OTA or full reflash), not generic Ubuntu upgrade guides. (NVIDIA Docs)

4.2. Keep system Python separate from your project Python

You already did the right thing here:

Let /usr/bin/python3 remain whatever the OS ships (3.8 on Ubuntu 20.04).
Install extra interpreters like python3.9 or python3.10 beside the system one, not instead of it.

For each project, make a venv with the interpreter you want:

python3.9 -m venv ~/venvs/hf
source ~/venvs/hf/bin/activate
pip install --upgrade pip
pip install huggingface_hub

This avoids breaking system tools that assume python3 is the original version.

4.3. Avoid touching `update-alternatives` for `python3`

The update-alternatives calls you tried failed because /usr/bin/python3.10 didn’t exist, but even if they had worked, redirecting /usr/bin/python3 to a different version can break apt and NVIDIA scripts.

Best practice on Jetson: don’t register python3 itself with update-alternatives at all.

5. Quick recap

The huggingface_hub issue is already solved by moving to Python 3.9.5 (that’s exactly what it needed).
The dpkg error messages are from NVIDIA’s nvidia-l4t-* packages, whose bootloader/kernel updater script doesn’t recognise your board ID and refuses to run.
Because of that, those packages stay “half configured”, and every apt action that touches them prints E: Sub-process /usr/bin/dpkg returned an error code (1).

To have a solid, future-proof system:

Best fix: when possible, reflash the Jetson with a clean JetPack image via SDK Manager. That gives you a consistent bootloader/kernel/rootfs and a clean set of nvidia-l4t-* packages that work for your board.
Short-term workaround: back up and neutralise the failing nvidia-l4t-* post-install scripts so that dpkg --configure -a completes successfully; then plan a proper reflash later.
For the future:
- Avoid generic Ubuntu full upgrades on Jetson; follow NVIDIA’s JetPack/Jetson Linux update instructions instead.
- Keep system Python as-is, use extra interpreters + virtualenvs for your ML work, and avoid changing /usr/bin/python3 via update-alternatives.

Dyno108 · November 26, 2025, 3:39pm

Thanks so much for the detailed help, I didn’t realise following standard Ubuntu guides could be damaging so thanks again for letting me know.

To reflash the jetson, is it absolutely necessary to flash with a separate Ubuntu machine? its unlikely ill have one on hand for a long time, so would it be okay to use a Mac? if not would a Mac running an Ubuntu VM be a working fix?

John6666 · November 26, 2025, 10:40pm

It should work, but there’s definitely some risk when connecting the device and cables for communication using a VM instead of the actual hardware (VMs are generally fine for high-level processing, but their proficiency with low-level I/O-oriented tasks varies…).

For rewriting SD cards, it seems to work fine on Mac or Windows.

Short version:

You don’t always need a separate Ubuntu PC.
For some things (writing SD-card images) a Mac alone is fine.
For full “SDK Manager” flashing (especially QSPI bootloader / NVMe), NVIDIA still expects an x86-64 Ubuntu host. That can be a real PC or an Ubuntu VM/emulator on your Mac, but VMs are a bit fiddly.

Below is the breakdown with context so you can choose a path that actually fits your situation.

1. Two different “flash” jobs

On a Jetson Orin Nano devkit you usually care about two layers:

Root filesystem / OS (what lives on the microSD card or NVMe)
QSPI bootloader firmware (tiny flash chip on the module – basically “BIOS/UEFI + early boot”)

NVIDIA exposes two official installation methods for devkits:

SD Card Image Method – write a prebuilt JetPack image to a microSD card.
NVIDIA SDK Manager Method – use a host PC running Ubuntu + SDK Manager over USB to flash QSPI and/or rootfs. (Qiita)

Your dpkg errors (nvidia-l4t-bootloader, nvidia-l4t-kernel etc.) are essentially the “QSPI/bootloader update” part misbehaving. Reflashing is about getting both layers back into a consistent state.

2. What you can do with just a Mac

2.1. Re-image the SD card (rootfs) – Mac is completely fine

For the SD Card Image Method, NVIDIA’s own getting-started guide for the Orin Nano devkit literally shows using Balena Etcher on macOS to write the image.

Process (high level):

On your Mac, download the JetPack SD card image for “Jetson Orin Nano Developer Kit” from NVIDIA’s download center / JetPack page.
Install Balena Etcher (macOS build).
Use Etcher to flash the .img file to a microSD card.
Put the card in the Jetson, power on, go through the normal Ubuntu setup.

This completely resets the root filesystem on that microSD.
No Linux PC is required for this part.

This by itself may already clear a lot of “random dpkg mess” that came from experimenting on the old OS.

2.2. Limitation: QSPI bootloader updates for JetPack 6.x

The catch is the QSPI bootloader:

NVIDIA’s JetPack 6.x notes say: if you use a JetPack 6.x SD card image for the first time, you must first update the QSPI bootloaders by installing JetPack 6 once using SDK Manager. After that one-time step, future JetPack 6.x SD-card images can be used directly. (Qiita)

So:

If you stay on JetPack 5.x (e.g., 5.1.2 / 5.1.3 / 5.1.4), you can usually get away with just SD-card flashing from the Mac and not worry about SDK Manager right away.
For a first-time move to JetPack 6.x, or for certain QSPI fixes, NVIDIA still expects you to run a proper flash from an Ubuntu x86-64 host at least once.

Given your current errors are around nvidia-l4t-bootloader wanting to go to 35.5.0, a clean SD-card reflash to a known-good JetPack 5.x image (and then resisting the urge to “apt dist-upgrade to the next major JetPack”) is already a big step towards stability, and can be done from Mac only.

3. Using a Mac + Ubuntu VM/emulator for full SDK Manager flashing

When you do want to properly update QSPI or flash NVMe, then you’re in “SDK Manager territory”.

3.1. Official requirement: x86-64 Linux host

SDK Manager’s system requirements say the host must be Ubuntu Desktop on x86-64 (16.04 / 18.04 / 20.04 – newer docs also mention 22.04) or a similar Linux, not macOS or Windows. (NVIDIA Docs)

So NVIDIA’s official options are:

A physical x86-64 machine running Ubuntu, or
An x86-64 Linux environment reached via VM/emulation.

macOS itself is not a supported host for SDK Manager.

3.2. Intel Mac: Ubuntu VM is common (but unofficial)

If your Mac is Intel:

You can install VirtualBox, VMware Fusion, etc., and run Ubuntu x86-64 as a guest.
Inside that Ubuntu VM you install SDK Manager and flash the Jetson over USB.

Plenty of people have done this successfully; there are tutorials and forum posts describing the steps and USB pass-through quirks.

Typical gotchas:

You must configure the VM’s USB settings so that the “NVIDIA Corp. APX” device (the Jetson in recovery mode) is attached to the VM, not to macOS.
If the USB device disconnects or snaps back to macOS mid-flash, SDK Manager will hang or fail.

NVIDIA doesn’t officially “support” this, but it’s a widely used workaround.

3.3. Apple Silicon (M1/M2/M3) Mac: needs x86 emulation

On Apple Silicon:

The usual virtualisation tools (Parallels/UTM/VMware) default to ARM64 Ubuntu guests.
SDK Manager is built for x86-64, so you need an Ubuntu x86-64 guest under emulation (e.g., UTM with QEMU) if you want to run it.

People have successfully done exactly this: running an emulated Ubuntu 22.04 (x86-64) under UTM on an M-series Mac, installing SDK Manager there, and flashing a Jetson Orin Nano.

Trade-offs:

It works, but it’s slower and more fragile than a real x86-64 PC.
You still have to get USB passthrough right (UTM/Parallels must hand the Jetson’s USB device to the guest).

So: it’s doable if you’re patient and careful, but not “one click”.

4. Is a separate Ubuntu PC absolutely necessary?

Putting it all together:

To just reinstall the OS on SD (clean JetPack 5.x or a consistent JetPack 6.x SD image):
︎ No, a separate Ubuntu PC is not required. Your Mac + Balena Etcher is enough.
To do NVIDIA’s official “first-time” QSPI bootloader update and full JetPack install (especially for JetPack 6.x, or NVMe flashing):
︎ Yes, you effectively need some Ubuntu x86-64 environment – but it can be:
- A physical Ubuntu PC, or
- An Ubuntu x86-64 VM/emulator running on your Mac, with USB passthrough configured.
There are advanced host-less paths (like upgrading Orin Nano from JetPack 5 to 6 using only SD cards and on-device apt steps) that avoid SDK Manager, but they are more complex and easy to get wrong. For where you are now, I’d treat those as “later, when you’re comfortable and after reading the full guide”.

5. Practical suggestion for you right now

Given your situation (beginner, already on Python 3.9.5, and seeing scary nvidia-l4t-* dpkg errors):

Short term, Mac-only “stabilise things” plan
- Pick a JetPack 5.x SD-card image for Jetson Orin Nano Devkit (e.g. 5.1.3 or 5.1.4, whichever NVIDIA recommends for your use). (Qiita)
- On the Mac, use Balena Etcher to flash that image to a new or freshly erased microSD card.
- Boot the Jetson from that card and do the initial setup.
- On that fresh system:
  - Avoid do-release-upgrade or large dist-upgrade jumps that push you into a new JetPack/L4T major version; follow Jetson-specific guides instead of generic Ubuntu ones.
  - Use your Python 3.9.5 + venv approach for ML work.
This already gets you onto a known-good base and should avoid the broken nvidia-l4t-* state you hit earlier.
Later, when/if you want JetPack 6 or full QSPI reset
- Decide whether you’re willing to:
  - Borrow or build a small x86-64 Ubuntu box, or
  - Invest time in setting up an Ubuntu x86-64 VM/emulator on your Mac and learning how to pass the Jetson’s USB device through reliably.
- When you do that, run SDK Manager once to flash the board fully (QSPI + rootfs) to a JetPack version you want.
- After that one-time QSPI update, future SD-card images for the same JetPack major line are much simpler. (Qiita)

Tiny summary

Standard Ubuntu guides can be dangerous on Jetson because they assume a normal PC – Jetson’s firmware stack (the nvidia-l4t-* packages) is much more tightly coupled to the hardware.
For re-imaging the SD card, you can absolutely use just your Mac – that is officially documented and common practice.
For full “flash everything including QSPI” (especially for first-time JetPack 6.x use), NVIDIA still expects an x86-64 Ubuntu host. That can be:
- a real Ubuntu PC, or
- an Ubuntu x86-64 VM/emulator on your Mac with USB passthrough, which works but is more work to set up.
A sensible path for you is: stabilise the board via SD-card reflash from Mac now, and only worry about SDK Manager / full QSPI flashing once you’re ready and have some form of Ubuntu host available.

Topic		Replies	Views
Huggingface_hub integration: ModuleNotFoundError: No module named 'huggingface_hub' Amazon SageMaker	6	11549	December 6, 2021
ERROR: Could not find a version that satisfies the requirement torch==1.7.1+cpu Beginners	17	25270	December 15, 2020
Issue installing Transformers from source 🤗Transformers	2	6956	January 12, 2023
Something happend Beginners	0	275	November 24, 2021
Jupiter notebook unable to login Beginners	1	1188	September 24, 2022