Ubuntu 安装、磁盘与桌面故障：先保数据的排查顺序

忽略分区警告后继续操作、强制关机、开启 root SSH、禁用更新等做法风险很高，本文不建议使用。Ubuntu 20.04 的标准安全维护也已结束；继续使用旧发行版前应先查看 Ubuntu release cycle 并明确维护来源。

Ubuntu 20.04 离线安装 Ollama（历史案例更新）

历史安装使用 ollama-linux-amd64.tgz、直接解压到 /usr、以当前登录用户运行 systemd 服务，并把“重启电脑”写成 GPU 生效的必要步骤。当前官方手工包名和服务建议已经变化，因此应按版本化流程处理：

在联网机器上从 Ollama 官方 Linux 页面或官方 Releases 获取与 CPU 架构匹配的包，记录版本、文件名、大小和发布方校验值；
把包和校验记录一起传到离线机，先本地核对，再查看归档内容，不覆盖未知旧文件；
当前官方 AMD64 手工包使用 .tar.zst，旧 .tgz 命令只适用于当时的归档格式；
先前台执行 ollama serve 并在另一终端运行 ollama -v，验证二进制、模型目录和 GPU 日志；
需要开机启动时使用专用非登录用户，而不是把个人用户名写进公开 unit。

一个最小服务骨架如下，实际二进制路径和用户必须由本机验证：

[Unit]
Description=Ollama Service
After=network-online.target

[Service]
ExecStart=/usr/bin/ollama serve
User=ollama
Group=ollama
Restart=always
RestartSec=3

[Install]
WantedBy=multi-user.target

应用配置后查看证据：

sudo systemctl daemon-reload
sudo systemctl start ollama
systemctl status ollama
journalctl -e -u ollama
nvidia-smi

GPU 没被发现时先看服务用户权限、驱动、日志和 Ollama GPU 支持说明。重启整机有时会重新加载刚安装的驱动，但不是所有 GPU 问题的必需步骤，也不是根因说明。

磁盘空间突然减少

先区分“文件占用”“已删除但仍打开”“快照/容器占用”和“挂载点失效”：

df -hT
findmnt
du -xhd1 /
sudo lsof +L1

如果某个目录位于单独文件系统，du -x 不会跨过去；这正适合先定位根文件系统本身。不要看到缓存目录大就直接递归删除，先确认它由哪个程序维护以及是否可重建。

容器环境可另外查看：

docker system df

这只是只读统计，不会自动清理。

外置盘或分区无法挂载

lsblk -f
findmnt
sudo blkid
journalctl -k -b --no-pager

要先回答：

目标设备是哪一个，型号和容量是否吻合；
文件系统是什么，是否处于只读/脏状态；
是否已经挂载在另一个位置；
日志里是权限问题、文件系统错误还是硬件 I/O 错误。

修复文件系统、改分区表、扩容根分区前必须有可验证备份。正在挂载或仍有写入的文件系统不能直接修复；图形工具里的警告也不能靠“点确定”当作处理步骤。

根分区扩容的安全清单

一个事故案例是在运行中的双系统直接打开 GParted、忽略警告，卡住后强制关机并修改 BIOS 启动项。截图和经历可以说明当时发生过什么，但不能当操作教程。真正执行前至少确认：

lsblk -f、findmnt / 与固件模式，锁定系统盘、EFI 分区和根分区；
空闲空间是否与目标分区相邻，是否有 LUKS、LVM、BitLocker 或 Windows Fast Startup；
重要数据有一份在另一物理设备上可读取的备份；
有可启动恢复介质，并验证能够进入；
调整文件系统是否支持在线扩展，移动分区是否必须离线；
笔记本接通电源，操作过程中不强制关机。

GParted 的警告需要按原文判断原因；“点击确定”不是通用步骤。完成后分别核对分区表、文件系统大小、df -hT 和引导项。

分区事故截图（仅作记录）

下列图片只用于说明一次历史事故中的界面和故障。它们不能证明目标磁盘、分区布局或警告原因与你的机器相同；不要照图忽略警告、强制关机或修改启动项。

使用 GParted 调整分区的界面

GParted 给出的启动风险警告

移动分区时的长时间操作界面

操作后进入的启动故障界面

APT 更新失败

sudo apt update
apt-cache policy PACKAGE_NAME
grep -RhsE '^[[:space:]]*deb ' /etc/apt/sources.list /etc/apt/sources.list.d/

区分：

网络/DNS/TLS 失败；
仓库不支持当前发行版；
签名密钥过期；
第三方仓库重复或失效；
包依赖冲突。

不要为了绕过签名错误关闭验证，也不要复制其他 Ubuntu 版本的软件源。第三方仓库出问题时，优先暂时禁用对应条目并查其官方迁移说明。

Open Robotics 的 EXPKEYSIG 是一个典型案例。当前做法不是从 keyserver 随便导入同一指纹或继续使用 apt-key，而是：

找到报错对应的 .list / .sources 文件；
核对仓库是否仍支持当前 Ubuntu 代号；
从仓库官方说明获取新的 keyring 包或密钥文件；
用 Signed-By 把该 key 限定到对应仓库；
再次 apt update 并查看策略来源。

禁止系统更新会让安全修复长期缺失，不作为解决依赖问题的方法。锁定科研环境应使用容器、快照、版本 pinning 或归档镜像，并明确安全维护边界。

字体安装后程序仍找不到

fc-list | grep -i FONT_FAMILY
fc-match FONT_FAMILY
fc-cache -f

Matplotlib 还可能使用自己的字体缓存。先定位缓存目录：

python - <<'PY'
import matplotlib
print(matplotlib.get_cachedir())
PY

关闭相关 Python 进程后，只清理这个已确认的缓存目录，再重新运行。字体文件还应确认授权范围，来源不明的字体不随博客提供下载。

不需要全系统安装时，优先放入当前用户字体目录：

mkdir -p ~/.local/share/fonts/research
install -m 0644 FONT_FILE.ttf ~/.local/share/fonts/research/
fc-cache -f
fc-match "FONT_FAMILY"

FONT_FILE.ttf 和 FONT_FAMILY 是占位符。来源不明的 SimHei 下载站点没有可靠的授权与校验信息，因此本文不提供链接；Noto CJK 等字体应从发行版仓库或项目正式发布页获取。

Typora 的主题 CSS 还可能覆盖系统字体。旧案例是在主题的 font-family 中加入 "Noto Sans CJK SC"。修改前复制主题文件，并在应用更新后检查自定义主题是否仍生效；不要编辑应用安装目录中的默认文件。

旧版主题文件中的字体设置截图也保留下来，供辨认 CSS 位置；实际文件名和选择器应以当前主题为准：

Typora 主题 CSS 中的 Noto Sans CJK SC 字体设置

SSH 连接超时

客户端：

ssh -vvv -p SSH_PORT USER_NAME@SERVER_HOST

服务器本地：

systemctl status ssh
ss -lntp
sudo ufw status verbose
journalctl -u ssh --since today

依次确认 DNS/IP、路由、端口监听、防火墙和认证。连接超时通常发生在到达认证之前，修改密码或开启 root 登录并不能解决。公网主机优先使用普通用户和公钥认证。

桌面快捷键与输入法冲突

某个快捷键失效时，先在以下位置检查重复绑定：

桌面环境的键盘快捷键；
输入法框架的全局快捷键；
当前应用的快捷键；
浏览器或编辑器扩展。

这比替换应用文件或重装桌面环境更容易验证和回滚。

旧案例是 Typora 的五级标题快捷键 Ctrl+F5 被 Fcitx 的“重新载入配置”占用。可以打开 Fcitx 配置、显示高级选项，搜索这个全局绑定并改成不冲突的键；修改前记下原值。这个案例保留的是定位方法，不保证所有 Fcitx/Fcitx5 版本菜单相同。

以下三张旧版 Fcitx 截图依次展示搜索配置、打开高级选项和清空冲突绑定的位置。当前发行版如果使用 Fcitx5，应以它自己的配置工具为准。

在旧版 Fcitx 配置中搜索快捷键

旧版 Fcitx 高级配置界面

Vim swap 文件

出现 Swap file ... already exists 时，不要立即删除 .swp。先确认是否还有另一个 Vim 进程正在编辑同一文件，并阅读提示中的进程、主机、时间和文件路径。需要恢复时可在副本上尝试：

vim -r PATH_TO_FILE

保存恢复内容并确认没有活跃编辑进程后，才处理遗留 swap。多人共享目录中还要核对文件所有者。

U 盘变为只读

先确认只读来自挂载选项、文件系统错误、硬件写保护还是设备 I/O 故障：

lsblk -f
findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS
journalctl -k -b --no-pager

内核因文件系统错误改为只读时，强行 remount,rw 可能继续破坏数据。先停止写入、备份仍可读的数据，再在卸载状态按文件系统类型检查；不要对未确认的设备运行修复或格式化命令。

远程桌面

先明确使用的是 GNOME Remote Desktop、xrdp、VNC 还是 SSH X11 转发。它们的会话、端口和显示服务器不同，不能把某一套图形界面设置当作 xrdp 的必需步骤。

systemctl status xrdp
ss -lntp
journalctl -u xrdp -b

在公网开放远程桌面前，应通过 VPN、SSH 隧道或严格来源地址控制访问范围，而不是只设置一个登录密码。

“安装 xrdp”和 GNOME Settings 中的 Screen Sharing 是不同服务，不应混在同一个流程里：

GNOME Remote Desktop/Remote Login 由桌面设置和用户会话管理；
xrdp 是独立 RDP 服务，常创建不同的图形会话；
VNC 又使用另一套协议和会话模型。

下图保留的是旧版 GNOME Screen Sharing 的设置入口，只用于说明它与 xrdp 不属于同一套服务；截图中被遮蔽的凭据不作为配置示例：

旧版 GNOME Screen Sharing 设置入口

如果选择 xrdp，安装后至少核对包来源、服务日志、监听地址、TLS 配置、会话类型和本地已登录会话的冲突。不要因为服务显示 active 就直接在公网放行 3389。

软件安装与卸载

apt-cache policy PACKAGE_NAME
sudo apt install PACKAGE_NAME
sudo apt remove PACKAGE_NAME

purge 会连同系统级配置一并删除，只有确认这些配置无需保留时再用。Snap、Flatpak、APT 和手工安装是不同来源，排查时先定位可执行文件：

command -v PROGRAM_NAME
readlink -f "$(command -v PROGRAM_NAME)"

查看系统中不同来源的软件：

dpkg -l
snap list

这两条仍不能涵盖 Flatpak、AppImage、源码安装和容器，所以定位问题时以实际可执行文件和包管理记录为准。

视频提示缺少 H.264 解码器时，VLC 或 mpv 自带/依赖的解码能力常能解决播放问题，但软件包可用性和专利许可随发行版与地区变化。先从发行版仓库安装播放器，不从“解码器下载站”获取二进制。

使用 useradd 后没有主目录，是因为低级命令不会在所有配置下默认创建。新建普通用户时明确使用发行版推荐工具，或在确认用户名、UID、组和 home 路径后使用 useradd -m；不要事后把别人的 home 递归改属主。

双系统默认启动项

安全做法是先记录当前固件与 GRUB 状态，不直接按第三方教程的菜单序号硬编码：

sudo efibootmgr -v
grep -E '^GRUB_DEFAULT|^GRUB_SAVEDEFAULT' /etc/default/grub
grep -n "^menuentry '" /boot/grub/grub.cfg

GRUB 菜单序号会随内核和探测结果变化。需要默认进入 Windows 时，优先使用发行版支持的 saved entry/命名条目流程，并在修改 /etc/default/grub 前备份；生成配置后保留可启动恢复方式。UEFI 启动顺序和 GRUB 默认菜单是不同层，不应同时盲改。

本文不提供的高风险操作

未确认目标磁盘、可验证备份与恢复介质的高风险分区操作；
没有启动介质和备份就在线调整根分区；
root SSH、弱密码、禁用系统更新；
过时的 Ollama 手工 service 配置，相关安装与服务管理以当前官方流程为准；
未核验授权的字体下载；
把特定 Ubuntu 18.04/20.04 界面路径写成当前通用结论。

参考资料与书签

以下 30 条作为补充检索入口。涉及无启动介质扩分区、强制关机、关闭错误报告或系统更新、放宽密码策略、开启 root SSH 的教程均属高风险资料，不能直接照抄；应先准备可验证备份、恢复介质，并查当前发行版官方文档。

本文不提供非官方 SimHei 字体直链。该来源没有足够的授权、校验和维护信息，属于未知字体下载，而不是普通参考文章。