Bugzilla Bug 70793

Emerge hotplug now installs a new version of hotplug:
sys-apps/hotplug-20040923 

However this version requires coldplug to be emerged AND added by rc-update to default rulevel, otherwise the system breaks. 

A note saying coldplug should be emerged appears at the end of the install but no mention is made of the necessity of adding coldplug to default runlevel.


Reproducible: Always
Steps to Reproduce:
1.emerge hotplug
2.reboot
3.

Actual Results:  
system breaks: on reboot, after entering runlevel 3, most services fail.

Expected Results:  
It should have emerged coldplug as a dependency of hotplug, and added coldplug
to defautl runlevel if hotplug already was in default runlevel.

Extended the message to ask users to put coldplug in a runlevel. I'm not going
ahead with the other things you suggested, many people want to run hotplug
without coldplug. Also ebuilds do not modify runlevels.

Also, people _really_ shouldn't be running coldplug at all, unless
they know what they are doing.  It's scary stuff.

There's a reason no other distro does this...

"many people want to run hotplug without coldplug."

Excuse me, but how can those people run hotplug without coldplug if it breaks the system?! How could this bug be marked as "fixed"? Either there should be a dependency on coldplug or this ebuild should be masked. :-(

"Also, people _really_ shouldn't be running coldplug at all, unless
they know what they are doing.  It's scary stuff."

So hotplug and coldplug should be hard-masked and not stable! 

Not true, they are stable, if you really want to use them :)

*** Bug 70824 has been marked as a duplicate of this bug. ***

I have no idea how hotplug got on my systems. It was probably emerged as a
dependancy of something else back in the mists of time. It's not a matter of my
"wanting" to use it.

All I know about the issue is that an emerge system rendered one of my systems
broken. Luckily I only rebooted one computer after the multi-system maintenance
upgrade and was able to back out the "upgrade" on the others before I had
nothing working.

Changing the ebuild so that it halts the upgrade until all the dependencies are
in place would be acceptable. At least it would get people to do the research
on what hotplug and/or coldplug are doing on or for their systems.

I don't know what other people would consider acceptable, but as I pointed out
in bug #70824, a few ewarns in the middle of an emerge system is not it.

People are working on notifying users better about this issue.

Your patience is appreciated.

Greg, pardon my ignorance, but no package whatsoever should be left "stable" if
it is known to break system and you are not willing to _fix_ the problem. This
is completely in contradiction with the very purpose of having package masks in
portage.

I do not suppose that "stable" shall mean stable under all circumstances but I
really _do_ expect that any package will NOT remain marked stable while it is
known that it will render my system unuseable. And also if it is known that a
package has some dependencies then it is not enough to ewarn users that it
needs them, this should be solved via depend in the ebuild. 

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.

Ok, two different issues here.

For comment #9, please open a new bug and we can work on it from there.

For comment #8, it's not the fact that the coldplug (or hotplug) package itself
isn't stable.  What isn't stable is loading a whole bunch of kernel drivers
into your system without knowing exactly what it is doing.  That's a kernel issue,
and has been known to cause bad things (the response is, don't build and load
those modules then.)

As Gentoo doesn't have an installer, to help configure what modules should be
loaded for your system based on the hardware, you have to either:
  - let coldplug make the best guess.
  - use kudzu or some other like minded program
  - use modules.autoload to load the modules that you need.

I suggest, and recommend the last option.  modules.autoload is what you should
use if you need modules loaded at boot time.  Don't use coldplug unless you know
exactly what you are doing.  That same warning was always made for the hotplug
package too, and if you search the bugzilla archives you will see that history.

Just to respond to an earlier comment since it was me who closed the bug, well,
making hotplug depend on coldplug will not help. ebuilds cannot add scripts to
a runlevel, and what good is coldplug installed but not in a runlevel?

I closed the bug because I had taken up the suggestions in all ways that were
possible (and useful) with our package system. Please don't sound so shocked :)

Could you change the ebuild to check for coldplug in /etc/runlevels/default and
do an eerror (if there is such a thing) to halt the emerge if it is missing? Of
course this would annoy the folks who have their modules.autoload.d files
configured correctly.

After spending a good deal of time on this problem today, I have come around to
the reasoning behind the current ebuild, but not the actual implementation we
have today. It would help if the ewarn (or eerror) would point to a web page
that says how to migrate from hotplug to autoload files.

I think this all stems from some old system installation instructions that said
to use hotplug to load the drivers at boot. Older users already had the
autoload files set up correctly and newer users might never have installed
hotplug.

sorry, but no, we can't do that in an ebuild.