On Wed, 2009-06-10 at 17:52 -0400, Warren Togami wrote:
> 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?
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. :)
> Warren Togami
> wtogami@xxxxxxxxxx
> --
> To unsubscribe from this list: send the line "unsubscribe initramfs" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Victor Lowther
RHCE# 805008539634727
LPIC-2# LPI000140019
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
