Linux下升级Python后yum报错“No module named”怎么办

桃夭

发布时间：2026-10-10 | 2人浏览过

原创

在CentOS或RHEL等Linux发行版中，当用户为了运行新版软件而将默认的python解释器软链接指向新安装的Python 3后，执行yum命令经常会遭遇There was a problem importing one of the Python modules required to run yum. The error given is: No module named yum或No module named urlgrabber等致命报错。解决此问题的核心路径非常明确：无需回退已安装的Python 3，只需将yum及其辅助组件执行脚本的解释器引导行（Shebang），从通用的#!/usr/bin/python显式修改回系统底层的#!/usr/bin/python2或原生的具体版本解释器，即可让系统包管理器立刻恢复正常运转。

一、为什么升级Python会导致yum无法运行

在RHEL 7或CentOS 7等系统中，包管理器yum底层完全依赖系统预装的Python 2环境及其专用模块（如yum和urlgrabber）。这些模块通常被安装在/usr/lib/python2.7/site-packages/目录下。系统原本的/usr/bin/python是一个指向python2（或python2.7）的符号链接。很多开发者在编译安装Python 3之后，习惯性地执行了覆盖操作：

ln -sf /usr/local/bin/python3 /usr/bin/python

这一改动破坏了底层依赖链条。当yum启动时，它根据脚本头部的#!/usr/bin/python启动了Python 3解释器。然而，Python 3的模块搜索路径（sys.path）中并没有Python 2专用的yum依赖库，而且Python 2与Python 3存在语法不兼容，最终导致解释器抛出No module named yum并异常中断。

Linux下升级Python后yum报错“No module named”怎么办 — 图 1：yum 模块加载故障与解释器调用链路分析

二、分步排查与核心修复操作

明确了故障是由解释器映射错误引起的，修复操作便可以直接聚焦于修改脚本首行的解释器声明。整套修复流程分为确认环境、修改yum主脚本、修改辅助组件以及最终验证四个阶段。

步骤 1：排查现有 Python 版本与路径

在动手修改前，先检查系统内存在的解释器。在终端执行以下检查命令：

ls -l /usr/bin/python*

在标准系统输出中，你通常会看到类似如下的对应条目（示例输出）：

lrwxrwxrwx 1 root root   22 Oct 10 02:00 /usr/bin/python -> /usr/local/bin/python3
lrwxrwxrwx 1 root root    9 Oct 10 01:00 /usr/bin/python2 -> python2.7
-rwxr-xr-x 1 root root 7136 Aug  4  2020 /usr/bin/python2.7

这说明底层原始的/usr/bin/python2及/usr/bin/python2.7二进制实体仍然完好存在，只是公共的python入口被指向了新版本。

步骤 2：修复 /usr/bin/yum 的解释器指定

使用vi或nano打开/usr/bin/yum文件：

sudo vi /usr/bin/yum

查看文件首行，将其从原本的通用声明修改为显式版本：

# 修改前
#!/usr/bin/python

# 修改后
#!/usr/bin/python2

如果系统提示缺少python2，也可以直接填入确切绝对路径#!/usr/bin/python2.7。保存并退出编辑器。

步骤 3：修复 urlgrabber 拓展组件（解决下载阶段报错）

仅修改/usr/bin/yum后，执行命令虽然能启动，但在实际下载 RPM 包时，可能会进一步抛出以下报错：

  File "/usr/libexec/urlgrabber-ext-down", line 28
    except OSError, e:
                  ^
SyntaxError: invalid syntax

这是因为底层负责多线程下载的拓展辅助工具urlgrabber-ext-down同样指定了通用 python。请编辑该文件：

sudo vi /usr/libexec/urlgrabber-ext-down

将首行同样更改为指定 Python 2：

# 修改前
#!/usr/bin/python

# 修改后
#!/usr/bin/python2

其他可能涉及的系统工具：如果在后续维护中运行firewall-cmd等命令出现类似报错，请检查/usr/bin/firewall-cmd和/usr/bin/system-config-firewall等脚本首行，同样将其调整为指向python2。

三、多版本Python共存架构对比

许多初学者之所以直接替换/usr/bin/python软链接，是因为希望在终端中输入python直接调用 Python 3。但在工业级 Linux 服务器上，这种“全局直接覆盖”的做法会严重破坏底层系统运维软件的稳定性。推荐的做法是保持系统自带软件独立隔离，使用别名、独立命令名或虚拟环境（Virtualenv / Conda）。

推荐的多版本共存最佳实践如下：

保留系统默认 python 软链接：让/usr/bin/python继续指向python2。对于日常开发，显式使用python3与pip3命令。
使用用户级别名（Alias）：若希望当前登录用户默认输入python即打开 Python 3，可在用户的~/.bashrc中加入alias python='python3'，这仅作用于当前用户的交互式Shell，不会影响以root身份运行的系统服务与后台脚本。
基于 venv 隔离工程依赖：对具体的开发项目，通过python3 -m venv myenv创建独立虚拟环境，在虚拟环境中拥有完全隔离的python入口与模块空间。

四、验证修复结果与常见陷阱排查

在完成对/usr/bin/yum和/usr/libexec/urlgrabber-ext-down的修改后，在控制台执行测试指令验证修复状态：

yum clean all
yum makecache

如果控制台能顺利输出类似以下信息，则说明基础库导入、网络下载与元数据解析功能均已恢复正常：

Loaded plugins: fastestmirror
Cleaning repos: base extras updates
Cleaning up list of fastest mirrors
Determining fastest mirrors
Metadata cache created successfully.

排查中的常见陷阱：

尝试使用 pip 给 Python 3 安装 yum：PyPI 仓库中的 yum 包并不是针对该 Linux 系统打造的完整包管理器组件。试图通过pip install yum修复不仅无法解决问题，还可能产生命名冲突。
误删系统原本的 Python 2：如果执行过类似yum remove python或手动清空了/usr/bin/python2*与/usr/lib/python2.7，会导致底层大量基础服务（包括 rpm 工具库）直接损坏。此时只能通过挂载系统安装光盘镜像或使用 rpm 命令手动重新安装 python 基础 rpm 包。

综上所述，只要保证系统内置的 Python 2 环境未被物理删除，通过将依赖工具的 Shebang 头明确绑定到/usr/bin/python2，即可完美解决No module named错误，同时兼顾 Python 3 的正常开发需求。