为了使用ifupdown管理网络。我删除了NetworkManager与libnm0，特别是删除libnm0后，发现系统进不去了，一直卡在：
a start job is running for Hold until boot process finishes up
学习了使用ubuntu制作救援USB，使用try ubuntu模式进行救援。
====》 介绍了TryUbuntu作为一个轻量级的Ubuntu救援环境，如何通过制作U盘启动进行系统修复
也就是：Ubuntu Live USB：
Ubuntu Live USB 和 “Try Ubuntu” 本质上是同一概念的不同表述，两者均指通过 USB 启动盘在不安装系统的情况下体验 Ubuntu 系统。不过，从使用场景和细节来看，它们的侧重点略有不同，以下是具体区别：
一、核心定义与本质
本质相同：
两者均基于 Ubuntu 的 Live CD/USB 技术，即通过启动盘加载系统到内存运行，无需安装到硬盘。用户可在该环境中体验系统功能、测试硬件兼容性或进行系统修复。
名称差异的来源：
- “Ubuntu Live USB” 强调介质形式（USB 驱动器）和运行方式（Live 模式）。
- “Try Ubuntu” 更侧重用户体验场景（“尝试” 系统功能），常见于 Ubuntu 官方引导语（如安装界面中的 “Try Ubuntu without installing”）。
救援过程中，chroot前为什么要mount这些，且用–bind参数？
sudo mount /dev/sdb3 /mnt
sudo mount --bind /dev /mnt/dev
sudo mount --bind /proc /mnt/proc
sudo mount --bind /sys /mnt/sys
sudo mount /dev/sdb2 /mnt/home
sudo chroot /mnt
为什么chroot之前要做这些mount？
在使用chroot命令进入目标系统环境前，需要执行一系列mount操作，这是因为chroot 环境需要一个完整的文件系统视图，而这些挂载操作的核心目的是为目标系统提供必要的运行依赖和资源访问权限。以下是具体原理解析：
一、chroot 的本质与限制
chroot命令会将指定目录（如/mnt）作为新的 “根目录”，使后续命令在该目录下的文件系统中运行。但默认情况下，chroot 环境是隔离且不完整的，缺少：
- 硬件设备访问（如/dev目录）
- 系统运行时信息（如/proc、/sys）
- 其他分区的文件系统（如/home、/usr）
因此，需要手动挂载这些关键目录，确保目标系统能正常运行命令（如apt）、访问硬件和文件资源。
二、各 mount 操作的具体作用
- sudo mount /dev/sdb3 /mnt
作用：将物理分区（/dev/sdb3）挂载到/mnt，作为 chroot 的根目录。
示例场景：假设/dev/sdb3是目标系统的根分区（/），挂载后/mnt即成为 chroot 环境的根目录。 - sudo mount --bind /dev /mnt/dev
作用：将当前系统的/dev目录 “绑定挂载” 到 chroot 环境的/mnt/dev。
核心原因：
dev目录存储硬件设备文件（如硬盘、键盘、网络接口），目标系统需要通过这些文件访问硬件。
例如，apt安装软件时可能需要访问磁盘设备，或bash需要读取键盘输入。 - sudo mount --bind /proc /mnt/proc
作用：绑定挂载/proc文件系统到 chroot 环境。
核心原因：
proc是虚拟文件系统，存储系统运行时信息（如进程列表、CPU 使用情况）。
目标系统的命令（如ps、top）需要读取proc中的数据，apt可能依赖系统资源信息。 - sudo mount --bind /sys /mnt/sys
作用：绑定挂载/sys文件系统到 chroot 环境。
核心原因：
sys存储硬件设备和内核参数的动态信息（如设备驱动状态）。
目标系统的硬件相关工具（如网络配置工具）需要访问sys中的设备信息。
三、为什么必须按顺序执行？
先挂载根分区：/mnt必须先作为目标系统的根目录存在，后续操作才能基于此展开。
后挂载设备与虚拟文件系统：这些依赖项需要基于已存在的根目录进行绑定。
最后挂载其他分区：如/home，确保目标系统能访问完整的文件系统结构。
四、典型错误案例
未挂载 /dev：执行chroot后运行bash会报错failed to run command /bin/bash，因为无法访问终端设备。
未挂载 /proc/sys：执行apt update会报错Error reading the cpu table，因为无法获取系统硬件信息。
未挂载 /usr（若为独立分区）：apt命令本身可能无法找到（因/usr/bin/apt在独立分区中未挂载）。
五、总结：chroot 环境的 “最小完整集”
执行 chroot 前，至少需要挂载以下内容：
- 目标系统的根分区（如/dev/sdb3挂载到/mnt）
- dev目录（提供硬件访问）
- proc文件系统（提供系统运行信息）
- sys文件系统（提供硬件和内核参数）
如果目标系统有独立分区（如/usr、/home），也需要手动挂载，否则相关目录在 chroot 环境中会是空的，导致命令执行失败（如apt无法找到/usr/bin下的程序）。
通过这些挂载操作，chroot 环境才能模拟一个完整的系统运行环境，允许用户像在真实系统中一样执行修复命令。
为什么要加bind？
在 chroot 前使用–bind参数（如sudo mount --bind /dev /mnt/dev），本质是为了在 chroot 环境中复用当前系统的关键目录，而不是创建独立的文件系统。以下是具体原理解析：
一、bind 挂载的核心作用：跨文件系统共享目录
mount --bind是一种特殊的挂载方式，它的作用是：
将一个已存在的目录（源目录）映射到另一个目录（目标目录），使两者共享相同的文件内容。
例如：
当前系统的/dev目录存储着硬件设备文件（如/dev/sda、/dev/console）。
通过mount --bind /dev /mnt/dev，chroot 环境的/mnt/dev会直接指向当前系统的/dev，而非重新创建一个空目录。
有一个坑是我之前装系统的时候参照了这篇博客：https://blog.csdn.net/qq_44634577/article/details/106603590
做了三个分区：home分区，根分区，usr分区（源下载的执行文件，配置等会放在这里面）
还有一种做法是直接一个根分区（公司里貌似就是这种？）
导致chroot的时候，比如根分区挂载到了/mnt，那么需要把usr分区也挂载到/mnt/usr，因为根分区中的bin, lib等目录都是软链接，指向usr目录下的子目录。
这样chroot进入后再apt install安装，就是装在正确的usr路径中。
ok，到这为止我以为把libnm0装回来应该就好了，结果依然不行，没有任何变化。
实在不行只能重装系统了。。。
2025.6.28 9.40
早上一起来开始又查了一下
https://blog.csdn.net/qq_25562325/article/details/125282432
按照这个文章的方法可以进入系统，查看报错日志。（此时没有了图形界面，猜测是这里出了问题）
quiet - 这个选项告诉内核不要产生任何输出（也称为非详细模式）。如果你不使用这个选项启动，你会看到很多内核消息，比如驱动程序/模块的激活、文件系统的检查和错误。没有quiet参数可能在你需要找到错误时有用。 - splash - 这个选项用于在后台加载系统的核心部分时启动一个漂亮的“加载”屏幕。
当系统启动不显示grub的时候，可以从一开始就按住shift来进入grub界面
journalctl发现lightdm服务启动报错
切换为gdm3后正常了。
切换命令：
sudo dpkg-reconfigure gdm3
会弹出切换窗口。
注意NetworkManager的包名是：network-manager