If this is actually a d-i/netcfg bug, then one approach would be to remove net-hotplug.sh (or its udev rule) from hw-detect. This script detects net device additions, and registers the devices as hotpluggable. With udev I think that all network devices come in this way, be they pci cards or usb nics. Perhaps it would be possible to modify the udev rule to exclude pci cards somehow, I don't know. (Then too, some systems do have hotpluggable pci cards.)
It's not particularly clear to me that this is a d-i bug though. If ifupdown/udev doesn't behave correctly/reliably for allow-hotplug interfaces that are cold-plugged at system boot, shouldn't it be fixed? We certianly have users with those sorts of interfaces, after all. I was able to reproduce the behabior described in this bug where the interface doesn't come up at all, and identify at least two separate scenarios where udev fails to bring it up. I've filed two bugs on udev for those scenarios; one invoves a long root fsck and a timeout, while the other can be reproduced by simply hard power cycling a box that has the allow-hotplug setting. I feel that this latter bug is indeed release critical, and is probably the one that the contributors to this bug report ran into. That leaves the other note from this bug, that: > Thus my builtin network card on my server is now "hotplugable" which > means that is is initiallised asyncronosly at bootup. That's true, and normally it will be initialised shortly after /etc/init.d/networking brings up the lo interface, but it could take arbitrarily long. I can see that causing some potential problems for certian services that expect the network to be up after /etc/init.d/networking, but it's not clear to me that those problems are acutally release critical. I've downgraded this bug for now, but it could be upgraded if there are actual concrete examples of this asynchronycity causing problems. [Hmm, one approach would be to make net.agent, when it calls ifup, register that interface in some file somewhere. Then when /etc/init.d/networking starts up, it could read that file and get a list of interfaces that were (mostly?) cold-plugged, and it could wait until all those interfaces finish coming up before returning.] -- see shy jo
signature.asc
Description: Digital signature
