挂载失败时，内核错误码需结合 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‑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。
