Ubuntu升级遇到grub-efi-amd64-signed安装失败3步搞定这个烦人错误用Ubuntu的同学应该都遇到过这个场景系统提示有更新你点了“安装更新”结果跑到一半弹出来一个错误——grub-efi-amd64-signed安装失败然后整个升级过程直接卡住要么反复提示修复要么只能强制重启重启后系统还进不去。这个错误我前前后后踩过好几次从18.04升级到20.04、20.04升级到22.04甚至只是普通的内核安全更新都有概率触发。网上搜一圈回答要么让你关Secure Boot要么让你直接重装GRUB但对很多朋友来说这些操作看得一头雾水更怕自己乱敲命令把引导弄坏。这篇文章我会把这个问题彻底拆开用三步解决大多数场景下的grub-efi-amd64-signed安装失败问题。全文面向所有Ubuntu用户无论你是桌面版还是服务器版、是双系统还是单系统这套排查思路基本通用。更重要的是我会把每一步背后的原理讲明白而不是让你机械地复制命令——毕竟下次再遇到你还是要能自己判断才行。1. 先搞清楚grub-efi-amd64-signed是什么以及它为什么会装失败1.1 这是UEFI引导链上的一环不是可有可无的软件包grub-efi-amd64-signed名字拆开看就是GRUB引导程序、EFI架构版本、amd64 CPU架构、signed签名。它是Ubuntu在UEFI模式下启动时使用的引导加载程序负责在电脑开机后把操作系统内核加载进内存。如果你用的是近五六年买的电脑基本都是UEFI启动而不是老式BIOS启动那这个包就是系统引导链里最底层、最核心的组件之一。它不是什么可装可不装的扩展工具而是Ubuntu能不能正常开机的关键。顺带提一句现在绝大多数主流发行版在UEFI Secure Boot安全启动场景下实际引导顺序是主板固件 → shim第一个被验证的引导程序 → GRUB → 内核。grub-efi-amd64-signed这个包就是做了微软签名验证的GRUB允许它在开启Secure Boot的情况下被主板信任。如果你关闭Secure Boot理论上确实能绕过签名验证的问题但根本问题没解决升级程序照样报错。1.2 升级时它安装失败最常见的原因是磁盘空间不足先说结论在大多数情况下这个错误和系统本身的健康状态关系不大而是因为升级过程中涉及到的存储空间不够了。Ubuntu的默认分区方案里通常会单独划一个/boot分区大小一般只有几百MB到1GB左右。这个分区专门放引导相关文件比如内核镜像、initrd初始内存盘、GRUB模块等。系统每次升级内核都会往/boot里写入新文件。而GRUB本身又需要往/boot/efi也就是EFI System PartitionESP分区写入引导文件。这两个分区尤其是/boot一旦满了grub-efi-amd64-signed的postinst脚本安装后配置脚本就会因为无法写入文件而失败。dpkg检测到脚本返回非零状态就会中止整个升级流程告诉你“安装失败”。可以把这个场景类比成搬家房间本身没问题家具也是新的但门口的走廊堆满了杂物新冰箱根本送不进去。这就是为什么很多教程会让你“删几个旧内核”本质上是清理走廊。1.3 其他导致安装失败的原因除了磁盘空间还有几类原因需要排查软件源问题本地缓存的软件包索引和实际版本不一致或者某些PPA个人软件源提供的依赖版本冲突导致grub-efi-amd64-signed下载不完整或被其他版本覆盖。dpkg状态错乱之前某次安装中断比如强制关机、断电导致dpkg数据库里残留了“半配置”half-configured状态后续所有安装操作都会卡住。EFI分区挂载异常/boot/efi分区因为某些原因没有被正确挂载或者挂载后文件系统出现错误导致GRUB写不进去。安全启动状态变化如果系统安装时开了Secure Boot但你在BIOS里关掉了它某些情况下升级脚本也会出现异常。所以第一步不是急着修复而是先做诊断确认到底卡在哪一环。1.4 动手前必须执行的诊断命令在终端执行下面这几条把输出截图或者记下来# 查看磁盘空间重点是/boot和/boot/efi df -h # 查看当前内核版本 uname -r # 查看dpkg是否有未完成的配置任务 sudo dpkg --configure -a # 查看grub相关包的安装状态 dpkg -l | grep grubdf -h的输出里如果/boot这一栏的“已用”接近100%或者/boot/efi接近100%那基本可以确定就是空间问题。dpkg -l | grep grub的输出里如果状态列出现iF、iU、iH这类非ii的标记说明包处于中断状态也需要修复。注意dpkg -l里状态列是两位字符第一位表示期望状态i表示希望安装第二位表示实际状态i表示已安装。ii才是正常状态iF表示半配置iU表示已解包但未配置iH表示半安装。看到非ii的基本就是dpkg状态出了问题。2. 第一步腾出空间让系统能喘口气2.1 清理apt缓存这步白送空间apt在下载软件包后会缓存到/var/cache/apt/archives目录。经过几个月甚至几年的更新这个目录里攒下的.deb文件体积可能相当可观。清理它是最安全的操作不会影响任何已安装软件。sudo apt clean如果不想全部清空也可以用apt autoclean只删除已经下载但不再可用的旧版本包文件。2.2 删除旧内核这是腾空间的大头Ubuntu的内核更新频率不高但每次更新都会占用/boot几百MB空间。如果你很少重启、系统跑了好几个月/boot里可能躺着五六套内核文件。删除旧内核是最有效的腾空间手段。先看当前系统正在用哪个内核这套内核绝对不能删uname -r假设输出是6.8.0-40-generic然后列出/boot目录下所有内核相关文件ls -lh /boot/vmlinuz-* /boot/initrd.img-*你会看到多个版本的内核镜像文件和initrd文件。删除旧内核的标准做法是使用apt来删让包管理器同步更新dpkg数据库sudo apt remove --purge linux-image-旧版本号-generic linux-headers-旧版本号-generic比如要删除6.5.0-15版本sudo apt remove --purge linux-image-6.5.0-15-generic linux-headers-6.5.0-15-generic一个常见的坑是如果你在/boot分区空间几乎为0的情况下试图用apt删包apt本身可能也会因为需要写临时文件而失败。这时候可以绕过包管理器直接手动删文件sudo rm -f /boot/vmlinuz-旧版本号 /boot/initrd.img-旧版本号 /boot/System.map-旧版本号 /boot/config-旧版本号然后重建initramfssudo update-initramfs -c -k 当前版本号不过手动删除之后dpkg数据库里还会有残留记录之后最好再用sudo apt -f install修正一下。2.3 清理日志文件别忽略这个隐形胖子systemd日志journal是另一个容易被忽略的空间占用来源但它默认存在/var/log/journal目录占的是根分区而不是/boot分区。如果你的根分区也比较紧俏可以顺手清一清sudo journalctl --vacuum-size50M这条命令会把日志压缩到50MB以内。放心这不影响系统运行只是把旧日志丢了。2.4 顺手检查一下EFI分区df -h里/boot/efi如果也接近满了同样需要清理。这个分区用的是FAT32格式里面存的是各个操作系统的引导文件目录结构通常长这样/boot/efi/EFI/ubuntu/Ubuntu的引导文件目录/boot/efi/EFI/Microsoft/Windows的引导文件目录如果你装了双系统清理EFI分区时只建议删除/boot/efi/EFI/ubuntu/下的旧备份文件比如带有日期的.bak后缀文件不要动Windows相关的文件也不要乱删shimx64.efi、grubx64.efi这种核心文件。3. 第二步修复dpkg状态把包管理器摆正3.1 先尝试自动修复这通常就够了如果前面的空间已经腾出来了第一步往往就能解决问题。但为了保险还是要把dpkg的装态修复一下。dpkg是Debian系操作系统的底层包管理器apt是基于它的上层工具。如果dpkg认为某个包处于“待配置”状态它会阻塞所有其他安装操作。把之前中断的配置流程跑完sudo dpkg --configure -a这条命令会重新运行所有等待配置的包的配置脚本。输出可能会很长耐心看完。如果结尾没有任何报错说明dpkg状态已经恢复正常。3.2 如果自动修复卡住强制移除再重装有时候dpkg --configure -a会在grub-efi-amd64-signed这个包上反复失败陷入死循环。这时候需要强制移除这个出问题的包再重新安装。sudo dpkg --remove --force-remove-reinstreq grub-efi-amd64-signed--force-remove-reinstreq的意思是“即使这个包处于需要重装的状态也强制移除”。这个参数平时要慎用但在包已经损坏、无法正常配置的情况下直接移除是干净利落的做法。如果报错说某个文件被其他包依赖可以再加上--force-remove-essential——但注意这是非常暴力的手段只在确认这个包本身已经损坏时才使用sudo dpkg --remove --force-remove-reinstreq --force-remove-essential grub-efi-amd64-signed3.3 手动清掉残留的配置信息强制移除后dpkg的info目录里可能还残留着这个包的脚本文件这些残留会导致重新安装时老脚本再次报错。手动清一下sudo rm -f /var/lib/dpkg/info/grub-efi-amd64-signed.*然后再更新一下包列表sudo apt update3.4 重新安装grub-efi-amd64-signed修复状态后重新安装这个包sudo apt install grub-efi-amd64-signed安装过程中如果提示需要配置shim-signed这是Secure Boot链上的另一个重要包一并同意即可。通常apt会自动解析依赖。如果提示依赖不满足可以试试强制修复依赖sudo apt -f install-f参数会自动修复所有依赖关系问题它会根据已安装包的依赖要求自动安装缺失的包或移除冲突的包。注意如果你用的是传统BIOS引导非UEFI对应的包名是grub-pc而不是grub-efi-amd64-signed。怎么判断自己用的是哪种引导模式执行ls /sys/firmware/efi如果这个目录存在且非空说明是UEFI模式如果提示No such file or directory则是传统BIOS模式。本文的修复针对的是UEFI模式。4. 第三步重建GRUB引导确保系统能正常开机4.1 确认EFI分区挂载正确在重新安装grub-efi-amd64-signed之后系统理论上已经能引导了但为了万无一失建议再执行一次完整的GRUB重建流程把引导文件确确实实地写进EFI分区。先确认EFI分区是否挂载mount | grep efi正常会看到类似/dev/sda1 on /boot/efi type vfat的输出。如果没有输出需要手动挂载。先查看哪块分区是EFI分区用lsblk -f查看所有分区的文件系统类型找到类型为vfat且大小在100MB到500MB之间的分区大概率就是EFI分区。假设是/dev/sda1sudo mount /dev/sda1 /boot/efi4.2 用grub-install重建引导文件这一步是把GRUB模块和核心引导文件重新写入EFI分区sudo grub-install --targetx86_64-efi --efi-directory/boot/efi --bootloader-idubuntu --recheck参数说明--targetx86_64-efi指定安装目标架构为64位EFI--efi-directory/boot/efi指定EFI分区挂载点为/boot/efi--bootloader-idubuntu指定启动项标识为ubuntu在BIOS启动菜单里会显示这个名字--recheck重新检查设备映射避免因为设备顺序变化导致错误执行完之后/boot/efi/EFI/ubuntu/目录下应该能看到shimx64.efi如果启用了Secure Boot和grubx64.efi文件。4.3 用update-grub生成引导菜单最后一步重新生成GRUB配置文件sudo update-grub这个命令会自动扫描系统里安装了哪些操作系统、哪些内核并生成新的启动菜单。如果一切正常输出里会列出检测到的内核镜像列表。如果你在升级前用的是Windows双系统update-grub还会通过os-prober扫描出Windows启动项并加入菜单。如果没有检测到可以检查一下/etc/default/grub里的GRUB_DISABLE_OS_PROBER是不是被设置成了true改成false后重新执行update-grub。4.4 重启验证引导链完整到这里三步操作完毕执行sudo reboot重启系统。开机后如果能正常进入系统说明GRUB引导链修复成功。如果启动菜单出现多个旧内核选项可以登录系统后用前面的方法清理。提示在执行reboot之前建议先跑一遍sudo apt update sudo apt full-upgrade把之前中断的升级彻底跑完避免下次开机又撞到同一个问题。5. 终极手段上面三步全做了还是不行怎么办在绝大多数情况下上面三步已经能解决问题。但总会有一些特殊情况——比如EFI分区本身有坏块、GRUB文件损坏到无法修复、或者引导链彻底乱了。这时候需要一些更暴力的手段。5.1 用Live USB进入系统chroot修复这是最常用的终极修复手段。准备一个Ubuntu的Live USB开机时进入Live环境然后通过chroot进入硬盘里的系统在系统内部重新执行GRUB修复。步骤大致如下假设根分区是/dev/sda2EFI分区是/dev/sda1# 挂载根分区到临时目录 sudo mount /dev/sda2 /mnt # 挂载EFI分区 sudo mount /dev/sda1 /mnt/boot/efi # 挂载必要的系统目录让chroot环境能正常通信 sudo mount --bind /dev /mnt/dev sudo mount --bind /proc /mnt/proc sudo mount --bind /sys /mnt/sys # 进入chroot环境 sudo chroot /mnt进入chroot后就相当于在原来的系统里操作可以重新执行grub-install和update-grub。退出chroot后重启问题基本都能解决。5.2 检查Secure Boot状态如果你在BIOS设置里看到Secure Boot是开启状态但Ubuntu安装时并没有在开启状态下安装GRUB可能无法通过签名验证。这时候有两种选择在BIOS里暂时关闭Secure Boot重启后执行一次sudo update-grub再回到BIOS里开启注意某些主板上开了Secure Boot后会自动忽略未签名引导项这种方式不一定有效。重新执行一次完整的grub-install确保shimx64.efi被正确写入这样在Secure Boot开启的状态下也能正常引导。有一点值得强调不要为了图省事永久关闭Secure Boot。虽然Ubuntu在关闭Secure Boot后依然能正常工作但开启Secure Boot是挡住了bootkit和部分恶意软件的第一道防线。如果你不懂怎么判断签名是否可信保持系统默认设置往往是最安全的。5.3 用efibootmgr检查主板上的启动项有时候GRUB文件都修复好了但主板固件里的启动项指向了错误路径。用efibootmgr查看当前NVRAM里的启动配置efibootmgr -v输出里会列出所有UEFI启动项找到Ubuntu对应的那条Boot000x确认File路径指向的是\EFI\ubuntu\shimx64.efi或\EFI\ubuntu\grubx64.efi。如果路径不对可以用efibootmgr手动调整sudo efibootmgr -c -d /dev/sda -p 1 -L Ubuntu -l \EFI\ubuntu\shimx64.efi-c表示创建新启动项-d指定磁盘设备-p指定EFI分区号-L设置显示名称-l指定引导文件路径。路径中的反斜杠是UEFI固件标准格式不要换成Linux风格的正斜杠。6. 常见问题与排查技巧实录实际操作中会遇到各种变体我把常见情况整理成一张速查表症状根本原因解决方案apt出现E: Sub-process /usr/bin/dpkg returned an error code (1)dpkg存在未完成的配置sudo dpkg --configure -a升级提示grub-efi-amd64-signed无法安装postinst脚本报错/boot或/boot/efi已满清理旧内核、清apt缓存重试安装强制移除grub-efi-amd64-signed后apt -f install报依赖冲突dpkg info目录残留rm -f /var/lib/dpkg/info/grub-efi-amd64-signed.*再重新安装grub-install提示failed to get canonical path of /boot/efiESP分区未挂载mount /dev/sda1 /boot/efi按实际设备号调整update-grub扫不到Windows启动项os-prober被禁用或Windows引导配置损坏修改/etc/default/grub将GRUB_DISABLE_OS_PROBER设为false重跑update-grub重启后直接进了GRUB命令行grub提示符配置文件缺失或损坏在GRUB命令行手动指定内核启动进入系统后执行sudo update-grub开机提示Boot Device Not FoundEFI分区里没有有效的引导文件Live USB chroot后执行grub-install和update-grub安装时提示The following packages have unmet dependencies软件源版本混乱sudo apt update sudo apt full-upgrade必要时移除第三方PPA6.1 一个容易被忽略的陷阱PPA源引发的依赖大战我自己遇到过一次很难缠的情况系统里装了一个第三方的PPA源用于提供更新的显卡驱动这个PPA提供的grub包版本比Ubuntu官方源里的更新结果升级时apt把grub-efi-amd64-signed解析到了PPA版本而PPA版本和Ubuntu的安全引导支持不兼容导致安装失败。排查思路是看apt policy grub-efi-amd64-signed输出里候选版本是来自哪个软件源。如果来自第三方PPA可以把PPA禁用或移除强制apt从官方源获取sudo apt install grub-efi-amd64-signed官方版本号或者更简单sudo apt install grub-efi-amd64-signed/ubuntu-updates指定源安装后再重新执行apt full-upgrade。6.2 双系统用户特别注意不要在Windows里“修复”GRUB如果你是Ubuntu和Windows双系统有过从Windows侧的磁盘管理工具里对EFI分区执行“格式化”或者“修复”操作那Ubuntu的引导文件会直接没了。到时候开机直接进Windows完全看不到GRUB菜单。这种场景的修复方式和5.1节提到的Live USB chroot是同一套流程不要尝试在Windows里用第三方工具去“恢复Linux引导”容易把问题搞得更大。用Live USB从外部进入在chroot环境里执行grub-install --targetx86_64-efi --efi-directory/boot/efi --bootloader-idubuntu重启后GRUB就能恢复。6.3 升级过程中断电这是最冤的死法我遇到过一次印象特别深的状况升级走到一半家里跳闸了。来电之后再开机系统直接卡在GRUB界面怎么都起不来。进Live环境一看dpkg状态一塌糊涂一个包里一半文件是新的、一半是旧的。这种场景下任何常规修复手段都失效了因为包的版本状态已经无法对齐。我当时的选择是先备份家目录和关键配置文件到移动硬盘。用Live USB直接重装系统安装时选择“保留数据和已安装应用”让安装器自动修复系统文件。这不是最优雅的方案但却是最快恢复工作状态的办法。在重装之前一定要先备份数据这是底线。7. 补充几条系统维护经验说完案例顺手聊聊我平时做Ubuntu升级的几个习惯都是踩过坑之后总结出来的。升级前先查空间。这个习惯能避免一大半问题。执行df -h花10秒钟就能确认/boot、/boot/efi、/分区是否有充足空间。尤其是/boot建议任何时候都保持至少200MB以上的空闲。内核清理要定期做。别等升级报错了才想起来删旧内核。你可以装一个byobu或者直接用apt autoremove --purge定期自动清理无用的内核包。注意apt autoremove不会自动清除正在使用的内核所以安全性是有保障的。升级前把重要数据备份一份。这个属于老生常谈但还是要强调。Ubuntu升级总体是靠谱的但总有小概率翻车。一个简单的办法是把家目录里最要紧的文件夹压缩后放到另一个硬盘或者网盘上花不了几分钟但能救命。用Timeshift做系统快照。如果你是桌面用户强烈建议安装Timeshift它可以对系统分区做增量快照升级前拍一个升级坏了直接回滚比手动修复省事一百倍。配置方式很简单设置里选择备份目标磁盘和备份频率有空就恢复一次。它不帮你解决升级报错本身但能让你从“系统坏了”变成“系统没坏过”。最后说点掏心窝的话grub-efi-amd64-signed安装失败这个问题本质上是Ubuntu包管理器对引导链完整性的一种“保守保护”——它对任何失败的配置脚本都会中止整个升级流程宁可当前系统保持原样也不让你得到一个半吊子的引导环境。所以遇到它真的不用慌按照“诊断空间→修复dpkg→重建GRUB”的顺序一步步走绝大多数情况下都能解决。最怕的不是报错而是不知道这个包是干什么的然后乱搜一通、乱删一通把引导链搞得面目全非。希望这篇文章能帮你少走弯路。如果你按照上面的步骤操作时遇到和文章描述不完全一样的情况大概率还是空间或依赖的问题把报错信息里第一行“Failed”或者“E:”开头的日志发出来顺着日志往下排查思路永远不会错。