If a network driver module is loaded, in modules.autoload.d/<kernel-version> hotplug attempts to start the related network script. This is undesired for a few reasons 1) The user cannot say "don't start the network script" 2) the rc script state directory (/var/lib/init.d/started) isn't created rw at this point so the script is "started" but not marked as "started" which causes a few problems The patch attached to this bug simply adds a test for the existance of /var/lib/init.d/started before starting the script as this directory is required to mark net scripts as started and doesn't exist when /etc/init.d/modules is called on boot. Hotplug and coldplug can still start network scripts after /var/lib has been mounted rw and the state dir as been created.
Created attachment 48828 [details, diff] stops hotplug launching net scripts if state dir does not exist
Your patch fixes the "/var/lib/ is not mounted" issue, but it doesn't solve the "don't start the network" issue. Is that ok?
Sure it fixes it - if the user inserts a pccard after /var/lib/init.d becomes available then we start the script. Which is good, because inserting the card implies we want it to start. The only other thing that can start it AFAIK is coldplug. I see what coldplug is doing as "correct behaviour" and am currently unsure what todo about networking in this instance. But adding coldplug is a user thing, whereas hotplug is pretty essential for some users.
*** Bug 81621 has been marked as a duplicate of this bug. ***
Thanks! Patch tested & working here against my prism2.5 card in master mode, baselayout-1.11.9 or so.
*** Bug 84619 has been marked as a duplicate of this bug. ***
This patch fixed my network not working every other boot on a fresh 2005.0 install.
Created attachment 55746 [details, diff] Stops net scripts from lanching if in the BOOT runlevel Except for net.lo
Note that this patch causes trouble for those of us using coldplug to start e.g. cardbus wireless network cards. With this patch, they don't start if plugged in at boottime.
Provided that coldplug is in the default runlevel and not the boot runlevel then it should work fine ....
Created attachment 56507 [details, diff] Prevents hotplug running /etc/init.d/net.<interface> Maybe this patch could be usefull. Whether to let hotplug bringing up a network interface or not doesn't depend on the runlevel only, but on the links under /etc/runlevels too. This prevents /etc/init.d/net.<interface> is ran twice if such a link exists on boot.
I think this bug should be marked as a duplicate of bug 56943. Matt Drew already proposed a patch on December 2004 (see bug 56943, comment #7); mine differs slightly.
The problem is that hotplug is doing it's job - and after much thought, hotplug is doing things correctly as it stands. The issue is with Gentoo more than hotplug as Gentoo should decide the order of starting and stuff. Hotplug really is for starting devices when they're plugged in. Hence my patch to runscript.sh which Gentoo provides through baselayout.
*** Bug 56943 has been marked as a duplicate of this bug. ***
I don't think hotplug starting network scripts whenever a network driver gets loaded is the Right Thing. Some people use hotplug for loading PC Cards (almost invariably network cards), and some people depend on hotplug for system startup. Hotplug bringing up network interfaces is desired by the first group (convenience) and not desired by the second group during startup (because it bypasses the init scripts and can cause problems) and possibly not desired at all. Even if we have hotplug look at runlevel, make sure the ability to show started status is available, and see if the runlevel contains a network configuration for ethX, we still run across problems where the interface isn't supposed to be up, but it comes up anyway and I can't stop it. Example: I configure eth1 (a Sprint cellular modem/network card) to not start on boot, because I only want it to connect sometimes (it's expensive to use). Unfortunately, hotplug ignores that. If the card is present during boot, hotplug will start it regardless of my configuration (though it will be brought down again as the boot proceeds). If I insert the card after boot, hotplug will bring it up (whether I want it to or not). And it will do it without any kind of user notification. In my experience, inserting a network card driver does NOT automatically imply the desire to have a network interface brought up. The net.agent script assumes that bringing up the interface is the desired behavior 100% of the time. That was a pretty valid assumption when hotplug was used for PC Cards, but it isn't a valid assumption now that hotplug is used for full system initialization. I think we need to divorce interface control from driver loading, at least during boot. Our patches are workarounds for a deeper problem: the lack of control over hotplug starting network interfaces. Ideas: 1) Perhaps we could "mark" interfaces as hotpluggable, and teach hotplug to use that mark to determine whether or not to start the interface (but it still shouldn't start them before we reach the default runlevel). 2) We could queue up network events ala SuSE, and be more specific about devices (I think this is the wrong solution). 3) We can disable the automatic interface configuration altogether, and do things manually (certainly the simplest solution). Interfaces can still start automatically, but only at boot time via the startup scripts. Otherwise, you have to bring it up yourself after driver loading/insertion. 4) Disable the automatic configuration, and run another service (coldplug?) that monitors devices with network interfaces that are configured to be automatically brought up, and starts the interface when the device driver is loaded. This is similar to 1), and avoids starting during boot by only having the service run in the default runlevel. Don't want something to start automatically? Unconfigure that device, or disable the entire service temporarily. I default to option 3, but that's cause I'm a curmudgeon. Option 4 is probably the best bet, to allow people who want the interface to come up on insertion the ability to do that. It's as safe as it can be, and avoids all the nasty boot problems.
Roy you are right, hotplug is doing his job correctly. But I think his job finishes when invoking net.agent, that is: a network card has been plugged in, a module has been loaded, system boots, whatever, hotplug must run the proper agent. The way this agent works depends on the agreed policy (I don't know Red Hat and Suse but Debian way is quite different from Gentoo's). Especially network interfaces should receive a special treatment, since /etc/init.d/net.<interface> cannot be ran twice, and one must choose whether hotplug or init will run it. As Matt states, having a card plugged in doesn't mean desiring of bringing up a network interface (on boot at least); moreover, I'd like to specify different behaviors for different interfaces/cards. Therefore I think the problem is more complex than specifying a boot order and the blacklist mechanism alone is not tunable at all. I suggest to follow Matt's option 1: 1) let the user decide which policy meets his demands by means of the hotplug_<iface>_policy variable which can assumes values "auto", "never" and "butboot" (set it wherever we want): auto: hotplug will always try to bring up the <iface> interface; never: hotplug will never try to bring up the interface (if user keeps on using init scripts on boot or even manually configures the interface (good luck)); butboot: hotplug will always try to bring up the interface except on boot. 2) depending on the current runlevel and the policy selected (suppose default value is auto) /etc/hotplug/net.agent should call /etc/init.d/net.<iface> or not. If we want network interfaces be configured during default runlevel then we have to set hotplug_<iface>_policy="butboot" and then create the link /etc/runlevels/default/net.<iface> -> /etc/init.d/net.<iface>.
Created attachment 56853 [details, diff] Sample implementation of net.agent with policy Just to give a clearer idea of the idea. Apply the patch and put two line like following into /etc/hotplug/net.rc: hotplug_eth0_policy="butboot" export hotplug_eth0_policy Then change the execute permissions: chmod 755 /etc/hotplug/net.rc Hotplug will not configure interface eth0 on boot.
Created attachment 57235 [details, diff] Patch to add hotplug policy to net init scripts An alternative to comment #17 - this one implements policy in net.lo, which means we get to put the configuration in /etc/conf.d/net with the rest of the network stuff. This patch makes the init script check whether it's being run from hotplug. This is done after modules get loaded, but before the pre-up function [I'm not sure if this is the right place for it, but it seems to make sense]. If we're being run from hotplug, the variable hotplug_${ifname} is checked to see if we should be messing with the interface. If it's set to "nostart" the init script just exits, otherwise it continues normally.
I just had a hard time figuring why the init script where automatically launched when I modprobe the driver. In my case it was with ipw2200. A bad combination in the wireless init-scripts render the card unusable when launched by rc-scripts, (it cannot associate anymore, i should probably debug it and fill a bug about it). That's why i didn't want the init-scripts to be launched. I think we should keep in mind that hotplug event are also generated when modprobing the driver (not only when plugging a new card), so the solution with the policy is probably the best (it will solve cases similar to mine at least).
I like the policy idea. However, I've made things a bit more simple by just using a boolean. I think consistency would be best here so either hotplug the interface or we don't. hotplug_${ifvar} is checked for either "no" or "false" and then stops with an error. Will be in baselayout-1.12.0-alpha3
Fixed in baselayout-1.12.0_pre1-r1
