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 http://forums.gentoo.org/viewtopic.php?p=1753418
Reproducible: Didn't try
Steps to Reproduce:
1. emerge coldplug
2. rc-update add coldplug default
Net.eth0 was not loaded, so its dependent services were not loaded.
Acted just like the old version of hotplug by itself, which would load all the
sabre root # emerge info
Portage 2.0.51-r3 (default-linux/x86/2004.0, gcc-3.3.4, glibc-220.127.116.1140808-r1,
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]
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
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
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 #
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.
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.
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 :)
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
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.
(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. :-)
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.
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?
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.
*** Bug 70977 has been marked as a duplicate of this bug. ***