挂载失败时，内核错误码需结合 dmesg 或 journalctl -k 中的 unknown-block(m,n) 和 error -x 综合分析：如 error -19 + unknown-block(0,0) 表示设备未识别，error -5 + unknown-block(179,1) 表示设备识别但读取失败；查错误码含义应执行 errno -l x，而非凭经验猜测。

挂载失败时，内核错误码不是直接“打印出来给你看”的，而是藏在 dmesg 和 journalctl -k 的上下文里，必须结合设备号、错误码数值和可用分区列表一起读——单独一个 -19 没意义，unknown-block(179,1) 才是关键线索。

怎么看 dmesg 里的挂载错误码

挂载失败后，第一反应不是翻 /etc/fstab，而是立刻执行：

dmesg | tail -30

重点找三类行：

• 以 VFS: Cannot open root device 或 mount failed 开头的主错误行，里面含 error -X
• 紧随其后的 unknown-block(M,N) —— 主设备号 M 告诉你驱动是否加载（比如 179 是 mmc，31 是 mtdblock），次设备号 N 对应具体分区
• 下方的 Please append a correct "root=" boot option; here are the available partitions: 区块，列出内核实际探测到的设备，比如 0801 12345678 sda1 [ext4]，说明 sda1 存在且类型识别正常

常见组合：error -19 + unknown-block(0,0) = 设备根本没被识别；error -5 + unknown-block(179,1) = 设备识别了但读取失败（可能文件系统损坏或只读）。

为什么 journalctl -k 比 dmesg 更可靠

dmesg 缓冲区会滚动覆盖，重启就清空；而 journalctl -k 记录的是持久化日志（只要 rsyslog 或 systemd-journald 配置正常）。排查启动期挂载失败，必须用：

journalctl -k --since "boot" | grep -A 5 -B 2 "VFS\|mount\|error"

这样能拿到完整上下文，包括：

• 内核模块加载顺序（比如 mmcblk 模块是否比 ext4 先加载）
• 设备树（Device Tree）解析结果（嵌入式场景下，sdhci@...: could not find pinctrl 会导致 unknown-block(0,0)）
• 根文件系统校验失败提示（如 EXT4-fs (mmcblk0p1): unable to read superblock）

注意：如果 journalctl -k 输出为空，说明 journald 未启用内核日志捕获，需检查 /etc/systemd/journald.conf 中 Storage= 是否为 persistent 或 volatile。

Zynq Linux Hardware Debug

Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。

下载

error -X 到底对应什么含义

内核错误码是负数，查含义不能靠猜。最准的方式是运行：

errno -l | grep "^[A-Z]" | grep -E "(^E[A-Z]+[[:space:]]+[0-9]+[[:space:]]+.*|^[0-9]+[[:space:]]+.*)"

或者直接查数值：

errno -l 19

输出：ENODEV 19 /* No such device */。关键点：

• error -19 ≠ 硬盘坏了，而是内核找不到设备节点（可能是驱动没加载、设备树没配对、U-Boot 传参错误）
• error -5（EIO）才是 I/O 层面的问题，此时要结合 dmesg 里是否有 end_request: I/O error 或 blk_update_request 日志
• error -22（EINVAL）大概率是 root= 参数格式错，比如写成 root=/dev/mmcblk0p1 但实际设备名是 mmcblk0p2，或 UUID 写错位

别依赖记忆，每次遇到新错误码都跑一遍 errno -l X。

fstab 挂载失败时怎么快速定位错误码源头

手动执行 mount -a 失败，屏幕只显示类似 mount: /mnt/data: wrong fs type, bad option, bad superblock...，这时错误码不在前台输出里。正确做法：

• 立即再跑一次 dmesg | tail -15 —— mount -a 触发的内核调用会留下痕迹
• 若看到 EXT4-fs (sdb1): bad geometry: block count 123456 exceeds size of device (98765 blocks)，说明文件系统元数据损坏，fsck 是下一步，不是改 fstab
• 若 dmesg 干净但 mount 报错，问题在用户空间（如缺少 ntfs-3g 二进制、nfs 客户端未安装），此时 journalctl -u systemd-mount@xxx.service 才是关键

真正容易被忽略的是：某些错误码（如 error -110，ETIMEDOUT）出现在 NFS 挂载时，不代表服务端宕机，而可能是客户端路由不通或防火墙丢包——这时候 dmesg 只给码，不给网络层线索，得切到 tcpdump 或 ip route get。