最可靠方式是用 sudo dmidecode -t baseboard 查 serial number 字段，因其直接读取 smbios base board 类型条目，字段语义明确、结构稳定；若返回 none 或 to be filled by o.e.m.，说明 bios 未填写，非命令或权限问题。
最可靠的方式是用 sudo dmidecode -t baseboard 查 Serial Number 字段；若为空，不是命令错了，而是 BIOS 根本没填——换别的命令也拿不到。
为什么 dmidecode -t baseboard 是首选
它直接读取 SMBIOS 表中 Base Board 类型条目，字段语义明确、结构稳定：Manufacturer 是主板品牌，Product Name 是型号，Serial Number 才是你要的主板序列号（注意：和 dmidecode -t system 里的 Serial Number 可能不同，OEM 常设为一致但不保证）。
必须加 sudo，否则报 Permission denied；别省略 -t baseboard，用模糊 grep "Serial Number" 容易混入内存、机箱等其他设备的序列号。
常见错误现象：
- 执行
dmidecode -t baseboard被拒绝 → 忘加sudo - 输出里有多个
Serial Number→ 没限定类型，grep 范围太宽 - 返回
Serial Number: None或To be filled by O.E.M.→ BIOS 固件未写入，非权限或命令问题
/sys/class/dmi/id/board_serial 免 root 但不可靠
内核把部分 DMI 数据映射成只读文件，适合脚本轻量调用，但存在性与权限不统一：
- 先试：
cat /sys/class/dmi/id/board_serial 2>/dev/null，成功就直接拿到值 - 若报
Permission denied，说明系统做了安全加固（如 Ubuntu 22.04+ 默认禁用），得切回sudo dmidecode - 该路径在容器、最小化系统或某些云主机中可能根本不存在，
ls /sys/class/dmi/id/看有没有这个文件再决定是否尝试
注意：/sys/class/dmi/id/product_serial 和 /sys/devices/virtual/dmi/id/product_serial 是系统级序列号，不是主板序列号，别混淆。
用 lshw -class motherboard 交叉验证更稳妥
当 dmidecode 输出混乱、字段错位，或怀疑 BIOS 填错时，lshw 会融合 DMI + PCI + sysfs 多源数据，对 Dell/HP/Supermicro 等 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、cat /sys/block/sda/device/serial 这些完全不碰 DMI/SMBIOS：
-
lsblk只展示块设备拓扑，输出里没有serial、model或vendor字段 -
free和/proc/meminfo只统计逻辑内存总量，不含插槽位置、DIMM 型号、序列号等物理属性 -
/sys/block/sda/device/serial存的是硬盘序列号，不是主板的
云主机或虚拟机环境下，dmidecode 返回的 Serial Number 往往是占位符（None、To be filled by O.E.M.），真实资产信息得走云平台元数据接口，硬查 DMI 没意义。
真正容易被忽略的是：主板序列号不是系统生成的，它来自 BIOS/UEFI 固件里的 SMBIOS 表；查不到，99% 是厂商出厂时根本没填，不是你漏了哪个参数或路径。
