According to my own results, and now eselect news read: sys-fs/udev-217 and sys-fs/eudev-2.1 no longer provide a userspace firmware loader. If you require firmware loading support, you must use kernel 3.7 or greater with CONFIG_FW_LOADER_USER_HELPER=n. However, I am unable to turn off CONFIG_FW_LOADER_USER_HELPER via menuconfig, and removing it by hand from .config results in kernel panics on boot. symptom: if CONFIG_FW_LOADER_USER_HELPER=y, boot hangs waiting for udev events if # CONFIG_FW_LOADER_USER_HELPER is not set (edited by hand), kernel crashes on boot reproduce: emerge gentoo-sources cd /usr/src/linux make menuconfig navigate to Drivers->Generic Options, and you will find CONFIG_FW_LOADER_USER_HELPER cannot be turned off hand editing .config to turn the option off has the above results (kernel crashes on boot) kernel: 3.16.7-gentoo eudev: 2.1.1 Intel Processor: Intel(R) Xeon(R) CPU E5-2620 0 @ 2.00GHz Video: NVIDIA Corporation G84GL [Quadro FX 570]
Don't hand-edit .config, it's not safe. On later kernel versions, you should disable FW_LOADER_USER_HELPER_FALLBACK (Prompt: Fallback user-helper invocation for firmware loading) in menuconfig, and that will automatically disable the hidden FW_LOADER_USER_HELPER option.
That does not appear to be possible: -*- Fallback user-helper invocation for firmware loading This option cannot be changed in menuconfig. I tried the vanilla-sources as well, thinking this might be a gentoo-ism, but this option appears to be forced on everywhere. I have been googling for over an hour trying to figure out how to disable it, and while plenty of people say "disable it", no one seems to indicate what option you need to change to be able to disable it safely. This option remains locked on a completely clean, unconfigured kernel, as well as kernels with genkernel generated configs.
You need to learn a few tricks of using menuconfig. When something is forced on like that, do NOT go and hand-edit .config, it's forced on for a reason. Read the help on that option to see what it's "Selected by:"
Thank you. I've been doing this for many years (including hand editing .config on occasion, always without issue until now), and hadn't ever noticed "selected by" in the menu-config help. You learn something new every day! For those who may be looking for a solution, it appear the vanilla sources, and gentoo-sources + genkernel by extension, select DELL_RBU [=m] by default. Navigate to Firmware-Drivers and unselect this, then navigate back up to Device Drivers->Generic Driver Options to (Finally!) turn off "Fallback user-helper invocation for firmware loading"
I'm glad you've worked around it, I'm going to convert this bug into one addressing the DELL_RBU default, thanks for pointing out that detail. @genkernel - we need to disable this (rarely used) DELL_RBU option, since it's forcing CONFIG_FW_LOADER_USER_HELPER=y, and this option will be a problem for newer udev versions. The details of that are mentioned in news item 2014-11-07-udev-upgrade.
Interesting. The Dell desktop PC I'm working on will not boot without the Dell firmware support, which in turn forces CONFIG_FW_LOADER_USER_HELPER=y, so unless I'm missing something, anyone wanting to boot linux on a Dell cannot use eudev >= 2.1 or udev >= 217. I'm not exactly a Dell enthusiast, but either I'm missing something obvious (I hope), or Poettering & Co. have just unloaded a 30-round high-calibre magazine into the foot of Linux.
You need DELL_RBU support to *boot*? That option is for *updating* your BIOS from within linux. FWIW I boot lots and lots of Dells without that option.
It really shouldn't. The whole thing is odd. I recompiled the kernel with that change and the machine won't boot. I'm installing a minimalistic gentoo on the box to see if I can get to the bottom of what is going on (maybe the nvidia blob is running interference for example). Either way changing the defaults to match the current recommendation would be awesome, and probably save a lot of us quite a bit of time.
OK, I've done some more digging, and this is getting interesting. I installed a fairly minimal gentoo. I also swapped a Radeon card for an NVidia card. (Although I do not have nvidia drivers installed, I wanted to see if the video firmware was running some kind of interference. It isn't.) hardware: Dell Precision T5600 (PERC Card) and T5610 (built in RAID controller) RAID mode: attempted all: RAID, ACHI, ATA (do difference, firmware is loaded regardless) kernel: 3.16.7-gentoo udev: 216-r1 [USE="acl firmware-loader gudev introspection kmod -doc (-selinux) -static-libs" ABI_X86="(64) -32 (-x32)"] I get kernel panics on boot (VFS unable to open UUID=blah) when I turn off the DELL_RBU and CONFIG_FW_LOADER_USER_HELPER in menuconfig, and get perfectly fine boots if I enable them. Just for the hell of it, I recompiled the kernel with DELL_BRU left off, but CONFIG_FW_LOADER_USER_HELPER=y, and lo and behold ... it still crashes out with the same error as above. It appears the RAID device is relying on DELL_BRU on every boot, maybe "upgrading" its firmware on the fly at each boot? Very strange. The solution appears to be to either dump the raid device completely, and connect via the SATA controller ONLY, or mask newer eudev/udev versions and leave the DELL_BRU setting on (maybe there is another approach I'm not aware of?). Either way, there are going to be a whole lot of Dell Precision T56xx owners who feel pain with this change becomes mainstream. Editorial: I really, really wish the eudev folks hadn't followed Poettering down this particular road to hell. I know their hearts are in the right place, wanting a udev drop-in replacement that doesn't shove systemd and/or gnome3 down our throats, and I heartily applaud them for it, but I think having firmware fallback support (at least for a few years yet, while hardware like this is still around...and this is a fairly new box btw) would have been a wonderful differentiator between stock/broken udev and the forked, much superior eudev. I think issues like this, where installing eudev with firmware-loader support would have been the obvious solution, would have won them tremendous mind-share during a critical time. Oh well, this has been an interesting problem to study nonetheless.
The solution I ended up having to use on both Dells was to mask newer eudev and udev versions. I was unable to get the machine to boot at all without DELL_RBU [=m] (and by extension, CONFIG_FW_LOADER_USER_HELPER=y). Dumping the raid controller wasn't an option, since one of the two remaining SATA ports is used by the DVD+RW and both are excruciatingly slow by comparison. I really hope a sensible workaround exists before the older eudev and udev get dropped from the tree. I foresee a great deal of pain for a lot of people ... I doubt very this is the only hardware combination that has peculiar firmware requirements that were, until now, met by having udev handle the firmware update and/or loading.
Looks like kernels >=3.17 contains the following fix: https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/base/firmware_class.c?id=5a1379e8748a5cfa3eb068f812d61bde849ef76c
(In reply to Alexander Tsoy from comment #11) > Looks like kernels >=3.17 contains the following fix: > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/ > drivers/base/firmware_class.c?id=5a1379e8748a5cfa3eb068f812d61bde849ef76c If I read this correctly, that means that on >=3.17 kernels, our udev/systemd ebuilds need to ensure FW_LOADER_USER_HELPER_FALLBACK is disabled, but FW_LOADER_USER_HELPER itself is safe... right?
(In reply to Ben Kohler from comment #12) Right. BTW I posted incorrect link. Correct one: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5a1379e8748a5cfa3eb068f812d61bde849ef76c And according to the following commit the above patch was first appeared in 3.17-rc1 https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=29b88e23a9212136d39b0161a39afe587d0170a5
I just wanted to confirm, that per the link Alexander posted (https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5a1379e8748a5cfa3eb068f812d61bde849ef76c) the following does work now: FW_LOADER_USER_HELPER=n LATTICE_ECP3_CONFIG=y DELL_RBU=y Tested with sys-kernel/gentoo-sources-4.0.1 sys-fs/eudev-3.0 virtual/udev-217 I think with these values supported by genkernel (and kernels >3.17 in general) it is safe to mark this bug us fixed. Thank you again to everyone for all the help.
Sounds good to me
