报错记录

图形界面卡死

有时会出现显示突然卡死在当前画面的现象，过了很久依然是卡死状态。这种现象通常被称为 “硬冻结”（Hard Freeze），确实让人抓狂，尤其是辛辛苦苦做的工作瞬间处于危险之中。

Step 1 盲打保存键

先盲打（因为看不到图形界面的变化）相应软件的保存快捷键，很多是 Ctrl + S。

Step 2 确认是否仅有显示层冻结

1. 如果桌面环境是 Cinnamon，请尝试按 Alt + F2（快速运行命令），再按 r，Enter 下去（重启 Cinnamon 的命令）。看能否解决卡死问题。否则继续看后面的步骤。
2. 如果键盘有 NumLock 或 CapsLock 灯，尝试按一下，看灯是否切换。如果灯能变化，说明内核还活着，只是图形栈卡死了；如果完全没反应，可能是内核或硬件层面挂死。
3. 尝试进入 tty

   进入 tty<n> 的方法为，Ctrl + Alt + F<m>。 <n>取1到6；<m>有6个值，取值范围在不同发行版不同，取1到6。例如，Ubuntu 中 <m> 为 3到8。

Step 3 重启什么呢

情况1：能进入 tty

方案 A：重启桌面环境

export DISPLAY=:0
cinnamon --replace &

• export DISPLAY=:0：这一步至关重要！TTY 是纯文本环境，它不知道要把图形界面显示在哪个屏幕上。这行命令告诉系统：“我要操作的是 :0 号图形显示器（即你的主屏幕）”。
• cinnamon --replace：告诉系统强制接管并替换当前卡死的 Cinnamon 桌面进程。
• &：让这个命令在后台运行，这样即使你退出 TTY，它也不会中断。 然后按下 Ctrl + Alt + F7（或 F1、F2 等，取决于你的Linux发行版把图形界面挂载在哪个通道），切回图形界面。你会发现屏幕闪烁几秒，然后桌面恢复了，卡死前打开的窗口、未保存的文档大概率都完好无损地躺在那里！ 其他桌面环境的处理方法类似。

方案 B：优雅杀死 Cinnamon 进程，拉起新桌面

如果方案A失效了，说明Cinnamon 已经死透了，连 --replace 信号都接收不到。此时只能采取“退而求其次”的办法——虽然保不住当前的工作状态，但至少可以安全地退出并重启图形界面，免去重启整台电脑的痛苦（方案C也是这样）。

pkill -HUP cinnamon

-HUP 信号会尝试让程序平稳重启，有时候也能保留一部分软件状态。

方案 C：重启显示管理器（DM）

如果连 Cinnamon 进程都杀不动，说明底层的显示管理器也死锁了。在 TTY 中运行以下命令来重启它：

sudo systemctl restart display-manager
# 或 sudo systemctl restart <DM>

查看DM的方法：

$ cat /etc/X11/default-display-manager
/usr/sbin/lightdm   # <DM> 的值是 lightdm

⚠️ 注意：重启 DM 会直接注销当前用户。这会丢失所有未保存的工作，它等同于 Ctrl + Alt + BackSpace 的效果，但优点是 100% 能让你回到登录页面，避免了强行拔电源对硬盘的伤害。

情况2：不能进入 tty

方案A：Magic SysRq Key 魔法键

只要内核还没完全崩溃（Panic），这个方法就能绕过图形界面，直接向内核发送命令，是替代硬重启的核心手段。

按住 Alt + PrintScreen 的同时，依次单独按以下字母键（不用按Shift），每个字母之间间隔1-2秒，经典口诀 "REISUB"：

键	全称	作用
R	Raw	把键盘切回原始模式（防止死锁影响输入）
E	TErminate	给所有进程发 SIGTERM（尝试正常终止）
I	KIll	给所有进程发 SIGKILL（强杀）
S	Sync	同步磁盘（sync，防止数据丢失）这一步最关键
U	Umount	重新挂载文件系统为只读
B	ReBoot	立即重启

如果只想恢复显示而不重启，可以只按 R（重置键盘）看能否恢复响应；如果显示服务（X11/Wayland的compositor）单独崩了而内核正常，有时候单独重启显示管理器能救回来。

如果只是想保数据后重启，最少做到 S（sync）再重启，比直接拔电源安全得多。

注：使用 Magic SysRq Key 的前提

前提是内核开启了 SysRq（通常默认是开的）：

$ cat /proc/sys/kernel/sysrq 
176

176 是什么意思呢？涉及 Linux 内核对 sysrq 掩码的一个特殊设计。

位值	十进制	功能
bit 0	1	特殊值:启用所有功能(见下方说明)
bit 1	2	允许控制控制台日志级别(如 sysrq+数字调节打印等级)
bit 2	4	允许控制键盘(SAK、解除raw模式)—— 对应 R
bit 3	8	允许调试性转储(进程状态、内存等)—— 对应 P、T、M等
bit 4	16	允许 sync —— 对应 S
bit 5	32	允许只读重挂载 —— 对应 U
bit 6	64	允许发信号给进程(term/kill/oom)—— 对应 E、I、F
bit 7	128	允许重启/关机 —— 对应 B、O
bit 8	256	允许调整所有实时任务的nice值

176 = 16 + 32 + 128 = bit4 + bit5 + bit7，只开启了 S、U、B 键的功能。如果想开启完整的 REISUB，就要设成 4 + 2 $\times$ 64 + 176 = 244，1 也能实现，相较 244 多了 bit1、bit3、bit8 这些调试功能，作用是把内核内部状态直接打印到内核日志(dmesg / journalctl)，不需要与系统正常交互，非常适合死机边缘时抓现场证据，使用步骤如下：

1. 死机时按顺序抓现场 先抓诊断信息，再执行REISUB，顺序类似:

   Alt+SysRq+L   → 打印所有CPU调用栈(最重要,直接看卡在哪)
   Alt+SysRq+T   → 打印任务列表
   Alt+SysRq+W   → 打印阻塞任务(D状态进程)
   Alt+SysRq+M   → 打印内存状态
   （等1-2秒让日志写入）
   Alt+SysRq+R   → 再走正常的REISUB恢复流程
   Alt+SysRq+E
   Alt+SysRq+I
   Alt+SysRq+S
   Alt+SysRq+U
   Alt+SysRq+B

   L(打印所有CPU栈)在某些死锁场景下输出可能非常长,如果你的系统当时已经严重卡死,执行这个命令本身也可能耗时较久甚至不完全成功——但按了总比不按强,能抓到多少是多少。

2. 重启后分析

   journalctl -b -1 -k | grep -A 30 "SysRq"

   重点看:
   • L/P 输出里,如果多个CPU的调用栈都卡在同一个函数(尤其是显卡驱动如 nvidia_*、amdgpu_*、i915_*),基本可以断定是驱动死锁
   • W 输出如果显示某进程长期处于 D 状态且栈顶是某个内核模块函数,同样指向驱动/硬件问题

要开启 REISUB 的所有键，可以设置：

sudo sysctl -w kernel.sysrq=1
# 永久生效：
echo "kernel.sysrq=1" | sudo tee /etc/sysctl.d/99-sysrq.conf

建议设成 1 而非 244，更省心也更全面。1 比 244 多的功能只有在你手动按键时才会真正实行。

方案B：重启系统，和工作进度说拜拜

如果 SysRq 也救不回来，那么已经进入了内核死锁，给主板/笔记本直接断电，然后重新通电即可。

过时的密钥环

W: http://packages.ros.org/ros/ubuntu/dists/focal/InRelease: 密钥存储在过时的 trusted.gpg 密钥环中（/etc/apt/trusted.gpg），请参见 apt-key(8) 的 DEPRECATION 一节以了解详情。

解决方案： $\qquad$这是 Ubuntu 新版本（Ubuntu 20.04及以后）对密钥管理方式的改变。 Ubuntu 24.04 不再推荐使用/etc/apt/trusted.gpg，而是推荐/usr/share/keyrings/。建议按以下步骤迁移 ROS 密钥：

1. 导出原有密钥

sudo apt-key export 421C365BD9FF1F717815A3895523BAEEB01FA116 | sudo gpg --dearmour -o /usr/share/keyrings/ros-archive-keyring.gpg

如果出现以下情况：

binzz@C7VF:~$ sudo apt-key export 421C365BD9FF1F717815A3895523BAEEB01FA116 | sudo gpg --dearmour -o /usr/share/keyrings/ros-archive-keyring.gpg
Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)).
gpg: 警告：没有导出任何东西
gpg: 找不到有效的 OpenPGP 数据。

这个错误表明 apt-key export 无法正确导出密钥，可能是因为密钥已经被删除或损坏。我们可以通过以下步骤重新添加 ROS Noetic 的 GPG 密钥并修复 APT 配置： (1) 重新下载并安装 ROS Noetic 的 GPG 密钥到 /usr/share/keyrings/

curl -s https://raw.githubusercontent.com/ros/rosdistro/master/ros.asc | sudo gpg --dearmor -o /usr/share/keyrings/ros-noetic-keyring.gpg

(2) 确保你的 ros-latest.list 文件正确指向这个密钥

echo "deb [signed-by=/usr/share/keyrings/ros-noetic-keyring.gpg] http://packages.ros.org/ros/ubuntu focal main" | sudo tee /etc/apt/sources.list.d/ros-latest.list

(3) 检查密钥是否正确安装

ls /usr/share/keyrings/ | grep ros    # 检查 `/usr/share/keyrings/` 是否有密钥文件

应该在输出中能看到 ros-noetic-keyring.gpg。 (4) 更新 APT：

sudo apt update

2. 删除旧密钥，不过不建议执行这一步

sudo apt-key del 421C365BD9FF1F717815A3895523BAEEB01FA116

3. 修改 sources.list 中的 ROS 源（nano是一种文本编辑器，可以换成你喜欢的编辑器）

sudo nano /etc/apt/sources.list.d/ros-latest.list

将行改为：

deb [signed-by=/usr/share/keyrings/ros-archive-keyring.gpg] http://packages.ros.org/ros/ubuntu focal main

4. 更新软件库：

sudo apt update

没有警告和报错即可。

不能执行存在且有执行权限的shell脚本

binzz@C7VF:~$ ll pack.sh
-rwxr-xr-x 1 binzz binzz 920  6月  3 12:49 pack.sh* # 有输出，说明文件存在；x说明有执行权限
binzz@C7VF:~$ ./pack.sh
bash: ./pack.sh: 无法执行：找不到需要的文件 # 却报这个错误
binzz@C7VF:~$

原因：

1. sh文件不以#!/bin/bash开头。此时只需加上这个开头即可。
2. sh文件是在Windows下编写的。Windows的换行符是\r\n，而Linux下的换行符是\n，两者不兼容，可用dos2unix工具进行转换。

   dos2unix pack.sh

磁盘挂载类错误

Windows盘挂载错误

完成卸载，且可以正常登录其他系统。但是在 Ubuntu 24.04.2 LTS 中，发现我的E盘（/dev/nvme0n1p10）无法挂载，这是因为我的E盘在我卸载 Ubuntu 20.04.6 LTS 时，发生过移动，导致E盘的UUID（表示分区首地址）和分区末地址发生了变化。报错信息为：

Error mounting /dev/nvme0n1p10 at/media/username/2CF0A71EF0A6ECF0:	wrong fs type, bad option, bad superblock on/dev/nvme0n1p10, missing codepage or helper program, or other error (udisks-error-quark, 0)

解决方案： 首先尝试挂载E盘，比如双击任务栏上E盘对应的图标。然后运行如下命令：

username@DeviceName:~$ sudo dmesg | tail
[sudo] username 的密码： 
# 省略多条信息，只保留以下有用部分。E盘的文件系统是NTFS .
[  202.787359] ntfs3: Enabled Linux POSIX ACLs support
[  202.787363] ntfs3: Read-only LZX/Xpress compression included
[  202.787923] ntfs3: nvme0n1p10: It is recommened to use chkdsk.
[  202.806195] ntfs3: nvme0n1p10: volume is dirty and "force" flag is not set!  # 关键信息
username@DeviceName:~$ sudo ntfsfix -d /dev/nvme0n1p10
Mounting volume... OK
Processing of $MFT and $MFTMirr completed successfully.
Checking the alternate boot sector... OK
NTFS volume version is 3.1.
NTFS partition /dev/nvme0n1p10 was processed successfully.
username@DeviceName:~$

然后就可以正常挂载E盘了！

已用 + 未用 < 总量

注意到 nvme0n1p10 的灰色部分，虽然在 nvme0n1p10 内，但处于未利用的状态，在 Gparted 能识别出，但在 Windows 中不能。这是 nvme0n1p10 扩容异常的缘故。

✅ 解决方案

1. 重启进入 Windows，找到该分区。

2. 右键 → 属性 → 工具 → 查错 → 检查 → 扫描驱动器 → 修复驱动器。

3. 回到 Linux Mint，先卸载该分区：

   sudo umount /dev/nvme0n1p10

4. 检查并修复 NTFS：

   sudo ntfsresize --info /dev/nvme0n1p10  # 查看当前文件系统大小
   sudo ntfsresize /dev/nvme0n1p10        # 让文件系统扩容到分区表大小

   ntfsresize 会安全地将 NTFS 扩展到整个分区，不会丢失数据。

5. 修复后重新挂载，GParted 里的“已用+未用”就会和“大小”一致。

挂载LVM2分区错误

binzz@C7VF:~$ lsblk /dev/nvme0n1p8 -f
NAME      FSTYPE      FSVER    LABEL UUID                                   FSAVAIL FSUSE% MOUNTPOINTS
nvme0n1p8 LVM2_member LVM2 001       G80P3l-sVD1-0sT9-0xm7-23OY-C1HN-cwyEuI                
└─rl-root xfs                        d9a6d2b0-da1f-478e-858d-31fbe7917ded                  
binzz@C7VF:~$ sudo mount /dev/nvme0n1p8 /mnt/rocky/
mount: /mnt/rocky: 未知的文件系统类型“LVM2_member”.
       dmesg(1) may have more information after failed mount system call.
binzz@C7VF:~$ sudo lvscan
  ACTIVE            '/dev/rl/root' [77.29 GiB] inherit
binzz@C7VF:~$ sudo mount /dev/rl/root /mnt/rocky/
binzz@C7VF:~$ ls /mnt/rocky/
afs  bin  boot  dev  etc  home  lib  lib64  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var
binzz@C7VF:~$