如何跟踪 systemd 单元文件，具体来说，设备单元文件？我使用的是3.18版本的linux内核。在我的板上，systemd 启动后，(mypartition).device 运行，并且我想，重新挂载 rootfs，并且需要大约 2 秒才能完成，如 systemd-analyze 图所示。我想知道这 2 秒内它做了什么，因为重新挂载 rootfs 不需要太多时间（通常几毫秒）。我如何理解systemd-analyze图，有这么多单元文件，是否有可能知道哪个单元导致其他单元运行？我尝试在系统中查找 .device 单元文件，但找不到任何内容。
答案1
内核版本 3.18 于 2014 年 12 月发布，所以它已经很老了。它是长期支持内核之一，尽管该内核版本的“官方”生命周期终止于 2017 年 1 月，但仍可能收到来自 Greg Kroah-Hartman 的不定期更新。因此，该内核版本不是无论如何，这必然是任何其他操作系统组件年龄的可靠指标，尤其是在嵌入式系统上。
您的系统报告什么systemctl --version？
在现代版本的 systemd 上，文件系统安装由单元处理*.mount。具体来说，要查看根文件系统挂载单元 的内容，-.mount您需要systemctl cat -- -.mount强制将 解释-.mount为单元名称（而不是选项）。使用该命令，您应该看到挂载单元将自动After=排序依赖于表示包含根文件系统的设备的设备/目标。
这些*.device单元表现为设备被内核检测到并在/sys虚拟文件系统和udev维护的设备节点中获得其表示（如果适用，例如网络设备在没有设备节点的情况下处理）。
这些*.device单元通常都是自动生成的，因此您通常不会*.device在任何地方找到任何单元文件。相反，udev 规则可能会影响设备单元的创建：例如，如果 udev 规则设置SYSTEMD_READY=0设备的属性，则设备创建将被忽略，直到该属性被删除或更改为SYSTEMD_READY=1。请参阅man systemd.device了解更多详情。
本质上，这些*.device单元的存在是为了代表硬件设备，主要是为了其他单元能够定义它们的依赖关系。默认情况下，设备单位不依赖于任何其他单位；相反，根据定义，它们将“依赖”它们所代表的用户空间可访问设备。
您看到的 2 秒可能来自以下操作的任意组合：
- 检测和准备包含磁盘控制器的总线（如果适用于您的系统架构）
- 磁盘控制器本身的检测和重置
- 当 Linux 内核驱动程序接管对磁盘的控制时，检测并重置磁盘，以便在系统固件可能已经对其执行过任何操作后使磁盘进入已知状态（这可能需要 2 秒的大部分时间） ，因为磁盘可能有广泛的内部自检例程，它们将在重置时运行）
- 读取、识别和处理磁盘上的分区表（Linux 内核支持多种分区表格式：根据硬件架构，可能不止一种适用）