Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 70891 - coldplug-20040920 does not load net modules
Summary: coldplug-20040920 does not load net modules
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: x86 Linux
: High critical (vote)
Assignee: Greg Kroah-Hartman (RETIRED)
: 70977 (view as bug list)
Depends on:
Reported: 2004-11-11 16:46 UTC by John Altstadt
Modified: 2004-11-12 11:28 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description John Altstadt 2004-11-11 16:46:53 UTC
Cut 'n paste from bug #70793, comment #9. Complete with inflammatory comments. :-)

Just to add another data point to the discussion, I attempted the switch to coldplug.

emerge -p coldplug told me that it only needed to pull in the new hotplug (20040923) which would then be followed by coldplug (20040920). So I emerged hotplug by itself and followed the ewarn directions as follows:

- I had to compare the old and new /etc/hotplug scripts to find out where the firmware files were that needed to migrate to /lib/firmware. (It might have been nice to state in the ewarn that the originating directory was /usr/lib/hotplug/firmware.) I found that I had no such firmware files.

- I removed /etc/hotplug/isapnp.rc.

- I replaced all the old hotplug files with the new ._cfg* files.

Then I emerged coldplug and rc-updated it into the default level.

As far as I can tell, these are all the actions required to get this running.

I rebooted the sacrificial workstation.

It was broken. It did not load net.eth0 which led to a host of other services not starting. I had to remove coldplug and revert back to hotplug-20040401 to get my workstation working again.

So now we are left with the situation that not only does the new hotplug emerge destroy systems, but even following the directions in the ewarns and installing coldplug does not help.


See also

Reproducible: Didn't try
Steps to Reproduce:
1. emerge coldplug
2. rc-update add coldplug default
3. reboot

Actual Results:  
Net.eth0 was not loaded, so its dependent services were not loaded.

Expected Results:  
Acted just like the old version of hotplug by itself, which would load all the
required modules.

sabre root # emerge info
Portage 2.0.51-r3 (default-linux/x86/2004.0, gcc-3.3.4, glibc-,
2.4.26-gentoo-r9 i686)
System uname: 2.4.26-gentoo-r9 i686 AMD Athlon(tm) XP 1700+
Gentoo Base System version 1.4.16
distcc 2.16 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled]
ccache version 2.3 [enabled]
Autoconf: sys-devel/autoconf-2.59-r5
Automake: sys-devel/automake-1.8.5-r1
Binutils: sys-devel/binutils-
Headers:  sys-kernel/linux-headers-2.4.19-r1,sys-kernel/linux-headers-2.4.21-r1
Libtools: sys-devel/libtool-1.5.2-r5
CFLAGS="-O3 -march=athlon-xp -funroll-loops -pipe"
CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config
/usr/kde/3.1/share/config /usr/kde/3.2/share/config /usr/kde/3.3/env
/usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config
/usr/lib/mozilla/defaults/pref /usr/share/config
/usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/
/usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/
/usr/share/texmf/xdvi/ /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-O3 -march=athlon-xp -funroll-loops -pipe"
FEATURES="autoaddcvs ccache distcc distlocks maketest sandbox severe sfperms
strict userpriv"
USE="3dnow X alsa apache2 apm arts avi berkdb bitmap-fonts bonobo cdr cjk crypt
cups curl dga directfb divx4linux doc dvb dvd dvdread emacs encode esd ethereal
f77 fam fastcgi fbcon flac foomaticdb fortran gb gd gdbm gif gnome gphoto2 gpm
gtk gtk2 gtkhtml guile imagemagick imap imlib innodb java jpeg junit kde libg++
libwww live mad maildir mikmod mmx motif mozilla mpeg mysql nas ncurses network
nls odbc ofx oggvorbis opengl oss pam pda pdflib perl png python qt quicktime
quotes readline samba sasl sdl slang slp spell sse ssl svga tcltk tcpd tetex
theora tiff truetype unicode usb wmf x86 xml xml2 xmms xv xvid zeo zlib"

sabre root #
Comment 1 Greg Kroah-Hartman (RETIRED) gentoo-dev 2004-11-12 07:09:13 UTC
rc-update coldplug to the boot level, the same level you had hotplug at.

That should solve this issue.

As for the firmware files, they should have all been moved already by the 
packages that own them.  If not, file bugs for them.
Comment 2 John Altstadt 2004-11-12 08:01:13 UTC
You are making an incorrect assumption.

sabre root # cd /etc/runlevels 
sabre runlevels # ls boot default 
alsasound  checkfs    clock        hostname  localmount  net.lo     serial
bootmisc   checkroot  consolefont  keymaps   modules     rmnologin  urandom

autofs      distccd     lm_sensors  netmount  sshd
bootsplash  domainname  local       nfs       syslog-ng
cupsd       hotplug     net.eth0    ntpd      vixie-cron
sabre runlevels # 

As you can see, hotplug is in default, not boot. Why can't coldplug go in the same place?

I will try coldplug in boot though.
Comment 3 Greg Kroah-Hartman (RETIRED) gentoo-dev 2004-11-12 09:48:47 UTC
Coldplug should go into the same place as hotplug.

The assumption was that a lot of users put hotplug in their boot level, that is 
why I made it.

If coldplug is at the same level as hotplug, there should be no difference, unless
you happened to have hotplug running before net.* due to the way you installed 
the box :)
Comment 4 John Altstadt 2004-11-12 10:01:01 UTC
coldplug works when added to runlevels/boot but not when it is added to runlevels/default which was where hotplug always lived. Can this be fixed? The forum discussion mentioned above has one comment that states: "You are probably right but shouldn't be issue solved by adding "before net" to those damn coldplug scripts?"

As for the firmware files, this system never had any that I can tell. The command
  locate firmware
doesn't find anything relevant.

Over the long term I would prefer to move the required modules into /etc/modules.autoload.d/kernel*, which currently only contains ide-scsi. So, is there any way of finding out exactly which modules coldplug (or the old hotplug) is loading? All that shows up at boot is a generic message that says coldplug is working on usb, pci, etc. dmesg doesn't contain the console boot messages, and there are not enough messages coming from the modules themselves to identify them.
Comment 5 John Altstadt 2004-11-12 10:09:17 UTC
(Our last comments collided.)

As I mentioned in bug #70793 and the forum discussion, I have no idea how hotplug got on my systems. It had to have been in the first few hours of a fresh install. The directions given at that time must have been to put it in default, because I wouldn't have had a clue otherwise at the time.

I guess a lot of people were just lucky up till now. :-)
Comment 6 Greg Kroah-Hartman (RETIRED) gentoo-dev 2004-11-12 10:11:01 UTC
Look at what modules are loaded after booting.  If they aren't listed in
your autoload file, put them there.  That's all you need to do.

And yes, it does look like a lot of people were getting lucky.  Put coldplug
at the "boot" level should solve the issue for everyone.
Comment 7 John Altstadt 2004-11-12 10:25:21 UTC
I was afraid you were going to say that.

lsmod shows lots of modules, but I know that many of them were already installed before coldplug was started and that installing some of them will automatically trigger the installation of others.

Is there a problem with putting them all in modules.autoload.d, i.e. will some other part of the boot try to load them a second time and break the system in some other imaginative way?
Comment 8 Greg Kroah-Hartman (RETIRED) gentoo-dev 2004-11-12 11:10:09 UTC
How about just putting the modules that you _know_ you need in there
(like for your network card) and then working from there.

And no, just putting all of them in there would not harm anything.
Comment 9 Greg Kroah-Hartman (RETIRED) gentoo-dev 2004-11-12 11:28:20 UTC
*** Bug 70977 has been marked as a duplicate of this bug. ***