PIP Illegal Instruction

Python Help
1

I ran ‘sudo pip3 install paramiko’ which seem to error out on my PI ZERO W.

When I try to either access ‘paramiko’ or do anything with PIP I get the error ‘illegal instruction’. Some examples:

paul@piZERO:~ $ 
paul@piZERO:~ $ python3
Python 3.9.2 (default, Mar 12 2021, 04:06:34) 
[GCC 10.2.1 20210110] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> import paramiko
Illegal instruction

paul@piZERO:~ $ sudo pip3 show paramiko
Illegal instruction

paul@piZERO:~ $ sudo pip3 list
Illegal instruction

paul@piZERO:~ $ sudo pip3 uninstall paramiko
Illegal instruction

Here are the locations I’ve found the package at:

/usr/local/lib/python3.9/dist-packages/paramiko
/usr/local/lib/python3.9/dist-packages/paramiko-3.2.0.dist-info
/usr/lib/python3/dist-packages/mypy/typeshed/third_party/2and3/paramiko

Is there a process to manually remove a PIP installed package?

2

I ran python3 in verbose mode (-v). When I imported paramiko, I saw that the ‘illegal instruction’ was raised when loading bcrypt. Checking the MANIFEST of paramiko, I saw that it was one of the dependencies. I manually ran a ‘sudo rm -r /usr/local/lib/python3.9/dist-packages/bcrypt*’. After that I was able to successfully run a ‘sudo pip uninstall paramiko’.

May not be the cleanest approach, but it worked.

3

There’s the ultimate problem. Never, ever, ever, ever run sudo pip-anything unless you know exactly what you are doing, as it modifies the system-installed packages in the system-installed Python. Otherwise, you can and often will break not only one specific package or environment, but your entire system Python install, and sometimes even your whole operating system itself (if, say, the package manager relies on that same Python install, as many often do). On newer Linux distros (and pip versions), pip will actively refuse to run against the system-installed Python if the Linux distro marks it as such, unless you deliberately pass the special highly discouraged flag --break-system-packages.

I can’t narrow it down without seeing the actual output from the install command you ran, but based on that output, likely some compiled code or dependencies got replaced with something not compiled for your platform, i.e. armhf, arm7 or armv8a (aarch64) depending on your version and edition of Raspbian. Therefore, simply uninstalling paramiko might well not solve it.

As a shotgun approach, you could try deleting everything in the /usr/local/lib/python3.9/dist-packages and then attempting to update pip. You can also create a new, isolated virtual environment, which you should always use over the system environment, with python3 -m venv .venv (or whatever you prefer for its name and location other than .venv), activate it, and install the package you want in that (without using sudo, of course).

If that still doesn’t work, you could try using your system package manager to re-install the system pip, e.g. sudo apt update && sudo apt remove python3-pip && sudo apt install python3-pip.

And if that doesn’t work, I’d re-flash the Pi with the latest OS image (which you might want to do from the start, if you don’t have much valuable on it that you can’t easily back up and restore).

The most important thing to remember to prevent this is NEVER EVER EVER USE sudo pip ANYTHING. Instead, create and activate one of more venvs.

Best of luck!

1 Like
4

Thanks @CAM-Gerlach. So, I really should pay attention to the warnings that are now displayed when using ‘sudo pip’ :wink:

Since I have your attention, the reason I use ‘sudo’ is because in the past a package would only be installed local to my user rather than system wide. Do I have to do something special to install system wide with PIP?

I have a bug open on bcrypts bug page.

5

If you want a package to be installed for your whole system, then use your system package manager (apt, assuming you’re on Raspbian/RPiOS). That’s what its there for :slightly_smiling_face: If the package you need isn’t available on it, you could, for example, install it in a system-wide venv (potentially using --system-site-packages) in a location that admins can write and all users can read.