3、主机系统要求：Ubuntu版本选择、内核要求、磁盘分区与网络配置建议
BM1684作为算能科技推出的AI推理芯片，其环境搭建的第一步并非安装驱动或拉取镜像，而是确保宿主机操作系统满足底层兼容性要求。很多开发者在后续步骤中遇到“设备节点不出现”“Docker容器无法映射算力”或“PCIe链路不稳定”等问题，根源往往可以追溯到主机系统的版本、内核或分区配置不当。本章将围绕Ubuntu版本选择、内核要求、磁盘分区与网络配置四个维度展开，帮助你在开始安装前就构建一个稳固的宿主环境。
上图展示了主机系统配置的完整决策链路。在实际工程中，版本、内核、磁盘和网络四个要素相互影响，例如旧内核可能无法识别新硬件，而分区不足则会导致Docker镜像撑爆根目录。下面逐一展开说明。
3.1 Ubuntu版本选择：LTS优先，兼容性为王
核心原理：BM1684的驱动（如bmnnsdk2）和运行时库（libbm1684）在编译时依赖特定的glibc版本和内核头文件。Ubuntu LTS版本提供长达5年的安全更新和稳定的ABI接口，是官方支持的首选。非LTS版本（如21.10、23.04）虽然内核较新，但可能引入不兼容的库变更，导致驱动模块编译失败。
判断方法：打开终端执行 lsb_release -a 查看当前版本。推荐选择以下三个版本之一：
| Ubuntu版本 | 内核默认版本 | BM1684兼容性 | 适用场景 |
|---|---|---|---|
| 18.04.6 LTS | 5.4.0 | 官方完整验证 | 老项目维护、生产环境 |
| 20.04.6 LTS | 5.15.0 | 官方推荐 | 新项目开发、多数AI框架 |
| 22.04.3 LTS | 6.2.0 | 社区验证良好 | 需要新特性、Python 3.10+ |
实战场景：某团队在Ubuntu 22.04上安装BM1684驱动时，发现insmod报错“Invalid module format”。排查后发现22.04默认内核6.2与驱动头文件版本不匹配。解决方案是安装linux-headers-$(uname -r)并重新编译驱动模块，但耗时较长。若一开始选择20.04，则可直接使用预编译驱动。
linux-image-5.15.0-generic内核包，切换到5.15内核后兼容性最佳。执行 sudo apt install linux-image-5.15.0-generic 并重启选择该内核。
3.2 内核要求：版本匹配与模块编译准备
核心原理：BM1684驱动以内核模块（.ko文件）形式加载，必须与当前运行内核的版本、配置（如CONFIG_MODVERSIONS）完全一致。SDK中的bmrt工具依赖/dev/bmdev设备节点，该节点由驱动创建。内核过旧可能缺少PCIe MSI中断支持，过新则可能改变API接口。
操作流程：
- 查看当前内核版本：
uname -r - 确认内核头文件已安装：
ls /usr/src/linux-headers-$(uname -r) - 若缺失，执行
sudo apt install linux-headers-$(uname -r) - 检查内核配置：
zcat /proc/config.gz | grep CONFIG_MODVERSIONS（应返回y）
案例拆解：某开发者使用Ubuntu 18.04默认内核4.15，安装驱动后ls /dev/bm*无输出。通过dmesg | grep bm1684看到“Unknown symbol”错误。原因是内核4.15缺少pci_alloc_irq_vectors符号。解决方法是升级内核至5.4（sudo apt install linux-image-5.4.0-generic），问题随即消失。
mainline内核（如6.8+），这些内核未经充分测试，可能导致驱动模块编译失败或运行不稳定。始终使用Ubuntu官方仓库中的LTS内核。
3.3 磁盘分区：预留空间与目录规划
核心原理：BM1684 SDK（约2GB）、Docker镜像（每个约3-5GB）、模型文件（数百MB）以及日志文件会快速消耗磁盘空间。默认分区方案中/和/var共用根分区，一旦Docker数据写满，系统将无法启动。建议将/var单独分区，或至少确保根分区有100GB以上空闲。
推荐分区方案（以500GB SSD为例）：
| 挂载点 | 大小 | 文件系统 | 说明 |
|---|---|---|---|
| / | 100GB | ext4 | 系统与驱动 |
| /var | 200GB | ext4 | Docker数据、日志 |
| /data | 200GB | ext4 | 模型、数据集、SDK |
| swap | 16GB | swap | 内存不足时兜底 |
操作流程：安装Ubuntu时选择“手动分区”，创建上述分区。若已安装系统，可使用gparted工具调整分区大小，但操作前必须备份数据。
实战场景：某团队在默认分区（根分区50GB）上运行YOLOv5训练，Docker镜像累积到30GB后系统报“No space left on device”。紧急清理/var/lib/docker后恢复，但后续频繁出现。最终通过添加新硬盘并挂载到/var/lib/docker解决。
sudo du -sh /var/lib/docker 检查Docker目录大小。若根分区紧张，可软链接到其他分区：sudo ln -s /data/docker /var/lib/docker。
3.4 网络配置建议：静态IP与代理设置
核心原理：BM1684开发过程中需要频繁下载依赖包（apt、pip）、拉取Docker镜像（docker pull）以及通过SSH远程调试。动态IP（DHCP）会导致IP变化，中断SSH连接；而网络代理配置不当则会导致下载超时或证书错误。
配置方法：
- 静态IP：编辑
/etc/netplan/01-netcfg.yaml，设置固定IP、网关和DNS。 - 代理设置：在
/etc/environment中添加http_proxy和https_proxy，并配置Docker代理（/etc/systemd/system/docker.service.d/http-proxy.conf）。 - DNS优化：使用
114.114.114.114或8.8.8.8，避免内网DNS解析失败。
# /etc/netplan/01-netcfg.yaml 示例
network:
version: 2
ethernets:
eth0:
dhcp4: no
addresses: [192.168.1.100/24]
gateway4: 192.168.1.1
nameservers:
addresses: [114.114.114.114, 8.8.8.8]
案例拆解：某实验室使用代理访问外网，但Docker拉取镜像时始终报proxyconnect tcp: dial tcp: lookup proxy.example.com: no such host。原因是Docker服务未继承系统代理。通过创建/etc/systemd/system/docker.service.d/proxy.conf并添加Environment="HTTP_PROXY=http://proxy.example.com:8080"，重启Docker后解决。
localhost或127.0.0.1，除非代理软件运行在宿主机上。若使用Docker容器，容器内需单独配置代理环境变量。
3.5 综合检查清单与常见问题复盘
核心原理：环境配置的失败往往源于多个因素的叠加。例如，Ubuntu版本正确但内核过旧，或磁盘空间充足但分区挂载错误。通过系统化检查清单，可以在5分钟内定位90%的问题。
检查清单：
lsb_release -a确认Ubuntu版本为18.04/20.04/22.04 LTSuname -r确认内核版本在4.15~5.15之间df -h确认根分区和/var分区有足够空间ip addr确认静态IP已生效ping 8.8.8.8测试外网连通性sudo apt update验证软件源可访问
复盘总结：根据多个项目经验，环境搭建失败的原因分布如下：
| 原因类别 | 占比 | 典型表现 | 解决耗时 |
|---|---|---|---|
| 内核版本不匹配 | 35% | insmod报错、设备节点缺失 | 1-2小时 |
| 磁盘空间不足 | 25% | Docker拉取失败、编译中断 | 30分钟 |
| 网络代理问题 | 20% | apt/pip超时、证书错误 | 1小时 |
| Ubuntu版本过新 | 15% | glibc不兼容、库缺失 | 2-3小时 |
| 其他 | 5% | BIOS设置、权限问题 | 不定 |
实战建议：在开始安装前，先使用vmstat和iostat检查系统资源，确保CPU、内存和I/O没有瓶颈。对于生产环境，建议使用PXE批量部署统一配置的Ubuntu系统，避免人工操作差异。