Summary: | emerge hotplug | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Michele Alzetta <michele.alzetta> |
Component: | [OLD] Core system | Assignee: | Greg Kroah-Hartman (RETIRED) <gregkh> |
Status: | VERIFIED FIXED | ||
Severity: | critical | CC: | altstadt, dsd |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Michele Alzetta
2004-11-11 07:00:18 UTC
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. |