The default kernel config for amd64 contains CONFIG_UEVENT_HELPER="/sbin/udevadm". Based on the description of the option, this really doesn't make any sense; I don't think udevadm does anything with the events. udevd uses the netlink interface, so it doesn't need this anyway. I think it should be changed to an empty string, or possibly the upstream default (/sbin/hotplug).
Futhermore /sbin/udevadm is the obsolete location and the new one is /bin/udevadm. There is a compability symlink over to /sbin/udevadm which will go away at some point. Empty string sounds good to me.
(In reply to Samuli Suominen from comment #1) > Futhermore /sbin/udevadm is the obsolete location and the new one is > /bin/udevadm. > There is a compability symlink over to /sbin/udevadm which will go away at > some point. FYI, this compability symlink no longer exists in stable udev, or systemd for that matter
17:00 <@ssuominen> genkernel is really abandoned entirely? 17:00 <@ssuominen> i wonder if we should proceed with lastriting it, been broken for more than year now regarding it's default kernel config, like bug 461828 17:00 <+willikins> ssuominen: https://bugs.gentoo.org/461828 "sys-kernel/genkernel: Default config for amd64 sets CONFIG_UEVENT_HELPER="/sbin/udevadm""; Gentoo Hosted Projects, genkernel; CONF; floppym:genkernel 17:01 <@ssuominen> ~400 days should be enough to give people time to fix it 17:02 <@Zero_Chaos> ssuominen: genkernel isn't abandoned at all, but I believe they expect the arch teams to maintain the kernel configs. 17:02 <@ssuominen> ok, CCing amd64@ then to take responsibility... -> CC amd64@g.o
This is NOT critical issue, this option is completely deprecated on new kernels(i set up this to empty string around 3.0 and did not have problems from that time). Non-existant binaries, that you may try to put there will be simple ignored. However, for the sake of consistency, this should be empty string in default config too.
Created attachment 376820 [details, diff] patch for genkernel <amd64 hat> Dear genkernel maintaners, please apply attached patch to genkernel repo, thanks in advance. </amd64 hat>
(In reply to Sergey Popov from comment #4) > This is NOT critical issue, this option is completely deprecated on new > kernels(i set up this to empty string around 3.0 and did not have problems > from that time). Non-existant binaries, that you may try to put there will > be simple ignored. > > However, for the sake of consistency, this should be empty string in default > config too. I have this option in 3.13.4 kernel, and current stable is 3.12, so the issue is still critical
lvm2 has some issues that are triggered when the uevent helper is not found or exits with non-zero status. I don't have the bug(s) handy. I'm not sure I would call this "critical", but it is more than minor.
(In reply to Sergey Popov from comment #5) > Created attachment 376820 [details, diff] [details, diff] > patch for genkernel > > <amd64 hat> > Dear genkernel maintaners, please apply attached patch to genkernel repo, > thanks in advance. > </amd64 hat> What about applying it in our ebuilds until it lands genkernel repo?
(In reply to Samuli Suominen from comment #6) > (In reply to Sergey Popov from comment #4) > > This is NOT critical issue, this option is completely deprecated on new > > kernels(i set up this to empty string around 3.0 and did not have problems > > from that time). Non-existant binaries, that you may try to put there will > > be simple ignored. > > > > However, for the sake of consistency, this should be empty string in default > > config too. > > I have this option in 3.13.4 kernel, and current stable is 3.12, so the > issue is still critical You do not get my point. Incorrect set of this option leading to no damage at all. No unbootable systems. No missing udev events. So, i do not understand why this is marked critical again. But, as i said earlier, no doubt that it should be fixed
(In reply to Mike Gilbert from comment #7) > lvm2 has some issues that are triggered when the uevent helper is not found > or exits with non-zero status. I don't have the bug(s) handy. > > I'm not sure I would call this "critical", but it is more than minor. Ahhh... LVM stuff. Yeah, that maybe a culprit if non-udev device detection is not enabled. So yeah, it can be called critical, i was wrong.
the incorrect setting breaks lvm2 as pointed out, here are the links, https://www.redhat.com/archives/linux-lvm/2012-August/msg00025.html https://bugs.gentoo.org/show_bug.cgi?id=479756
See also: bug 493874
found more broken arches, genkernel-3.4.49.1/arch/x86/kernel-config:CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" genkernel-3.4.49.1/arch/alpha/kernel-config:CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" genkernel-3.4.49.1/defaults/kernel-config:CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
If no one is maintaining the configs, perhaps we should simply make defconfig or the releng configs default? Not that the releng configs are any more up to date mind you, but at least that's one set of gentoo specific kernel configs to neglect instead of two...
(In reply to Rick Farina (Zero_Chaos) from comment #14) > If no one is maintaining the configs, perhaps we should simply make > defconfig or the releng configs default? Not that the releng configs are > any more up to date mind you, but at least that's one set of gentoo specific > kernel configs to neglect instead of two... Speaking for the x86 team, we'd support either making the releng configs default or making `make allmodconfig` the default. Personally, I feel a lot of people need genkernel to just work and would either spend the extra time compiling to have it "just work" or, if they couldn't afford the compile time, they'd be well-versed enough to know about genkernel --menuconfig to disable the stuff they don't need.
(In reply to Samuli Suominen from comment #11) > the incorrect setting breaks lvm2 as pointed out, here are the links, > > https://www.redhat.com/archives/linux-lvm/2012-August/msg00025.html > https://bugs.gentoo.org/show_bug.cgi?id=479756 Yes, this broke infra boxes. We had to update the kernel config to clear that setting. (In reply to Rick Farina (Zero_Chaos) from comment #14) > If no one is maintaining the configs, perhaps we should simply make > defconfig or the releng configs default? Not that the releng configs are > any more up to date mind you, but at least that's one set of gentoo specific > kernel configs to neglect instead of two... The releng kernel configs for amd64 / x86 have been kept by me. I've been doing updates every 6 months / 1 year - so they're not that "old". In any case, someone needs to step up and maintain the configs for every affected arch.
Sorry, I don't want to be a drama queen (as someone said), but I really would rather avoid getting pulled in by force to the genkernel development :-(
(In reply to Samuli Suominen from comment #17) > Sorry, I don't want to be a drama queen (as someone said), but I really > would rather avoid getting pulled in by force to the genkernel development > :-( Why don't we simply apply the patch from comment #5 to the ebuild? Also, why don't we move from genkernel to genkernel-next? :/
InCVS
