GPG验证失败需先定位断点：密钥缺失、过期、指纹不符、源废弃或系统时间偏差；对应操作包括提取NO_PUBKEY后16位ID导入密钥、清理旧密钥重装最新版、核对源地址与发行版代号、校准系统时间或重建密钥环。
遇到 GPG 验证失败，不是加 --nogpgcheck 就完事。真正要解决，得先弄清是哪一环断了——密钥没导入？导入了但过期？指纹对不上？还是源本身已失效？下面分几类常见原因，直接对应操作。
密钥缺失或未正确导入
这是最基础也最常见的原因：系统根本没这个仓库的公钥。
- 看错误里有没有
NO_PUBKEY或类似提示，后面跟着一串 16 位十六进制码（比如871920D1991BC93C），这就是你要找的密钥 ID - Ubuntu/Debian 系统可尝试：
sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 871920D1991BC93C - RHEL/CentOS/Rocky/AlmaLinux 系统则用：
sudo rpm --import https://repo.mysql.com/RPM-GPG-KEY-mysql-2022（换成你对应软件的官方密钥 URL）
密钥存在但已过期或被轮换
很多项目（如 MySQL、PostgreSQL、Kali）会定期更新签名密钥。旧密钥仍留在系统里，但新包已用新密钥签名，导致“密钥已安装却不匹配”。
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 运行
rpm -qa gpg-pubkey*（RHEL系）或apt-key list（Debian系）列出当前所有密钥 - 查官网文档确认最新密钥指纹（例如 MySQL 2022 密钥指纹是
3A79BD29），再用rpm -qi gpg-pubkey-3a79bd29-*或apt-key finger核对本地是否一致 - 不一致就先卸载旧密钥：
RHEL系：sudo rpm -e gpg-pubkey-5072e1f5-*
Debian系：sudo apt-key del 5072E1F5（ID 去掉前缀 0x） - 再重新导入官网提供的最新密钥
软件源配置异常或已废弃
仓库地址失效、协议写成 http://、发行版代号过时（如还在用 focal 却已升级到 jammy），都会让 GPG 验证找不到对应签名文件。
- 检查
/etc/apt/sources.list（Debian/Ubuntu）或/etc/yum.repos.d/*.repo（RHEL系），确认 URL 是https://开头 - 核对发行版代号是否与当前系统匹配：
lsb_release -sc或cat /etc/os-release | grep VERSION_CODENAME - 临时注释掉可疑第三方源，再运行
apt update或dnf makecache，看错误是否消失，从而定位问题源
系统时间偏差或密钥环损坏
GPG 签名带时间戳，若服务器时间严重不准（快或慢几小时以上），验证会直接失败；密钥环文件损坏也会导致识别异常。
- 用
timedatectl status查时间同步状态，未启用则执行：sudo timedatectl set-ntp true - Debian/Ubuntu 下若多次导入无效，可能是
/etc/apt/trusted.gpg损坏：
先备份：sudo cp /etc/apt/trusted.gpg /etc/apt/trusted.gpg.bak
再重建：sudo rm /etc/apt/trusted.gpg && sudo apt update（会自动重建） - RHEL 系可尝试清理缓存：
sudo yum clean all或sudo dnf clean all
