系统维护 on Breaking Dawn

Ubuntu 忘记密码后的恢复：优先重设用户密码，不启用 root

Tue, 21 Jul 2026 10:15:00 +0800

仅限授权设备：以下步骤适用于自己拥有或明确获授权维护的电脑。能够接触设备和 GRUB 菜单的人可能获得本地管理员权限；请同时保护好物理设备和磁盘加密密钥。

Ubuntu 默认把 root 账户锁定，日常管理通过普通用户加 sudo 完成。忘记登录密码时，通常只需要重设自己的用户密码，没有必要长期启用 root。

通过恢复模式重设密码

开机时进入 GRUB；如菜单被隐藏，可在开机阶段按住 Shift（传统 BIOS）或反复按 Esc（常见 UEFI）尝试显示菜单。
选择 Advanced options for Ubuntu，再选择带有 (recovery mode) 的内核。
在恢复菜单中选择 root – Drop to root shell prompt。
将根文件系统重新挂载为可写，然后为目标用户设置新密码：

1
2
3
4


mount -o remount,rw /
passwd 用户名
sync
reboot

把 用户名 替换为实际 Linux 用户名；它通常不是 Windows 账户邮箱。若不确定，可在恢复 shell 中查看 /home 下的目录名。

BitLocker 与磁盘加密提醒

此操作不应修改 Windows 分区。若 Ubuntu 使用全盘加密，系统会先要求解锁磁盘；如果忘记的是磁盘解锁口令而非登录密码，恢复路径不同，不能通过简单的 passwd 解决。

完成恢复后，请检查是否仍有不需要的管理员账户，并为重要数据保留离线备份。

出处

原始参考：如何在 Ubuntu 上重置 Root 密码（系统极客）
官方参考：Ubuntu Community Help Wiki：LostPassword

本文将“重置 root”调整为 Ubuntu 更推荐的普通用户密码恢复方式。

Ubuntu 内核更新与固定版本：先保留回退，再考虑 hold

Tue, 21 Jul 2026 10:05:00 +0800

安全提示：内核更新也包含安全修复。除非某个已确认的驱动 / 硬件回归正在影响使用，不建议长期冻结内核；应记录原因与恢复日期。

Ubuntu 通常会保留一个或多个旧内核，这正是遇到新内核与 NVIDIA、VirtualBox 等 DKMS 模块不兼容时最好的回退手段。第一选择应是从 GRUB 的“Advanced options for Ubuntu”启动上一个可用内核，而不是马上阻止所有升级。

先确认当前状态

1
2
3


uname -r
dpkg -l 'linux-image*' | grep '^ii'
apt-cache policy linux-generic linux-image-generic linux-headers-generic

记录可正常使用的内核版本、显卡驱动版本和故障表现。待问题解决并在新内核上验证后，再清理旧内核；不要删除当前正在运行的版本。

需要短期暂停更新时

Ubuntu 的内核通常由元包推进。下面只是在问题排查期间暂停元包更新；包名需以本机 apt-cache policy 输出为准：

1
2


sudo apt-mark hold linux-generic linux-image-generic linux-headers-generic
apt-mark showhold

恢复更新：

1
2
3


sudo apt-mark unhold linux-generic linux-image-generic linux-headers-generic
sudo apt update
sudo apt upgrade

固定单个、已安装的版本包，往往不能阻止元包引入新版本；反过来，冻结元包又会连带停止内核安全更新。因此应该把 hold 当作短期隔离措施，而不是永久配置。

出处

原始参考：Ubuntu 锁定内核不让它升级（RayChiu，CSDN）
原始参考：Ubuntu 固定内核版本（checknet，CSDN）
命令参考：APT apt-mark 手册

本文合并两篇原始资料，并补充了 Ubuntu 22.04 的内核元包和安全更新风险。

Linux 磁盘空间排查：正确使用 df、du 与大文件定位

Tue, 21 Jul 2026 09:15:00 +0800

适用环境：Ubuntu 22.04 LTS。执行清理操作前，请先确认路径和数据归属；不要因空间不足而直接删除不认识的系统目录。

df 看的是文件系统剩余空间，du 看的是目录内容占用。两者结合，能快速判断是哪个分区满了、又是哪个目录导致的。

第一步：确认哪个分区满了

1

df -hT

关注挂载点为 /、/home、/boot 的行。Use% 接近 100% 时，先不要升级系统或安装大型软件包；这可能让包管理操作中断。

第二步：从大目录逐层缩小

1
2


sudo du -xhd1 / | sort -h
du -xhd1 "$HOME" | sort -h

-x 让 du 不跨越到其他挂载点，避免把 Windows NTFS 分区、移动硬盘等内容混在统计里。通常先检查 /var、/home、/usr；在 /var 下，日志、软件包缓存和容器数据经常占用较多空间。

继续深入某个目录时，替换路径即可：

1

sudo du -xhd1 /var | sort -h

第三步：定位异常大文件

1

sudo find /var -xdev -type f -size +1G -printf '%10s %p\n' | sort -n

看到大文件后，先判断它是否为日志、下载缓存、虚拟机磁盘或数据库文件。对日志可使用 journalctl --disk-usage 查看 systemd 日志占用；不要直接删除正在写入的日志文件。

一个容易忽略的差异

若 df 显示空间已满而 du 找不到对应内容，可能是进程仍打开着一个“已删除文件”。可用下面命令排查：

1

sudo lsof +L1

确认对应服务后，以正常方式重启服务或系统，才会释放这部分空间。

出处

原始参考：Linux 查看磁盘空间命令（df、du）（jadeandplum，CSDN）
手册参考：GNU Coreutils: df invocation

本文将原始命令按“整体—目录—文件—异常占用”的排查顺序重新组织。

Ubuntu 中 dpkg 返回错误代码 1：从检查到修复

Tue, 21 Jul 2026 09:00:00 +0800

适用环境：Ubuntu 22.04 LTS。本文只处理 apt / dpkg 的软件包状态问题，不适用于磁盘损坏或系统无法启动的情形。

E: Sub-process /usr/bin/dpkg returned an error code (1) 不是一个单独的故障原因，而是安装流程最后给出的概括性结果。真正的线索通常出现在它之前：可能是某个包的配置脚本失败、依赖缺失、磁盘空间耗尽，或安装被中断。

先找到真正报错的包

先重新执行一次，并保留完整输出；重点看最后一个出现 error processing package 或 post-installation script 的包名。

1
2
3


sudo apt update
sudo apt install -f
sudo dpkg --configure -a

这三个命令依次更新软件包索引、修复可满足的依赖、继续完成尚未配置的包。大多数“错误代码 1”到这里就能恢复。

仍失败时的排查顺序

查看可用空间：df -h；/ 或 /var 写满会导致配置脚本失败。
查看最近的包管理日志：sudo tail -n 120 /var/log/dpkg.log。
用前面找到的包名重新安装：sudo apt install --reinstall 包名。
只有确认该包可以移除且没有关键依赖时，才考虑 sudo apt remove 包名 后再安装。

不要把删除 /var/lib/dpkg/info 当作常规修复方式。该目录保存已安装软件包的维护脚本与元数据；直接改动前必须有备份，并应先确认是元数据损坏而非某个具体包的配置错误。

修复后的确认

1
2
3


sudo apt -f install
sudo dpkg --audit
sudo apt upgrade

若 dpkg --audit 没有输出未完成的软件包，说明包管理状态已恢复。对驱动、内核、引导加载器等重要组件，建议在重启前确认没有待处理的错误。

出处

原始参考：解决 apt-get 安装中的 dpkg error code (1)（焦距，博客园）

本文为基于原始参考重新编排的排障笔记；命令应以当前终端输出为准。