最可靠方式是用 root 权限运行 sudo dmidecode -t baseboard 查 Serial Number 字段；若为空或 None，说明 BIOS 未填写，非命令错误，此时可尝试 /sys/class/dmi/id/board_serial（免 root 但不一定存在）或 sudo lshw -class motherboard 交叉验证。
主板序列号不是系统生成的，它来自 BIOS/UEFI 固件里的 SMBIOS 表，查不到多半是厂商没填，不是你命令写错了。
查主板序列号优先用 dmidecode -t baseboard
这是最直接的方式，读取 SMBIOS 中 Base Board 类型条目，字段真实、结构清晰：
-
Serial Number字段才是你要的主板序列号（注意：和dmidecode -t system里的 Serial Number 可能不同，OEM 常设为一致，但不保证） - 输出里
Manufacturer和Product Name是主板品牌与型号，Version是 PCB 版本号 - 必须加
sudo，否则报Permission denied；别省略-t baseboard，用模糊 grep 容易混入其他设备的 Serial Number - 如果返回
Serial Number: None或To be filled by O.E.M.，说明固件根本没写——换别的命令也白搭
/sys/class/dmi/id/board_serial 免 root 但不一定可用
内核把部分 DMI 数据映射成只读文件，适合脚本轻量调用，但权限和存在性不统一：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 先试：
cat /sys/class/dmi/id/board_serial 2>/dev/null，成功就直接拿到值 - 若报
Permission denied，说明系统做了安全加固（如 Ubuntu 22.04+ 默认禁用），得切回sudo dmidecode - 该路径在容器或最小化系统中可能根本不存在，
ls /sys/class/dmi/id/看有没有board_serial这个文件再决定是否尝试
用 lshw -class motherboard 交叉验证更稳妥
当 dmidecode 输出混乱或怀疑 BIOS 填错时，lshw 会融合 DMI + PCI + sysfs 多源数据，对 Dell/HP 等 OEM 设备识别更准：
- 安装后运行：
sudo lshw -class motherboard | grep -E "product:|vendor:|serial:" - 注意字段名是
serial:（冒号后带空格），不是Serial Number: - 如果
dmidecode显示空序列号但lshw有值，大概率是 BIOS 没填全，而 OEM 在其他固件区（如 ACPI）补了信息 - 某些 Supermicro 主板启用 ECC 后，
dmidecode -t memory会错位，此时lshw -class memory的输出反而更可信
别信 lsblk 或 free 查主板信息
这两个命令完全不碰 DMI/SMBIOS，查不到任何主板级标识：
-
lsblk只展示块设备拓扑，输出里没有serial、model或vendor字段 -
free和/proc/meminfo只统计逻辑内存总量，不包含插槽位置、DIMM 型号、序列号等物理属性 - 试图从
/sys/block/sda/device/serial读主板序列号？这个路径存的是硬盘序列号，且很多 NVMe/SATA 设备压根不暴露该文件
真正麻烦的不是命令怎么写，而是 BIOS 里根本没填——尤其消费级主板和虚拟机。查之前先确认场景：物理服务器看 dmidecode -t baseboard，OEM 整机再加 lshw 对比，容器或加固系统优先试 /sys/class/dmi/id/board_serial，别在错误路径上浪费时间。
