ifup async race problem

modules.d/40network/60-net.rules

ACTION=="add", SUBSYSTEM=="net", RUN+="/sbin/ifup $env{INTERFACE}" ACTION=="online", SUBSYSTEM=="net", RUN+="/sbin/netroot $env{INTERFACE}"

This works just fine if you have a single interface. But if you have more than one interface bad things can happen. If you have two or more interfaces and root=dhcp, the ifup udev rule attempts to dhclient on all interfaces simultaneously.

This can be a problem in cases where two or more interfaces are on DHCP networks. The udev rule kicked off both interfaces simultaneously, so there is no way to guarantee which of the two will succeed to mount the rootfs. In my testing this means eth0 or eth1 unpredictably mounted the rootfs. The other interface meanwhile is configured to an IP address and has routes added. DNS and routes configured could be either interface as well.

Locking so only one interface can ifup at a time wont exactly help here, because you still cannot predict which interface will go first.

It seems we have no way to make it predictable (eth0 attempts before eth1) while doing ifup from a udev event?

Warren Togami
[email protected]
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 5 lines · Warren Togami

modules.d/40network/60-net.rules

ACTION=="add", SUBSYSTEM=="net", RUN+="/sbin/ifup $env{INTERFACE}" ACTION=="online", SUBSYSTEM=="net", RUN+="/sbin/netroot $env{INTERFACE}"

Quoted 7 lines

This works just fine if you have a single interface. But if you have more than one interface bad things can happen. If you have two or more interfaces and root=dhcp, the ifup udev rule attempts to dhclient on all interfaces simultaneously.

This can be a problem in cases where two or more interfaces are on DHCP networks. The udev rule kicked off both interfaces simultaneously, so there is no way to guarantee which of the two will succeed to mount the rootfs. In my testing this means eth0 or eth1 unpredictably mounted the rootfs. The other interface meanwhile is configured to an IP address and has routes added. DNS and routes configured could be either interface as well.

Locking so only one interface can ifup at a time wont exactly help here, because you still cannot predict which interface will go first.

It seems we have no way to make it predictable (eth0 attempts before eth1) while doing ifup from a udev event?

My preferred solution would be to have the udev rule only grab configuration information (either from dhcp or ip= lines), and actually bring the interfaces up in the mount loop, where we can serialize them according to whatever the local netboot configuration requires.

Parallelizing the config information grabbing is a clear win (dhcp can take forever), but actually bringing up and taking down the interfaces is very fast once we actually have the information. :)