Created attachment 342152 [details, diff] udev-init-scripts-24-fix_no_coldplug.patch When booting with rc_coldplug="NO" into X, USB keyboard and USB mouse are not working leaving the user with an unuseable system. The attached patch fixes this problem.
Hello, can you please test the patch above for udev-init-scripts-24 and see if it triggers the issue in bug #424189 again? Thanks, William
sounds bad, but isn't that the purpose of "no coldplug" that there will be no coldplug, like for drivers of input devices? that the user needs to add those into the loadable module list himself?
The affected drivers are compiled into the kernel. What still needs to be done is to create necessary symlinks and adjust permissions. That's what the patch tries to achieve. When you look into older udev start scripts you will see that this command was executed when coldplug is disabled.
(In reply to comment #2) > sounds bad, but isn't that the purpose of "no coldplug" that there will be > no coldplug, like for drivers of input devices? that the user needs to add > those into the loadable module list himself? I'm tending to agree with this interpretation. The purpose of rc_coldplug="no" or "nocoldplug" on the kernel command line is to skip the entire coldplug sequence. (In reply to comment #3) > The affected drivers are compiled into the kernel. What still needs to be > done is to create necessary symlinks and adjust permissions. That's what the > patch tries to achieve. > When you look into older udev start scripts you will see that this command > was executed when coldplug is disabled. I know that, but the question is, given the bug in comment #1, should it have been? In other words, what does the patch do if things are not built into the kernel? Does it make the modules load?
(In reply to comment #4) > (In reply to comment #2) > > sounds bad, but isn't that the purpose of "no coldplug" that there will be > > no coldplug, like for drivers of input devices? that the user needs to add > > those into the loadable module list himself? > > I'm tending to agree with this interpretation. The purpose of > rc_coldplug="no" or "nocoldplug" on the kernel command line is to skip the > entire coldplug sequence. Can you please stop making false assumptions? This bug is about rc_coldplug="NO" now being really broken because udev does not even take action for already existing devices which need adjustment through existing udev-rules. > (In reply to comment #3) > > The affected drivers are compiled into the kernel. What still needs to be > > done is to create necessary symlinks and adjust permissions. That's what the > > patch tries to achieve. > > When you look into older udev start scripts you will see that this command > > was executed when coldplug is disabled. > > I know that, but the question is, given the bug in comment #1, should it > have been? In other words, what does the patch do if things are not built > into the kernel? Does it make the modules load? l'm not at home right now and thus cannot test the module loading. Although I doubt the patch will lead to automatic module loading (like I said before, this command was executed in older udev start scripts when coldplug was disabled) I will test it as soon as I return to my Gentoo test machine.
(In reply to comment #5) > (In reply to comment #4) > > (In reply to comment #2) > > > sounds bad, but isn't that the purpose of "no coldplug" that there will be > > > no coldplug, like for drivers of input devices? that the user needs to add > > > those into the loadable module list himself? > > > > I'm tending to agree with this interpretation. The purpose of > > rc_coldplug="no" or "nocoldplug" on the kernel command line is to skip the > > entire coldplug sequence. > > Can you please stop making false assumptions? This bug is about > rc_coldplug="NO" now being really broken because udev does not even take > action for already existing devices which need adjustment through existing > udev-rules. I am not making a false assumption. If you look at the definition of nohotplug (which will be another bug because there is no such option) on the livecd, it states that it disables the cold/hotplug "init scripts" at boot. > > (In reply to comment #3) > > > The affected drivers are compiled into the kernel. What still needs to be > > > done is to create necessary symlinks and adjust permissions. That's what the > > > patch tries to achieve. > > > When you look into older udev start scripts you will see that this command > > > was executed when coldplug is disabled. > > > > I know that, but the question is, given the bug in comment #1, should it > > have been? In other words, what does the patch do if things are not built > > into the kernel? Does it make the modules load? > > l'm not at home right now and thus cannot test the module loading. Although > I doubt the patch will lead to automatic module loading (like I said before, > this command was executed in older udev start scripts when coldplug was > disabled) I will test it as soon as I return to my Gentoo test machine. This is what we need to know. If it doesn't lead to automatic module loading, I don't have a problem with applying it.
Here are the results. Prerequisite is my attached patch being applied to the udev init script. Booting with rc_coldplug="YES" I get the following: root@shanghai:~ # lsmod Module Size Used by snd_hda_codec_realtek 56258 1 snd_hda_intel 22963 0 snd_emu10k1 130001 0 snd_hwdep 5724 1 snd_emu10k1 snd_util_mem 2147 1 snd_emu10k1 snd_ac97_codec 104592 1 snd_emu10k1 ac97_bus 901 1 snd_ac97_codec snd_rawmidi 17295 1 snd_emu10k1 snd_hda_codec 69280 2 snd_hda_codec_realtek,snd_hda_intel snd_seq_device 4756 2 snd_rawmidi,snd_emu10k1 snd_pcm 70489 4 snd_ac97_codec,snd_hda_codec,snd_hda_intel,snd_emu10k1 microcode 7790 0 pcspkr 1835 0 snd_page_alloc 6754 3 snd_pcm,snd_hda_intel,snd_emu10k1 snd_timer 17591 2 snd_pcm,snd_emu10k1 snd 51899 10 snd_hda_codec_realtek,snd_ac97_codec,snd_hwdep,snd_timer,snd_pcm,snd_rawmidi,snd_hda_codec,snd_hda_intel,snd_emu10k1,snd_seq_device soundcore 4930 1 snd Booting with rc_coldplug="NO" I get the following: root@shanghai:~ # lsmod Module Size Used by microcode 7790 0 The one module gets triggered by /etc/conf.d/modules: root@shanghai:~ # grep -v "^[[:space:]]*\(#.*\|\)$" /etc/conf.d/modules modules="microcode" shanghai:~ #
I was reading IRC log from today: <Poly-C_atwork> WilliamH: I already did. But I stumbled about another bug. Even with "udevadm trigger --attr-match=dev" the devices won't get processed properly. For example I get segfaults in r600g_dri.so because all devices in /dev/dri/ are only readable by root. So I suspect udev currently is buggy because it should still process already existing devices on startup to get permissions right. How about adding both, first: udevadm trigger --attr-match=dev Then the remainining ones which make sense, like ensuring we get the input devices and graphics: udevadm trigger --subsystem-match=drm --subsystem-match=input
Do we really want to maintain this type of hack at all? Since it is a hack at most: 14:19 < kay> you are skipping coldplug but expect /dev to be proper? :) Then Kay suggested "udevadm trigger --attr-match=dev --action=add": 14:22 < kay> ssuominen: try: udevadm trigger --action=add --attr-match=dev 14:22 < kay> ssuominen: it might still load a few modules, but almost all of them should be skipped
(In reply to comment #9) > Do we really want to maintain this type of hack at all? Since it is a hack > at most: > > 14:19 < kay> you are skipping coldplug but expect /dev to be proper? :) > > Then Kay suggested "udevadm trigger --attr-match=dev --action=add": > > 14:22 < kay> ssuominen: try: udevadm trigger --action=add --attr-match=dev > 14:22 < kay> ssuominen: it might still load a few modules, but almost all of > them should be skipped Honestly, I have kept this even though I didn't know why we have it. I'm not sure any other distros offer an option to allow skipping the coldplug sequence, and I wouldn't have a problem dropping it if there isn't really a use case for it. @poly-c: Can you please elaborate on why you feel we should have this function?
(In reply to comment #10) > (In reply to comment #9) > > Do we really want to maintain this type of hack at all? Since it is a hack > > at most: > > > > 14:19 < kay> you are skipping coldplug but expect /dev to be proper? :) > > > > Then Kay suggested "udevadm trigger --attr-match=dev --action=add": > > > > 14:22 < kay> ssuominen: try: udevadm trigger --action=add --attr-match=dev > > 14:22 < kay> ssuominen: it might still load a few modules, but almost all of > > them should be skipped > > Honestly, I have kept this even though I didn't know why we have it. I'm > not sure any other distros offer an option to allow skipping the coldplug > sequence, and I wouldn't have a problem dropping it if there isn't really a > use case for it. > > @poly-c: > Can you please elaborate on why you feel we should have this function? I don't want to have udev loading kernel modules during the boot process. I just want udev to handle device nodes nothing else. A couple of years ago udev's module loading could be prevented by disabling coldplugging. udev then simply processed all available devices, fixed permissions and ownership according to existing udev rules and all was fine. When sys-fs/udev-init-scripts were introduced this no longer worked until recent change to udev-init-scripts-24. But now existing devices won't get processed anymore by udev. Oh and before you come up with it, blacklisting all modules is no option for me. Kay's suggestion works. So I gonna attach a "fixed" patch.
Created attachment 342460 [details, diff] udev-init-scripts-24-fix_no_coldplug.patch Patch with Kay's suggestion. This works for me and re-establishes the disabled coldplug functionality I know from older udev versions.
(In reply to comment #12) > Created attachment 342460 [details, diff] [details, diff] > udev-init-scripts-24-fix_no_coldplug.patch > > Patch with Kay's suggestion. > This works for me and re-establishes the disabled coldplug functionality I > know from older udev versions. cool, I would like us of course to keep this functionality, but: may I also suggest renaming this rc_coldplug= option to rc_trigger_only_with_attrs_dev= ? would be more clear
(In reply to comment #13) > (In reply to comment #12) > > Created attachment 342460 [details, diff] [details, diff] [details, diff] > > udev-init-scripts-24-fix_no_coldplug.patch > > > > Patch with Kay's suggestion. > > This works for me and re-establishes the disabled coldplug functionality I > > know from older udev versions. > > cool, I would like us of course to keep this functionality, but: > > may I also suggest renaming this rc_coldplug= option to > rc_trigger_only_with_attrs_dev= ? > would be more clear rather, rc_add_only_with_attrs_dev=, but whatever, it's just bikeshedding
We would also have to rename the kernel command line option. We currently use nocoldplug to indicate that we do not want the coldplug sequence to be run (see the get_bootparam call). Any ideas?
(In reply to comment #15) > We would also have to rename the kernel command line option. We currently > use nocoldplug to indicate that we do not want the coldplug sequence to be > run (see the get_bootparam call). > > Any ideas? then leave it and just apply the patch, imho
This is fixed in commit 5eed3ed. I also added an einfo so that users will know that /dev permissions and symbolic links are being set. This will be part of udev-init-scripts 25. Thanks for the report.
