Struggling to install huggingface_hub

Beginners
4

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:

  1. The clean, recommended fix (reflash JetPack / Jetson Linux).
  2. A short-term workaround if you can’t reflash yet.
  3. 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)

  1. Back up your data
    Copy off anything you care about from /home (projects, notebooks, models, etc.).

  2. On a separate Ubuntu x86_64 machine, install NVIDIA SDK Manager. (NVIDIA Docs)

  3. 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).

  4. 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.

  5. Boot the Jetson, run the first-boot wizard.

  6. 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

  1. Go to the dpkg info directory:

    cd /var/lib/dpkg/info

  2. 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.)

  3. 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.

  4. Re-run configuration:

    sudo dpkg --configure -a

    Now dpkg should mark those packages as configured instead of erroring out.

  5. (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.
1 Like