Slackware设置开机启动

你现在这个情况是：bond 是被第三方软件生成/接管的，你只能看到（或改到）类似下面这些字段：

 

ip="10.7.1.122"

netmask="255.255.255.0"

mode="4"

slaves="eth0 eth1"

mac=""

👉 配置项里根本没有 xmit_hash_policy，对吧？
这在 PXE / 无盘 / 管控系统里非常常见。

下面直接给你三种可行方案，按“侵入性从低到高”，你选一个就能用。

---

方案一（最稳、最常用）：运行后强制写 sysfs ✅

这是不改第三方配置、成功率 100% 的做法。

直接在 bond 创建完成后执行：

 

echo layer2 > /sys/class/net/bond0/bonding/xmit_hash_policy

立即生效（只影响新连接）。

验证：

 

cat /proc/net/bonding/bond0 | grep "Transmit Hash Policy"

看到：

 

Transmit Hash Policy: layer2 (0)

---

⚠️ 关键点（一定要注意）

• 必须在 bond0 已存在 之后

• 第三方软件重建 bond 时会被覆盖

• 重启会丢失

👉 所以通常要 自动化兜底

---

方案二：用 udev 自动兜底（强烈推荐） ⭐⭐⭐

这是最优雅、不怕第三方覆盖的方案。

1️⃣ 创建 udev 规则

 

vi /etc/udev/rules.d/90-bond-xmit-hash.rules

内容：

 

ACTION=="add", SUBSYSTEM=="net", KERNEL=="bond0", \

     RUN+="/bin/sh -c 'echo layer2 > /sys/class/net/bond0/bonding/xmit_hash_policy'"

如果 bond 名不是 bond0，改成 KERNEL=="bond*" 也行。

---

2️⃣ 重新加载规则

 

udevadm control --reload

测试（可选）：

 

udevadm trigger -c add -s net

---

3️⃣ 优点

• ✅ bond 每次创建都会自动修正

• ✅ 不依赖第三方配置格式

• ✅ 适合 PXE / 无盘 / 管控系统

• ✅ 不怕 reboot / 重建

---

方案三：rc.local / 启动脚本兜底（简单但不完美）

如果你用的是 Slackware / 非 systemd，这是最容易的。

编辑：

 

vi /etc/rc.d/rc.local

加：

 

# Fix bonding xmit_hash_policy for PXE

[ -e /sys/class/net/bond0/bonding/xmit_hash_policy ] && \

   echo layer2 > /sys/class/net/bond0/bonding/xmit_hash_policy

 

chmod +x /etc/rc.d/rc.local

---

三种方案怎么选？（一句话）

场景	推荐
第三方偶尔改 bond	方案一
第三方经常重建 bond	方案二（udev）
Slackware / 简单环境	方案三

---

再给你一个“生产级防踩坑补丁” 🔧

有些第三方在 bond down → up 时会偷偷重置策略，你可以用更通用的规则：

 

ACTION=="add|change", SUBSYSTEM=="net", KERNEL=="bond*", \RUN+="/bin/sh -c 'echo layer2 > /sys/class/net/%k/bonding/xmit_hash_policy'"

---

最后一个确认（很重要）

你这个配置看起来 非常像 PXE / 无盘 / 管控系统自动生成 的网络。

👉 我想确认一句：

• 这是 PXE 无盘节点？

• 还是 宿主机给大量机器装系统？

如果是 PXE，我还能顺手帮你把：

• LACP

• MTU

• ad_select

• TFTP / NFS 吞吐

一起调到 最佳状态。

 

udevadm trigger -c add -s net开机会启动的吗

 

短答先给你（很确定）：

❌ udevadm trigger -c add -s net 不会“自动”在开机执行
✅ 但你完全不需要手动执行它

下面把 udev 在开机时到底发生了什么 给你讲清楚。

---

一、开机时 udev 到底做了什么？

在系统启动过程中（包括 Slackware）：

1. 内核发现网络设备

   • bond0

   • eth0 / eth1

   • tap / vnet

2. 内核发出 add 事件

3. udevd 自动处理这些 add 事件

4. 你的规则：

 

ACTION=="add", SUBSYSTEM=="net", KERNEL=="bond0", RUN+=...

👉 会在开机时自动触发一次

不需要你手动跑 udevadm trigger。

---

二、那 udevadm trigger 是干嘛的？

它的用途只有一个：

“补发一次事件”

典型场景：

• 你刚写完 udev 规则

• 设备已经存在

• 不想重启

这时你才用：

 

udevadm trigger -c add -s net

等价于：
👉 假装所有网卡刚刚被插上

---

三、所以你的 udev 方案在开机时是安全的吗？

✔ 是的
✔ 非常可靠
✔ PXE / 无盘环境里就是这么干的

时间顺序大概是：

 

bond0 创建↓ udev 收到 add↓ RUN echo layer2 > xmit_hash_policy↓ bond0 启动完成

---

四、你还需要注意的一个“细节坑” ⚠️

bond0 是谁创建的？

如果是：

• 内核 + rc.inet1

• ifup / network scripts

• libvirt

• 管控系统

👉 都会产生 udev add 事件

---

但如果第三方软件是这样干的：

 

先创建 bond0 然后多次 down/up

那么：

• ACTION=="add" 只触发一次

• 后续 不会再触发

这时建议用这个 更稳规则：