There is one problem with loading modules in modules.autoload.d - when the networking card is loaded, the hotplug agent catches this and tries to start the script. The major trouble here is that during the boot-up process the services are not marked as started, so the networking service tries to start everything from the beginning in the background - starts also the script 'Mounting root filesystem read-only' and so on! This is not good, the boot-up process can even freeze (happened to me if I added some dependencies to net.eth0). I was thinking about some master execution plan thing, which is created every time something is going to be started. And if something wants to start and the master execution plan is already existing, it has to consult the execution with the master plan. To implement such thing there has to be a locking functionality - see bug #118418 for implementation (in BASH).
Don't put network card modules in there then - use coldplug to load them.
Ick, don't use coldplug, that will load them even earlier, right? And I'm trying to get rid of it (udev will do coldplug for you if you uncomment out one line in the udev startup logic, much faster than the coldplug package and works better...)
I'm using coldplug, but I'm not happy with it. I also missed a BIG FAT WARNING somewhere. It would be nice to place the warning somewhere visible (and force people to use coldplug...). I think there should be some more clever solution, not only say "use something else" - there is surely somebody, who doesn't want to use coldplug (for whatever reason). Coldplug is not an universal solution, so why to disallow to load network modules manually during the system boot-up? Give me a reasonable answer and I will sleep better :-)
(In reply to comment #2) > Ick, don't use coldplug, that will load them even earlier, right? > Wrong. modules is a CRITICAL_SERVICE is normally run early in the boot sequence so it loads disk drivers, etc so it can mount /var/lib rw coldplug is not and depends on modules so it runs afterwards - and /var/lib is mounted rw at this point. > And I'm trying to get rid of it (udev will do coldplug for you if you uncomment > out one line in the udev startup logic, much faster than the coldplug package > and works better...) > As long as we can tell udev to "go" via an init script or the udev-startup scripts after /var/lib is mounted rw then I'm happy :)
Infact a quick look through the source shows that the commented line in trigger_events for the "real coldplug" shows that it would happen far far too early in the boot process. imo, nothing should be triggered like this until after RC critical services have been started. Hence coldplug is doing just fine.
(In reply to comment #3) > I'm using coldplug, but I'm not happy with it. I also missed a BIG FAT WARNING > somewhere. It would be nice to place the warning somewhere visible (and force > people to use coldplug...). We shouldn't force people to use coldplug. However, there's nothing wrong with a big fat warning either :) I'll slap a warning into /etc/modules.autoload.d/kernel* telling them not to use this for loading network modules if they have hotplug or udev installed.
> We shouldn't force people to use coldplug. > However, there's nothing wrong with a big fat warning either :) > I'll slap a warning into /etc/modules.autoload.d/kernel* telling them not to > use this for loading network modules if they have hotplug or udev installed. That "big fat warning" came through today and it reads: # This file should only be used to load modules that are essential to the # mounting of local partitions, such as RAID controllers. # Coldplug or similar should be used to load the rest of the modules # for your hardware automatically. # # WARNING: It is dangerous to put modules here which will cause hotplug to # start services, for example network driver modules. The wording in the first paragraph is misleading. I had nvidia, subfs and bc modules which this warning suggests should not be loaded in the autoload file. Ater removing these three modules as suggested and rebooting they were not reloaded. After putting them back in I could reboot and everything worked again. I suggest the warning is reworded to only mention network cards specifically. Not a global "remove everything but raid" .
I've removed the first paragraph and changed the second one to read # WARNING: It is dangerous to put modules here which will cause hotplug to # start services, for example network driver modules. # For network modules it is advisable to use coldplug to load your modules. # You can do this by emerging coldplug and adding coldplug do the boot runlevel # using rc-update. See bug #118419 for why this is.
Fixed in -r2
Hi, could you please tell, WHICH modules might start services? And btw, up until this moment, I loaded my networking modules with autoload and had no problems, but the one time I used coldplug everything was in a great mess. Granted ,that was a long time ago, but I do not want to use any service that I could skip. Gentoo's booting became more and more time consuming over the years, and I hate waiting for the scripts (if I liked watching my box booting for ages, I could happily use SuSE). Also, IMHO, if hotplug starts services just based on loaded modules, hotplug is broken and should be fixed and not the user forced to add another boot service that could be skipped savely otherwise. I have lots and lots of modules, which I only need occasionally,. Why do I want coldplug loading all of them, if I can load only the ones I want and need all the time with autoload, and load the ones I need less than once in a month when I need them with modprobe?
Yes, I agree. Until now nobody offers really fix the problem - postpone module loading until the core system is completely up (only the CRITICAL_SERVICES in /sbin/rc).
(In reply to comment #11) > Yes, I agree. Until now nobody offers really fix the problem - postpone module > loading until the core system is completely up (only the CRITICAL_SERVICES in > /sbin/rc). > You see that's the problem - modules IS a CRITICAL_SERVICE .... it may be needed for things like localmount and other CRITICAL_SERVICEs.
Created attachment 77355 [details, diff] Sleep init scripts until sysinit has completed Attached is a patch that causes init scripts to sleep when /proc/sys/kernel/hotplug exists and is set to /dev/null,/bin/true or /bin/false - ie not a valid hotplug agent. When it's set back to a valid hotplug agent then the init script is woken up. Please test this against baselayout-1.12.0_pre14-r2
Created attachment 77359 [details, diff] Fixed hotplug patch for netlink Patch against baselayout-1.12.0_pre14-r2 Fixes the problem with netlink: /lib/rcscripts/addons/udev-start.sh sets the hotplug agent to "" echo "" > /proc/sys/kernel/hotplug so the restoring of the agent stops working.
(In reply to comment #12) > You see that's the problem - modules IS a CRITICAL_SERVICE .... it may be > needed for things like localmount and other CRITICAL_SERVICEs. > I had in mind postponing of the hotplug effect. And the real fix was introduced in comment #13 and fixed a little bit in comment #14 :-)
Does it fix your issue?
Any yes, your patch with my update fixes this issue completely :-)
please do NOT mess with /proc/sys/kernel/hotplug, it is set to NULL for a good reason. If you mess with it, after the udev startup script has modified it to be what it knows to be the proper program (or not), things can get very messed up. For newer udev versions, on the 2.6.15 kernel, we use netlink to get the messages, and udev fires off the proper old-style hotplug events when needed. That is why that file is set to NULL. I'm working with uberlord to get the proper resolution here.
(In reply to comment #18) > For newer udev versions, on the 2.6.15 kernel, we use netlink to get the > messages, and udev fires off the proper old-style hotplug events when needed. > That is why that file is set to NULL. Ok, I do not know problems of hotplugging. I have suspend2-sources-2.6.15-*. At least patch from uberlord introduced a lock that was needed: hotplug events still started my network scripts immediately after modules were loaded, but they were put into sleep until the hotplug agent changed back from /bin/false into NULL. At least it works (somehow) on 2.6.15.
Created attachment 77568 [details, diff] Lock init scripts from running when /dev/.rcsysinit exists
Created attachment 77569 [details, diff] udev creates /dev/.rcsysinit for locking This is a needed patch to the udev addon scripts to create the lock
Thanks, that works. Events are not postponed, they are ignored. I think it would be better to stop execution of script before mylevel is taken from {svcdir}/softlevel (in runscript.sh on line 27) as the file softlevel doesn't exist - it generates an error (my modified net.agent writes output to console). I mean to put the check just after the check for EUID in runscript.sh.
baselayout-1.11.14-r2 and baselayout-1.12.0_pre15 have the patches in portage. Awaiting on udev to be fixed in portage.
udev-079-r1 and udev-081-r1 have the fixes in portage.
Thanks for very nice solution of this problem.
