Linux启动慢需先区分内核（0.000000至“Freeing init memory”）与用户空间（init/systemd阶段）瓶颈；用bootgraph.py分析内核日志生成bootgraph.html，再用bootchartd+pybootchart.py分析用户空间bootlog.tgz，缺一不可。
启动慢？先确认瓶颈在内核还是用户空间
Linux启动性能问题必须分两段排查：内核初始化阶段（从 0.000000 timestamp 到 Freeing init memory）和用户空间阶段（init 或 systemd 启动服务）。直接调参数不看日志，90%会白忙。用 bootgraph.py 解析 /var/log/kern.log 或 dmesg 输出的内核日志，生成 bootgraph.html；再用 bootchartd 抓取用户空间数据打包为 bootlog.tgz，用 pybootchart.py 可视化——这两步漏掉任何一环，优化就是拍脑袋。
内核启动阶段：关键参数与风险点
真正能动的内核级启动参数极少，且多数需编译时启用，运行时仅能微调。重点盯住两个开关：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
-
initcall_debug=1：必须在内核命令行（/etc/default/grub中GRUB_CMDLINE_LINUX）添加，否则bootgraph.py无法提取每个initcall的耗时。没这个，你根本不知道哪个驱动或子系统卡住了。 -
CONFIG_LOG_BUF_SHIFT：决定内核 log buffer 大小。默认值常导致早期启动日志被覆盖。若发现dmesg开头缺失，说明 buffer 溢出，需在内核配置中调高（如设为18，即 256KB），重新编译内核。 - 慎用
quiet splash：虽然让屏幕干净，但会屏蔽关键 early-init 日志。调试阶段务必删掉。
用户空间启动：systemd 服务并行与延迟控制
绝大多数“启动慢”实际卡在 systemd 服务依赖链上。不是加参数，而是改行为：
- 查慢服务：
systemd-analyze blame直接列出各服务启动耗时，systemd-analyze critical-chain显示最长依赖路径。 - 禁用非必要服务：
systemctl disable bluetooth.service ModemManager.service，别只停 enable 状态，要mask彻底屏蔽（systemctl mask xxx）。 - 调整服务启动时机：对非核心服务（如
docker.service），在 unit 文件里加WantedBy=multi-user.target替代default.target，避免挤占早期启动窗口。 - 禁用 fsck：若根文件系统是
ext4且已启用日志，可在/etc/fstab对应行加pass 0，跳过启动时磁盘检查。
容易被忽略的硬件层影响
参数调得再细，硬件拖后腿也白搭。三个硬性检查点：
- BIOS/UEFI 中关闭
Secure Boot和Fast Boot—— 前者可能触发模块签名验证延迟，后者常导致 PCIe 设备枚举异常，反而更慢。 - SSD 固件版本过旧会导致 AHCI 初始化卡顿，尤其 NVMe 盘。用
sudo nvme list查型号，去厂商官网核对固件更新状态。 - USB 设备（尤其是带 hub 的键鼠、打印机）在内核 probe 阶段可能超时重试，拔掉所有非必要 USB 设备再测启动时间，差值超过 2 秒就得查
dmesg | grep -i usb是否有 timeout 报错。
