systemd-analyze time 仅统计 systemd 接管后的三阶段耗时，不含 BIOS/UEFI、GRUB、内核解压等前置时间；kernel 阶段超 1s 查固件设置与驱动，initrd 高耗时查加密/LVM 配置，userspace 占比超 80% 则需用 blame --all 定位慢服务及挂载单元。
systemd-analyze time 显示三阶段耗时不准？
直接运行 systemd-analyze time 得到的数值，是 systemd 从自身接管控制权开始计时的，并不包含 BIOS/UEFI 自检、GRUB 菜单停留、内核解压等前置时间。所以它反映的是“可测量的启动链”起点，不是整机通电到登录界面的全程。
输出中三个字段含义必须分清：kernel 是从内核第一条指令执行到 init 进程被创建的时间；initrd 只在启用 initramfs 时出现，含加密卷解锁、LVM 扫描等动作；userspace 才是 systemd 加载所有 unit 的总耗时——这个值最值得盯紧。
- 如果
kernel阶段 > 1s，优先检查 BIOS/UEFI 设置（如 Fast Boot 是否开启）、NVMe 驱动是否内置、Secure Boot 是否引发额外验证 -
initrd耗时高，重点查/etc/crypttab中密码提示方式、rd.md=0 rd.lvm=0等内核参数是否误禁用了必要模块 -
userspace占比超 80%，说明问题在服务层，下一步必须用blame
systemd-analyze blame 排查慢服务时漏掉 mount 单元？
systemd-analyze blame 默认只显示已成功激活（active）的 unit，但挂载失败或卡在 activating (start) 状态的 .mount 单元不会出现在列表里——它们会拖慢整个关键路径，却隐身了。
真正要抓全，得加两个参数：systemd-analyze blame --no-pager --all。其中 --all 强制列出所有已加载 unit（包括 failed 和 activating 状态），--no-pager 避免因终端宽度截断长服务名（比如带 UUID 的 dev-disk-by\x2duuid-xxx.mount）。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 重点关注耗时 > 500ms 的
.mount单元：它们往往对应/etc/fstab中配置了但设备不可达的条目（如拔掉的 USB 盘、未挂载的 NFS 服务器） - 看到
NetworkManager-wait-online.service耗时高，别急着禁用——先用journalctl -u NetworkManager-wait-online.service -b看日志，大概率是 DHCP 超时或 IPv6 RA 等待卡住 - 第三方服务（如
docker.service、prometheus-node-exporter.service）若耗时突增，用systemctl show -p ExecMainPID <code>service-name查 PID，再结合strace -p <code>PID看卡在哪个系统调用上
critical-chain 显示的“瓶颈”其实可以绕过？
systemd-analyze critical-chain 输出的是依赖树中最长的一条串行链，但它不等于“必须优化的点”。有些 unit 处于关键路径上，只是因为设计如此（比如 multi-user.target 依赖 network.target，而后者又依赖 NetworkManager.service），并非性能缺陷。
判断是否真瓶颈，要看两点：一是该 unit 自身耗时是否异常（对比 blame 结果）；二是它是否真的被下游服务强依赖。例如 getty@tty1.service 出现在关键链末端，但除非你必须秒级登录，否则它不影响业务就绪时间。
- 若发现某个服务（如
cloud-init.service）长期霸占关键链头部，且耗时稳定在 3~4s，大概率是云平台元数据服务响应慢，可考虑在/etc/cloud/cloud.cfg.d/99-disable.cfg中设disable_root: true并关掉非必要模块 - 想临时跳过某环节？不要直接
systemctl disable，而是改 unit 文件，在[Unit]段加Wants=替代After=，或用systemctl mask彻底切断依赖（慎用） -
critical-chain不显示并行启动的服务，所以总耗时永远 ≤ 最长链耗时 —— 这也是为什么优化单个服务未必缩短整体启动时间
plot 生成的 SVG 图打不开或报错？
systemd-analyze plot > boot-time.svg 生成的图本质是 XML 格式 SVG，浏览器能打开，但部分旧版 Chrome 或 Firefox 会因安全策略拒绝加载本地文件中的脚本（SVG 内嵌 JS）。这不是生成失败，是渲染限制。
更可靠的方式是用 systemd-analyze dot | dot -Tpng -o boot-time.png 转成 PNG——前提是系统装了 graphviz。CentOS/RHEL 需 yum install graphviz，Ubuntu/Debian 用 apt install graphviz。
- 图中横向色块越长，代表该 unit 启动越慢；色块重叠越多，说明并行度越高；空隙越大，说明等待依赖越久
- 如果发现大量服务在某个时间点后才开始启动（比如 8s 后突然密集出现），说明前面有个隐形的同步点（如
local-fs.target或自定义 target）卡住了 - 注意：图中显示的耗时是相对时间（从 systemd 启动开始），和
time命令的绝对值一致，但和blame的倒序排列逻辑不同——plot更适合看并发关系，而非排序找“最慢”
time 定范围、blame 锁目标、critical-chain 看依赖、plot 验并发，四者缺一不可。最容易被忽略的是：很多“慢启动”根本不是 systemd 层面的问题，而是硬件响应（如 SATA Link Down 重试）、固件 Bug（某些 Intel RST RAID 卡在 initrd 阶段死等）、甚至 BIOS 电池没电导致 CMOS 时间回滚触发证书校验延迟——这些在任何 systemd-analyze 输出里都不会体现。 
