The versions of sys-fs/udev which have hotplug functionality built in should not only block sys-apps/coldplug but also sys-apps/hotplug.
The reason for this is that udev and hotplug conflict with each other.
Hints for the conflicts can be found here in bugzilla and in the forums. Unfortunately I don't have a link right now. But as many other people I had some issues with my usb scanner, the /dev/cdrom and /dev/dvd links and udev rules which have been ignored by udev. See the many bug reports and forum threads about it.
After unmerging hotplug everything is working well again as before I'd upgraded to the first udev version with hotplug and coldplug functionality, before udev-089 I guess.
To explain it a bit more detailed:
As you possibly know there are many and long discussions about inconsistant
linkings for some devices like /dev/cdrom, /dev/cdrw etc. in the forums.
Many people including myself have the problem that randomly after each reboot
sometimes /dev/cdrom is their CD-ROM drive and /dev/cdrw is their CD-RW burner
and sometimes it's vice versa. Additional there are sometimes links like
/dev/cdrom1 which are randomly linked against different devices.
Another problem is that some udev rules for some usb devices like setting the
owner and group for the usb scanner are ignored even if they look correct.
After searching and reading a lot in the forums and in bugzilla I had the idea
to uninstalling hotplug and delete the directories /etc/hotplug*.
After this and rebooting the system every problem with the device links and the
udev rules were fixed without changing anything else. The device links are
consitant and link to the correct devices and the udev rules are applied again
so that the correct permissions are set again.
That's why I suppose that there is a conflict between hotplug and udev.
And, btw., hotplug isn't needed anylonger if a newer udev version with built in
hotplug functionality is installed. ;-)
If you have both udev and hotplug installed you have the same software
installed twice. It's not quite unusual that this can lead to conflicts.
Btw, since one of the latest emerge -uDN world the inconsistencies of the device links is back again. But I don't know yet what has changed.
At the same time every ebuild which depend on sys-apps/hotplug should be changed, so that it depends on sys-apps/hotplug-base instead because hotplug-base is a dependency of hotplug as well as of udev.
Please see also my other bug reports:
This is already under way, both of these will provide a virtual...
But right now we do rely on one part of the hotplug scripts, the network stuff
that has yet to be implemented in the udev scripts.
I'm going to close this out, this is the way forward, but we are not quite ready...
*** Bug 148104 has been marked as a duplicate of this bug. ***
Reopen to dupe.
*** This bug has been marked as a duplicate of 147006 ***
On a second though, this thing is heavily broken, completely unmaintained and just needs to die; see the bugs linked to this one.
udev-103 should block this thing to force people to unmerge it, it's causing lots of troubles and isn't much useful for anything.
Created attachment 107057 [details, diff]
disable hotplugd-calling for compatibility
Second approach that enables people to keep hotplug for strange mixed 2.4/2.6 systems: Not call hotplugd compatibility script by default.
udev-103-r1 no longer calls scripts in hotplug dir.
(In reply to comment #7)
> udev-103-r1 no longer calls scripts in hotplug dir.
/me blinks... Like, that you killed hotplug functionality in udev unconditionally?
Yes, that is the correct solution. udev should handle it all on it's own now.
If you need hotplug to do anything for 2.4, we should leave it alone on the box.
And sorry for the delay, real-world has been rough lately, and my gentoo time has been limited :(
(In reply to comment #9)
> Yes, that is the correct solution.
Uhm, could you clarify please what exactly is the correct solution? Killing udev's hotplug functionality?
(In reply to comment #7)
> udev-103-r1 no longer calls scripts in hotplug dir.
Congratulations. Both gregkh and myself told you that network scripts and bluetooth would not be called anymore.
I've lost the ability to plug a pcmcia network card into my laptop and Gentoo to start it automatically :/
(In reply to comment #11)
> I've lost the ability to plug a pcmcia network card into my laptop and Gentoo
> to start it automatically :/
You have? To fix this would be a very simple udev rule, which is the correct solution to take here.
I'll work on this tomorrow, as I have the hardware to test this out.
This is also why I did not do this kind of change just yet, it needs a lot of testing and coordination.
And I haven't "disappeared", a simple email or ping would have proven that.
I'll try to fix up the mess tomorrow...
(In reply to comment #12)
> (In reply to comment #11)
> > I've lost the ability to plug a pcmcia network card into my laptop and Gentoo
> > to start it automatically :/
> You have? To fix this would be a very simple udev rule, which is the correct
> solution to take here.
Remember to export IN_HOTPLUG=1 :)
Ditto automatic starting of my network scripts on modprobe. I'll test too see if bluetooth still automatically works on my laptop later today.
gregkh: zzam did send you a ping to see if you were alive, and recieved no response, and thus went ahead to work on udev. He was originally after fixing some CDROM stuff and thus asked me about it (since you nearly ate my head off for bumping udev in the past when I had fibrechannel issues and needed the bump).
There are a lot of people claiming breakage, because of all the things that were invoked by hotplug. net.agent, code from 2004 raising Uberlord's ire for one.
Hotplug scripts and maps that were installed by packages other than hotplug itself need some more work from their maintainers - I'm doing gpsd now, simply because I have supported hardware.
uberlord: the bluetooth init scripts are started on my laptop fine automatically by udev when the modules get loaded. I'm porting the gpsd hotplug caller now
Here is an extremely crude version of everything that hotplug's net.agent did for Gentoo:
ACTION=="add", SUBSYSTEM=="net", RUN+="/etc/init.d/net.%k start"
ACTION=="remove", SUBSYSTEM=="net", RUN+="/etc/init.d/net.%k stop"
It works for me, but it does definetly need cleanup.
Look at 70-bluetooth.rules and /lib/udev/bluetooth.sh for a cleaner way to do it.
gregkh could probably suggest other nice cleanups too.
(In reply to comment #16)
> Here is an extremely crude version of everything that hotplug's net.agent did
> for Gentoo:
> ACTION=="add", SUBSYSTEM=="net", RUN+="/etc/init.d/net.%k start"
> ACTION=="remove", SUBSYSTEM=="net", RUN+="/etc/init.d/net.%k stop"
> It works for me, but it does definetly need cleanup.
> Look at 70-bluetooth.rules and /lib/udev/bluetooth.sh for a cleaner way to do
I went with adding net.sh to /lib/udev and calling that.
This is because we may wish to expand it at some point to maybe create links to net.lo if needed on hotplug events.
When we stop we sleep for a second so that any interface monitoring daemons like wpa_supplicant, netplug, etc have a chance to stop before we do - this is needed so udev can in turn stop the daemons.
This has been added to udev-103-r2.
gregkh: I've been sending you e-mails and I was also trying to work with you several months ago before 103 hit the tree on new HAL stuff but you kind of stopped responding to me....
*** Bug 163106 has been marked as a duplicate of this bug. ***
Any issues w/ p.masking hotplug anywhere but on 2.4 profiles (plus doing some udev versions cleanup)?
net-wireless/ipw2100-firmware depends on hotplug. Is this really necessary? Else I could unmerge hotplug.
net-wireless/ipw2100-firmware should not depend on hotplug since hotplug is no longer executed and used if you have udev on your system.
Why is hotplug not being removed from the system when you upgrade to a new version of udev? Why is there no remark _after_ emerging udev about big collisions with hotplug? The combination of hotplug and a up-to-date version of udev is a system-killer after you reboot!
A simple message would solve a lot of sweat and be very user friendly.
Thank you for your Feedback.
*** Bug 228289 has been marked as a duplicate of this bug. ***
Maybe we should finally add the blocker, and just break the remaining issues so they get fixed soon.
OR: Set a fixed date when to add the blocker. Lets say the 2008/07/19.
Yes, this would make sense. Last but not least for the normal user.
Can't we just package.mask hotplug on the kernel-2.6 profiles?
is there anything holding this back now?
(In reply to comment #28)
> is there anything holding this back now?
Bump. There are no blockers left.
CC treecleaner. Mostly those packages have || ( ) dependency for hotplug, so it can be simply dropped from it. Then sys-
I guess sys-apps/coldplug can go too. Nothing depends on it.
# Samuli Suominen <email@example.com> (22 Jan 2012)
# Remove coldplug, hotplug and hotplug-base in 30 days wrt bug #145809
They are gone.