|Summary:||sys-apps/coldplug, sys-apps/hotplug, sys-apps/hotplug-base removal request|
|Product:||Gentoo Linux||Reporter:||Heiko Baums <heiko>|
|Component:||New packages||Assignee:||No maintainer - Look at https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers if you want to take care of it <maintainer-needed>|
|Severity:||major||CC:||amigadave, kanelxake, kripton, rhill, robbat2, roy, thomas.mey, uberlord, zdavatz, ziga.boehm|
|Package list:||Runtime testing required:||---|
|Bug Depends on:||72485, 129882, 158114, 159931, 162183, 162185, 162190, 162201, 162205, 163610, 209966, 210079, 210082, 210085, 210088|
|Bug Blocks:||74850, 82729, 99038, 104962, 124427, 130540, 130638, 131244, 144388, 145187, 147006|
|Attachments:||disable hotplugd-calling for compatibility|
Description Heiko Baums 2006-08-31 22:48:53 UTC
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: bug #142604 bug #143660 bug #145805
Comment 1 Greg Kroah-Hartman (RETIRED) 2006-09-01 03:05:26 UTC
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...
Comment 2 Jakub Moc (RETIRED) 2006-09-18 12:50:53 UTC
*** Bug 148104 has been marked as a duplicate of this bug. ***
Comment 3 Jakub Moc (RETIRED) 2006-11-29 09:49:21 UTC
Reopen to dupe.
Comment 4 Jakub Moc (RETIRED) 2006-11-29 09:50:29 UTC
*** This bug has been marked as a duplicate of 147006 ***
Comment 5 Jakub Moc (RETIRED) 2007-01-15 11:48:09 UTC
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.
Comment 6 Matthias Schwarzott 2007-01-15 12:30:57 UTC
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.
Comment 7 Matthias Schwarzott 2007-01-15 16:08:32 UTC
udev-103-r1 no longer calls scripts in hotplug dir.
Comment 8 Jakub Moc (RETIRED) 2007-01-15 18:56:03 UTC
(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?
Comment 9 Greg Kroah-Hartman (RETIRED) 2007-01-15 19:53:46 UTC
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 :(
Comment 10 Jakub Moc (RETIRED) 2007-01-15 21:22:25 UTC
(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?
Comment 11 Roy Marples (RETIRED) 2007-01-16 07:10:31 UTC
(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 :/
Comment 12 Greg Kroah-Hartman (RETIRED) 2007-01-16 07:39:08 UTC
(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...
Comment 13 Roy Marples (RETIRED) 2007-01-16 08:03:14 UTC
(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.
Comment 14 Robin Johnson 2007-01-16 08:07:07 UTC
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.
Comment 15 Robin Johnson 2007-01-16 08:09:51 UTC
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
Comment 16 Robin Johnson 2007-01-16 08:27:10 UTC
uberlord: 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.
Comment 17 Roy Marples (RETIRED) 2007-01-16 13:11:42 UTC
(In reply to comment #16) > uberlord: > 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. 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.
Comment 18 Doug Goldstein (RETIRED) 2007-01-16 20:22:06 UTC
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....
Comment 19 Jakub Moc (RETIRED) 2007-01-21 18:40:44 UTC
*** Bug 163106 has been marked as a duplicate of this bug. ***
Comment 20 Jakub Moc (RETIRED) 2007-05-05 10:59:32 UTC
Any issues w/ p.masking hotplug anywhere but on 2.4 profiles (plus doing some udev versions cleanup)?
Comment 21 Jens-Uwe Peter 2007-06-19 06:44:41 UTC
net-wireless/ipw2100-firmware depends on hotplug. Is this really necessary? Else I could unmerge hotplug.
Comment 22 Doug Goldstein (RETIRED) 2007-06-19 15:05:42 UTC
net-wireless/ipw2100-firmware should not depend on hotplug since hotplug is no longer executed and used if you have udev on your system.
Comment 23 Zeno Davatz 2008-06-19 14:38:52 UTC
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. Best Zeno
Comment 24 Doug Goldstein (RETIRED) 2008-06-19 15:01:56 UTC
*** Bug 228289 has been marked as a duplicate of this bug. ***
Comment 25 Matthias Schwarzott 2008-06-19 16:06:15 UTC
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.
Comment 26 Zeno Davatz 2008-06-19 16:43:12 UTC
Yes, this would make sense. Last but not least for the normal user. Best Zeno
Comment 27 Matthias Schwarzott 2008-11-06 08:39:12 UTC
Can't we just package.mask hotplug on the kernel-2.6 profiles?
Comment 28 Ryan Hill (RETIRED) 2009-03-08 07:41:42 UTC
is there anything holding this back now?
Comment 29 James Broadhead 2010-11-08 17:14:29 UTC
(In reply to comment #28) > is there anything holding this back now? > Bump. There are no blockers left.
Comment 30 Samuli Suominen (RETIRED) 2013-01-20 10:40:54 UTC
http://qa-reports.gentoo.org/output/genrdeps/rindex/sys-apps/hotplug-base media-tv/wis-go7007-0.9.8-r3 sys-apps/hotplug-20040923-r1 sys-apps/hotplug-20040923-r2 http://qa-reports.gentoo.org/output/genrdeps/rindex/sys-apps/hotplug app-emulation/xen-tools-4.1.1-r6 app-emulation/xen-tools-4.1.2-r2 app-emulation/xen-tools-4.1.2-r3 app-emulation/xen-tools-4.2.0-r1 app-emulation/xen-tools-4.2.0-r2 media-tv/ivtv-1.0.1 media-tv/ivtv-1.0.2 media-tv/ivtv-1.0.3-r2 media-tv/wis-go7007-0.9.8-r3 net-dialup/capi4k-utils-20050718-r3:usb net-wireless/at76c503a-0.16 net-wireless/at76c503a-9999 net-wireless/atmel-firmware-1.3-r1 net-wireless/ipw2100-firmware-1.3 net-wireless/ipw2200-firmware-2.2 net-wireless/ipw2200-firmware-2.4:kernel_linux net-wireless/ipw2200-firmware-3.1 net-wireless/ipw3945-ucode-1.13 net-wireless/ipw3945-ucode-1.14.2 net-wireless/prism54-firmware-18.104.22.168 net-wireless/prism54-firmware-2.13 net-wireless/rt2860-firmware-34 net-wireless/rt2870-firmware-29 net-wireless/rt61-firmware-1.2 net-wireless/rt73-firmware-1.8-r1 net-wireless/zd1201-firmware-0.14 net-wireless/zd1211-firmware-1.2 net-wireless/zd1211-firmware-1.3 net-wireless/zd1211-firmware-1.4 sys-apps/coldplug-20040920 sys-apps/ezusb2131-1.0 sys-fs/iprutils-2.2.18 sys-fs/iprutils-2.2.19 sys-fs/iprutils-2.3.0 sys-fs/iprutils-2.3.9 CC treecleaner. Mostly those packages have || ( ) dependency for hotplug, so it can be simply dropped from it. Then sys-
Comment 31 Samuli Suominen (RETIRED) 2013-01-20 10:48:06 UTC
I guess sys-apps/coldplug can go too. Nothing depends on it.
Comment 32 Samuli Suominen (RETIRED) 2013-01-21 22:39:07 UTC
# Samuli Suominen <email@example.com> (22 Jan 2012) # Remove coldplug, hotplug and hotplug-base in 30 days wrt bug #145809 sys-apps/ezusb2131 sys-apps/hotplug sys-apps/hotplug-base sys-apps/coldplug
Comment 33 Samuli Suominen (RETIRED) 2013-02-08 17:36:19 UTC
They are gone.