udev-217 stalls booting

[Fitzcarraldo]

With sys-fs/udev-216-r1 installed, my OpenRC-based installation boots quickly and without apparent problems.

With sys-fs/udev-217 installed, my OpenRC-based installation hangs for a long time when booting, waiting for uevents to be processed. When eventually booting continues and I login to KDE via KDM, the KWin Hardware Temperature Settings widget on the Deskstop shows the temperature as 0.0 degrees C for the CPU's four cores.

The kernel is the same in both cases: 3.13.7-gentoo.

The problem is consistently reproducible. Reinstalling sys-fs/udev-216-r1 makes everything work as expected. Reinstalling sys-fs/udev-217 results in the booting delay and the CPU cores' temperatures being shown as 0.0 by the KWin widget.

With sys-fs/udev-216-r1, VT1 looks like this during boot:

Code: Select all

INIT: version 2.88 booting

   OpenRC 0.13.2 is starting up Gentoo Linux (x86_64)

 * /proc is already mounted
 * Mounting /run ...
 * /run/openrc: creating directory
 * /run/lock: creating directory
 * /run/lock: correcting owner
 * Remounting devtmpfs on /dev ...
 * Mounting /dev/mqueue ...
 * Mounting /dev/shm ...
 * Mounting security filesystem ...
 * Mounting debug filesystem ...
 * Mounting cgroup filesystem ...
 * Mounting fuse control filesystem ...
 * Loading module xt_LOG ...
 * Loading module vboxdrv ...
 * Loading module vboxnetflt ...
 * Loading module vboxnetadp ...
 * Autoloaded 4 module(s)
 * setting up tmpfiles.d entries for /dev ...
 * Starting udev ...
 * Generating a rule to create a /dev/root/ symlink ...
 * Populating /dev with existing devices through uevents ...
 * Waiting for uevents to be processed ...

and the boot process continues so quickly that I cannot photograph the rest.

With sys-fs/udev-217, VT1 looks like this during boot:

Code: Select all

INIT: version 2.88 booting

   OpenRC 0.13.2 is starting up Gentoo Linux (x86_64)

 * /proc is already mounted
 * Mounting /run ...
 * /run/openrc: creating directory
 * /run/lock: creating directory
 * /run/lock: correcting owner
 * Remounting devtmpfs on /dev ...
 * Mounting /dev/mqueue ...
 * Mounting /dev/shm ...
 * Mounting security filesystem ...
 * Mounting debug filesystem ...
 * Mounting cgroup filesystem ...
 * Mounting fuse control filesystem ...
 * Loading module xt_LOG ...
 * Loading module vboxdrv ...
 * Loading module vboxnetflt ...
 * Loading module vboxnetadp ...
 * Autoloaded 4 module(s)
 * setting up tmpfiles.d entries for /dev ...
 * Starting udev ...
starting version 217
 * Generating a rule to create a /dev/root/ symlink ...
 * Populating /dev with existing devices through uevents ...
 * Waiting for uevents to be processed ...

and the console display hangs for a long time. Eventually some additional lines appear at the bottom:

Code: Select all

INIT: version 2.88 booting

   OpenRC 0.13.2 is starting up Gentoo Linux (x86_64)

 * /proc is already mounted
 * Mounting /run ...
 * /run/openrc: creating directory
 * /run/lock: creating directory
 * /run/lock: correcting owner
 * Remounting devtmpfs on /dev ...
 * Mounting /dev/mqueue ...
 * Mounting /dev/shm ...
 * Mounting security filesystem ...
 * Mounting debug filesystem ...
 * Mounting cgroup filesystem ...
 * Mounting fuse control filesystem ...
 * Loading module xt_LOG ...
 * Loading module vboxdrv ...
 * Loading module vboxnetflt ...
 * Loading module vboxnetadp ...
 * Autoloaded 4 module(s)
 * setting up tmpfiles.d entries for /dev ...
 * Starting udev ...
starting version 217
 * Generating a rule to create a /dev/root/ symlink ...
 * Populating /dev with existing devices through uevents ...
 * Waiting for uevents to be processed ...
worker [4212] /devices/system/cpu/cpu3 is taking a long time
worker [4218] /devices/system/cpu/cpu0 is taking a long time
worker [4223] /devices/system/cpu/cpu1 is taking a long time
worker [4224] /devices/system/cpu/cpu2 is taking a long time
worker [4225] /devices/system/cpu/cpu4 is taking a long time
worker [4226] /devices/system/cpu/cpu5 is taking a long time
worker [4227] /devices/system/cpu/cpu6 is taking a long time
worker [4241] /devices/system/cpu/cpu7 is taking a long time

After a further delay, the boot process continues and the KDM log-in screen is displayed.

/var/log/messages contains the following messages when booting with sys-fs/udev-217 installed:

Code: Select all

# cat /var/log/messages | grep 08\:2 | grep microcode
Oct 31 08:24:43 meshedgedx kernel: microcode: CPU4 sig=0x106e5, pf=0x10, revision=0x3
Oct 31 08:24:43 meshedgedx kernel: platform microcode: Direct firmware load failed with error -2
Oct 31 08:24:43 meshedgedx kernel: platform microcode: Falling back to user helper
Oct 31 08:25:43 meshedgedx kernel: microcode: CPU5 sig=0x106e5, pf=0x10, revision=0x3
Oct 31 08:25:43 meshedgedx kernel: platform microcode: Direct firmware load failed with error -2
Oct 31 08:25:43 meshedgedx kernel: platform microcode: Falling back to user helper
Oct 31 08:26:43 meshedgedx kernel: microcode: CPU6 sig=0x106e5, pf=0x10, revision=0x3
Oct 31 08:26:43 meshedgedx kernel: platform microcode: Direct firmware load failed with error -2
Oct 31 08:26:43 meshedgedx kernel: platform microcode: Falling back to user helper
Oct 31 08:27:43 meshedgedx kernel: microcode: CPU7 sig=0x106e5, pf=0x10, revision=0x3
Oct 31 08:27:43 meshedgedx kernel: platform microcode: Direct firmware load failed with error -2
Oct 31 08:27:43 meshedgedx kernel: platform microcode: Falling back to user helper
Oct 31 08:28:43 meshedgedx kernel: microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba

Is any one else experiencing problems with sys-fs/udev-217?

[Roman_Gruber]

well i ditched udev for eudev and these hang was gone on my box.

[Fitzcarraldo]

Well, if I understand correctly the post Switching to eudev, switching from udev to eudev would take:

Code: Select all

cat /usr/src/linux/.config | grep CONFIG_FHANDLE # Make sure it is "y".
CONFIG_FHANDLE=y
echo "sys-fs/eudev -rule-generator" >> /etc/portage/package.use
emerge -avC udev
emerge -av eudev
etc-update
emerge @preserved-rebuild
/etc/init.d/udev --nodeps restart
rc-update add udev-postmount

Is the above correct? Is that what I need to do? What exactly does the USE flag rule-generator do?

What about the Predictable Network Interface Names mess (yet another bright idea from freedesktop.org )? When I installed sys-fs/udev-216-r1 it displayed the following:

Code: Select all

End of installation of sys-fs/udev-216-r1

 * 
 * File /etc/udev/rules.d/70-persistent-net.rules is from old udev installation but if you still use it,
 * rename it to something else starting with 70- to silence this deprecation
 * warning.
 * 
 * Starting from version >= 197 the new predictable network interface names are
 * used by default, see:
 * http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames
 * http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udev-builtin-net_id.c
 * 
 * Example command to get the information for the new interface name before booting
 * (replace <ifname> with, for example, eth0):
 * # udevadm test-builtin net_id /sys/class/net/<ifname> 2> /dev/null
 * 
 * You can use either kernel parameter "net.ifnames=0", create empty
 * file /etc/systemd/network/99-default.link, or symlink it to /dev/null
 * to disable the feature.
 * 
 * You need to restart udev as soon as possible to make the upgrade go
 * into effect.
 * The method you use to do this depends on your init system.
 * For sys-apps/openrc users it is:
 * # /etc/init.d/udev --nodeps restart
 * 
 * For more information on udev on Gentoo, upgrading, writing udev rules, and
 * fixing known issues visit:
 * http://wiki.gentoo.org/wiki/Udev
 * http://wiki.gentoo.org/wiki/Udev/upgrade
>>> sys-fs/udev-216-r1 merged.
>>> Regenerating /etc/ld.so.cache...
>>> Auto-cleaning packages...

>>> No outdated packages were found on your system.

I have not bothered to add net.ifnames=0 to the kernel boot line in grub.cfg, but I do have the following files currently and udev-216-r1 installed:

Code: Select all

$ ls /etc/udev/rules.d/
10-usbprinter.rules  51-android.rules  70-persistent-net.rules  80-net-name-slot.rules  80-net-setup-link.rules
$ cat /etc/udev/rules.d/70-persistent-net.rules
# PCI device 0x1969:0x1063 (atl1c)
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="70:5a:b6:3e:c1:8a", NAME="eth0"

# PCI device 0x8086:0x4235 (iwlagn)
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:21:6a:9a:68:4c", NAME="wlan0"
$

and:

Code: Select all

$ ls /etc/systemd/network
99-default.link
$ ls -la /etc/systemd/network/99-default.link
-rw-r--r-- 1 root root 0 Oct 31 07:41 /etc/systemd/network/99-default.link
$ cat /etc/systemd/network/99-default.link
$

If I want eudev to leave eth0 and wlan0 alone, do I leave the above-mentioned files as they are, or do I need to do anything? When I used to have sys-fs/udev-197-r10 and sys-fs/udev-init-scripts-19 installed, the contents of /etc/udev/rules.d/70-persistent-net.rules were:

Code: Select all

# This file was automatically generated by the /lib64/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.

# PCI device 0x1969:0x1063 (atl1c)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="70:5a:b6:3e:c1:8a", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

# PCI device 0x8086:0x4235 (iwlagn)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:21:6a:9a:68:4c", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="wlan*", NAME="wlan0"

After installing eudev, do I need to change /etc/udev/rules.d/70-persistent-net.rules to contain what it contains currently for sys-fs/udev-216-r1 (see further up this post) or will it revert to the contents shown directly above?

[rant]
This udev/systemd stuff is bloody confusing (=annoying). It's like musical chairs for adults. It's enough to drive someone screaming back to Windows. No wonder there has never been a 'year of the Linux desktop'. Jeez.
[/rant]

[mv]

If I want eudev to leave eth0 and wlan0 alone

I would strongly recommend to use different names (not used by the kernel), e.g. "lan0" and "wifi0": In the moment when you have no collision with kernel names, everything will work fine, no matter whether you use udev or eudev. Moreover, you avoid the race condition (which AFAIK still exists in eudev and which was the reason why udev changed the scheme). You can use any of the files you posted, just use a different value for NAME=... (and, of course, you have to modify your other network settings to use these interface names: However, this is a one-time change and worth the effort unless you really have a serious resons why you cannot do this.)

[Fitzcarraldo]

Thanks for your post, mv, but, before I even begin to think about udev/eudev rules files, it would be nice if I could get eudev to install. This is what I get after I un-install sys-fs/udev-216-r1 and virtual/udev-215 and try to merge eudev:

Code: Select all

# emerge -aV eudev
Portage 2.2.14 (python 2.7.8-final-0, default/linux/amd64/13.0/desktop, gcc-4.8.3, glibc-2.19-r1, 3.13.7-gentoo x86_64)
#

[mv]

Code: Select all

# emerge -aV eudev

emerge -av eudev (small v for "verbose", not capital V for "version").

[Fitzcarraldo]

Gahh! As the Japanese say, sometimes even a monkey falls out of a tree. I'll edit my second post in this thread to change the 'V' to 'v'.

Anyway, this is what I did:

Code: Select all

# emerge -avC udev
# emerge -av eudev
# etc-update
Scanning Configuration files...
Exiting: Nothing left to do; exiting. :)
# emerge @preserved-rebuild
Calculating dependencies... done!
>>> Auto-cleaning packages...

>>> No outdated packages were found on your system.
# /etc/init.d/udev --nodeps restart
 * Stopping udev ...                                                                                                                                                                                                                         [ ok ]
 * Starting udev ...                                                                                                                                                                                                                         [ ok ]
 * Generating a rule to create a /dev/root symlink ...                                                                                                                                                                                       [ ok ]
 * Populating /dev with existing devices through uevents ...                                                                                                                                                                                 [ ok ]
 * Waiting for uevents to be processed ...                                                                                                                                                                                                   [ ok ]
#

I didn't need to add udev-postmount to the default runlevel. As I have USE="-rule-generator", the ebuild did not display the ewarn message telling me to do that.

'emerge -avC udev' displayed the following messages:

Code: Select all

>>> Regenerating /etc/ld.so.cache...

 * GNU info directory index is up-to-date.

!!! existing preserved libs:
>>> package: sys-fs/udev-216-r1
 *  - /lib64/libudev.so.1
 *  - /lib64/libudev.so.1.6.0
 *      used by /bin/findmnt (sys-apps/util-linux-2.25.2)
 *      used by /bin/lsblk (sys-apps/util-linux-2.25.2)
 *      used by /lib/udev/hid2hci (net-wireless/bluez-5.24)
 *      used by 44 other files
 *  - /usr/lib64/libgudev-1.0.so.0
 *  - /usr/lib64/libgudev-1.0.so.0.2.0
 *      used by /usr/bin/simple-scan (media-gfx/simple-scan-3.12.2)
 *      used by /usr/lib/udisks/udisks-daemon (sys-fs/udisks-1.0.5-r1)
 *      used by /usr/lib/udisks2/udisksd (sys-fs/udisks-2.1.3)
 *      used by 48 other files
Use emerge @preserved-rebuild to rebuild packages using these libraries
#

However, the command 'emerge @preserved-ebuild' just displayed the message 'No outdated packages were found on your system.' and did not rebuild anything.

The current situation is:

Code: Select all

# eix -I udev
[I] dev-python/pyudev
     Available versions:  0.16.1 0.16.1-r1 {pygobject pyqt4 pyside test PYTHON_TARGETS="python2_7 python3_2 python3_3 python3_4"}
     Installed versions:  0.16.1-r1(02:34:04 13/10/14)(pyqt4 -pygobject -pyside -test PYTHON_TARGETS="python2_7 python3_3 -python3_2 -python3_4")
     Homepage:            http://pyudev.readthedocs.org https://github.com/pyudev/pyudev
     Description:         Python binding to libudev

[I] sys-fs/eudev
     Available versions:  *1.3 *1.5.3-r1 1.9-r2 1.10-r2 (~)2.1.1 **9999 {doc gudev (+)hwdb introspection (+)keymap (+)kmod +modutils +openrc +rule-generator selinux static-libs test ABI_MIPS="n32 n64 o32" ABI_PPC="32 64" ABI_S390="32 64" ABI_X86="32 64 x32"}
     Installed versions:  2.1.1(18:33:48 31/10/14)(gudev hwdb introspection keymap kmod modutils -doc -rule-generator -selinux -static-libs -test ABI_MIPS="-n32 -n64 -o32" ABI_PPC="-32 -64" ABI_S390="-32 -64" ABI_X86="64 -32 -x32")
     Homepage:            https://github.com/gentoo/eudev
     Description:         Linux dynamic and persistent device naming support (aka userspace devfs)

[I] sys-fs/udev-init-scripts
     Available versions:  26-r2^t (~)27^t **9999^t
     Installed versions:  27^t(22:36:55 20/08/14)
     Homepage:            http://www.gentoo.org
     Description:         udev startup scripts for openrc

[I] virtual/libgudev
     Available versions:  215-r1(0/0) {introspection static-libs systemd ABI_MIPS="n32 n64 o32" ABI_PPC="32 64" ABI_S390="32 64" ABI_X86="32 64 x32"}
     Installed versions:  215-r1(22:26:01 20/08/14)(introspection static-libs -systemd ABI_MIPS="-n32 -n64 -o32" ABI_PPC="-32 -64" ABI_S390="-32 -64" ABI_X86="64 -32 -x32")
     Description:         Virtual for libgudev providers

[I] virtual/libudev
     Available versions:  215-r1(0/1) {static-libs systemd ABI_MIPS="n32 n64 o32" ABI_PPC="32 64" ABI_S390="32 64" ABI_X86="32 64 x32"}
     Installed versions:  215-r1(22:26:24 20/08/14)(static-libs -systemd ABI_MIPS="-n32 -n64 -o32" ABI_PPC="-32 -64" ABI_S390="-32 -64" ABI_X86="64 -32 -x32")
     Description:         Virtual for libudev providers

[I] virtual/udev
     Available versions:  215 {systemd}
     Installed versions:  215(16:04:56 31/10/14)(-systemd)
     Description:         Virtual to select between different udev daemon providers

Found 6 matches.

Code: Select all

# ls /etc/udev/rules.d/
10-usbprinter.rules  51-android.rules  70-persistent-net.rules  80-net-name-slot.rules  80-net-setup-link.rules

Code: Select all

# cat /etc/udev/rules.d/70-persistent-net.rules
# PCI device 0x1969:0x1063 (atl1c)
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="70:5a:b6:3e:c1:8a", NAME="eth0"

# PCI device 0x8086:0x4235 (iwlagn)
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:21:6a:9a:68:4c", NAME="wlan0"

Code: Select all

# cat /etc/udev/rules.d/80-net-name-slot.rules
# No, I don't want the switch yet. Thanks.
# http://forums.gentoo.org/viewtopic-t-948718-highlight-.html
# End of file.

Code: Select all

# cat /etc/udev/rules.d/80-net-setup-link.rules 
# No, I don't want the switch.
# http://forums.gentoo.org/viewtopic-p-7507456.html#7507456
# End of file.

Code: Select all

# ls -la /etc/systemd/network/99-default.link
-rw-r--r-- 1 root root 0 Oct 31 07:41 /etc/systemd/network/99-default.link

The problem now is that booting hangs at 'Waiting for uevents to be processed ...' and I have to use Ctrl-C after a long wait to get it to continue:

Code: Select all

INIT: version 2.88 booting

   OpenRC 0.13.2 is starting up Gentoo Linux (x86_64)

 * /proc is already mounted
 * Mounting /run ...
 * /run/openrc: creating directory
 * /run/lock: creating directory
 * /run/lock: correcting owner
 * Remounting devtmpfs on /dev ...
 * Mounting /dev/mqueue ...
 * Mounting /dev/shm ...
 * Mounting security filesystem ...
 * Mounting debug filesystem ...
 * Mounting cgroup filesystem ...
 * Mounting fuse control filesystem ...
 * Loading module xt_LOG ...
 * Loading module vboxdrv ...
 * Loading module vboxnetflt ...
 * Loading module vboxnetadp ...
 * Autoloaded 4 module(s)
 * setting up tmpfiles.d entries for /dev ...
 * Starting udev ...
 * Generating a rule to create a /dev/root/ symlink ...
 * Populating /dev with existing devices through uevents ...
 * Waiting for uevents to be processed ...

I'll have a look in /var/log/messages.

EDIT: Fixed order of commands issued.

[Fitzcarraldo]

The problem that occurred with udev-217 appears to be occurring with eudev-2.1.1 as well. It is something to do with the Intel microcode for the CPU. Why it didn't happen with udev-216-r1 I do not know. Here are the relevant error messages in the case of eudev-2.1.1:

Code: Select all

# dmesg | grep microcode
[   16.181490] microcode: CPU0 sig=0x106e5, pf=0x10, revision=0x3
[   16.181533] platform microcode: Direct firmware load failed with error -2
[   16.181537] platform microcode: Falling back to user helper
[   76.231907] microcode: CPU1 sig=0x106e5, pf=0x10, revision=0x3
[   76.231943] platform microcode: Direct firmware load failed with error -2
[   76.231950] platform microcode: Falling back to user helper
[  136.393961] microcode: CPU2 sig=0x106e5, pf=0x10, revision=0x3
[  136.393995] platform microcode: Direct firmware load failed with error -2
[  136.394002] platform microcode: Falling back to user helper
[  196.556962] microcode: CPU3 sig=0x106e5, pf=0x10, revision=0x3
[  196.557018] platform microcode: Direct firmware load failed with error -2
[  196.557026] platform microcode: Falling back to user helper
[  256.718243] microcode: CPU4 sig=0x106e5, pf=0x10, revision=0x3
[  256.718271] platform microcode: Direct firmware load failed with error -2
[  256.718276] platform microcode: Falling back to user helper
[  316.863589] microcode: CPU5 sig=0x106e5, pf=0x10, revision=0x3
[  316.863656] platform microcode: Direct firmware load failed with error -2
[  316.863664] platform microcode: Falling back to user helper
[  376.995697] microcode: CPU6 sig=0x106e5, pf=0x10, revision=0x3
[  376.995736] platform microcode: Direct firmware load failed with error -2
[  376.995743] platform microcode: Falling back to user helper
[  437.139188] microcode: CPU7 sig=0x106e5, pf=0x10, revision=0x3
[  437.139223] platform microcode: Direct firmware load failed with error -2
[  437.139231] platform microcode: Falling back to user helper
[  497.300307] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba

I'm trying to understand the article in the Arch Wiki: https://wiki.archlinux.org/index.php/Microcode#Updating_microcode.

I am now upgrading the kernel from 3.13.7-gentoo to 3.17.1-gentoo-r1 using genkernel to rebuild a new initramfs file, and will also edit the grub.cfg file as described in the Arch Wiki article to see if that sorts out the problem.

[kernelOfTruth]

*subscribes*

/me - is facing similar issues - investigating ...

[Fitzcarraldo]

OK, I have got it booting (relatively) smoothly. The problem is indeed caused by the Intel CPU microcode not loading, but I still don't know why this problem didn't occur with udev-216-r1 but did occur after I installed udev-217 and did occur after I installed eudev-2.1.1. Anyway, the delay after the boot message ' * Waiting for uevents to be processed ...' appears is now much shorter, and the microcode error messages no longer occur. As you can see below, the Intel microcode is now loaded correctly at boot:

Code: Select all

$ dmesg | grep microcode
[   16.287897] microcode: CPU0 sig=0x106e5, pf=0x10, revision=0x3
[   16.447951] microcode: CPU0 sig=0x106e5, pf=0x10, revision=0x3
[   16.448695] microcode: CPU0 updated to revision 0x7, date = 2013-08-20
[   16.448743] microcode: CPU1 sig=0x106e5, pf=0x10, revision=0x3
[   16.448828] microcode: CPU1 sig=0x106e5, pf=0x10, revision=0x3
[   16.449186] microcode: CPU1 updated to revision 0x7, date = 2013-08-20
[   16.449196] microcode: CPU2 sig=0x106e5, pf=0x10, revision=0x3
[   16.449219] microcode: CPU2 sig=0x106e5, pf=0x10, revision=0x3
[   16.449588] microcode: CPU2 updated to revision 0x7, date = 2013-08-20
[   16.449598] microcode: CPU3 sig=0x106e5, pf=0x10, revision=0x3
[   16.449619] microcode: CPU3 sig=0x106e5, pf=0x10, revision=0x3
[   16.449898] microcode: CPU3 updated to revision 0x7, date = 2013-08-20
[   16.449983] microcode: CPU4 sig=0x106e5, pf=0x10, revision=0x3
[   16.450032] microcode: CPU4 sig=0x106e5, pf=0x10, revision=0x3
[   16.450389] microcode: CPU4 updated to revision 0x7, date = 2013-08-20
[   16.450462] microcode: CPU5 sig=0x106e5, pf=0x10, revision=0x3
[   16.450542] microcode: CPU5 sig=0x106e5, pf=0x10, revision=0x3
[   16.450900] microcode: CPU5 updated to revision 0x7, date = 2013-08-20
[   16.450914] microcode: CPU6 sig=0x106e5, pf=0x10, revision=0x3
[   16.450941] microcode: CPU6 sig=0x106e5, pf=0x10, revision=0x3
[   16.451321] microcode: CPU6 updated to revision 0x7, date = 2013-08-20
[   16.451327] microcode: CPU7 sig=0x106e5, pf=0x10, revision=0x3
[   16.451342] microcode: CPU7 sig=0x106e5, pf=0x10, revision=0x3
[   16.451613] microcode: CPU7 updated to revision 0x7, date = 2013-08-20
[   16.451858] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
[   27.879328] microcode: Microcode Update Driver: v2.00 removed.

The kernel configuration items listed below were already configured that way in kernel 3.13.7-gentoo in my installation, and I left them the same in the kernel 3.17.1-gentoo-r1 that I have just built (unnecessarily, probably):

Code: Select all

# cat /usr/src/linux/.config | grep MICROCODE
CONFIG_MICROCODE=m
CONFIG_MICROCODE_INTEL=y
# CONFIG_MICROCODE_AMD is not set
CONFIG_MICROCODE_OLD_INTERFACE=y
# CONFIG_MICROCODE_INTEL_EARLY is not set
# CONFIG_MICROCODE_AMD_EARLY is not set

After building the kernel and modules, editing /etc/default/grub and running grub2-mkconfig, I then did the following:

Code: Select all

emerge microcode-ctl
rc-update add microcode_ctl boot
/etc/init.d/microcode_ctl start

and rebooted. Then I re-ran grub2-mkconfig, because there were some error messages when I ran it after rebuilding the kernel, due to missing devices because the microcode had not been added at the previous boot, of course:

Code: Select all

mount /dev/sda3 /boot # I have /boot on a separate partition.
grub2-mkconfig -o /boot/grub/grub.cfg

I don't think my problem had anything to do with the version of kernel or udev-217. The microcode was not loading for either kernel version until I installed microcode-ctl and added it to the boot runlevel. But, as I said before, why this problem did not occur when udev-216-r1 was installed I do not know. If I re-installed udev-216-r1 the problem disappeared; if I re-installed udev-217 the microcode problem reappeared. And installing eudev-2.1.1 also made the microcode problem reappear.

If I knew how, I think the loading of the CPU microcode could be done by the initramfs so that the microcode is loaded even earlier, but I have no idea how to do that. But I'll do some more investigating. Anyway, at least my laptop is now booting as expected and the KWin Hardware Temperature Settings widget on the KDE Desktop is again showing the temperatures of the CPU's four cores.


EDIT: They say every cloud has a silver lining; well this problem finally forced me to ditch systemd/udev and install eudev. I had been toying for a long time with installing eudev but was too nervous to do it, as I was worried about breaking badly the installation on my main laptop.

[Roman_Gruber]

For some reason since yesterday my box also hangs with eudev uevents beeing processed at startup.

I checked dmesg and it claims it can not find

[ 12.348146] nvidia 0000:03:00.0: irq 50 for MSI/MSI-X
[ 61.067126] iwl4965 0000:06:00.0: request for firmware file 'iwlwifi-4965-2.ucode' failed.
[ 61.067130] iwl4965 0000:06:00.0: no suitable firmware found!

which kinda explains the minute lag there. assuming the left numbers are seconds.
I am pretty sure wireless lan worked on 3.10 for ages. I saw somewhere else that 3.11 is needed but I do not want to ditch a long term support kernel. The problems arose since 2-days or so, so I will have to check what was upgraded and caused this issue.
wlan worked for ages and i am on 3.10 for ages too. I may have upgrades to a newer 3.10 revision of the long term support but still it annoys me that a basic functionality, which I hardly use is suddenly broken.

SEcond bug which arose after two days, which I am pretty sure was not there also

[ 11.939658] udevd[2841]: starting version 2.1.1
[ 12.102838] ACPI Warning: 0x0000000000000828-0x000000000000082f SystemIO conflicts with Region \PMIO 1 (20130328/utaddress-251)
[ 12.102846] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
[ 12.102850] ACPI Warning: 0x0000000000000530-0x000000000000053f SystemIO conflicts with Region \GPIO 1 (20130328/utaddress-251)
[ 12.102854] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
[ 12.102855] ACPI Warning: 0x0000000000000500-0x000000000000052f SystemIO conflicts with Region \GPIO 1 (20130328/utaddress-251)
[ 12.102859] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver

this is also from dmesg.

Well i have not bothered so far to find the real root cause but I suspect an eudev upgrade recently for that.

localhost roman # splat eudev
* sys-fs/eudev-1.10-r2

Emerged at: Fr Okt 17 13:40:38 2014
Build time: 56 seconds

Emerged at: Sa Okt 18 20:05:57 2014
Build time: 59 seconds

* sys-fs/eudev-2.1.1

Emerged at: Fr Okt 31 12:30:19 2014
Build time: 1 minute, and 30 seconds

[Roman_Gruber]

Code: Select all

localhost roman # tail -14 /var/log/emerge.log 
1414847870: Started emerge on: Nov 01, 2014 14:17:50
1414847870:  *** emerge  =eudev-1.10-r2
1414847919:  >>> emerge (1 of 1) sys-fs/eudev-1.10-r2 to /
1414847919:  === (1 of 1) Cleaning (sys-fs/eudev-1.10-r2::/usr/portage/sys-fs/eudev/eudev-1.10-r2.ebuild)
1414847920:  === (1 of 1) Compiling/Merging (sys-fs/eudev-1.10-r2::/usr/portage/sys-fs/eudev/eudev-1.10-r2.ebuild)
1414847976:  === (1 of 1) Merging (sys-fs/eudev-1.10-r2::/usr/portage/sys-fs/eudev/eudev-1.10-r2.ebuild)
1414847979:  >>> AUTOCLEAN: sys-fs/eudev:0
1414847979:  === Unmerging... (sys-fs/eudev-2.1.1)
1414847983:  >>> unmerge success: sys-fs/eudev-2.1.1
1414847987:  === (1 of 1) Post-Build Cleaning (sys-fs/eudev-1.10-r2::/usr/portage/sys-fs/eudev/eudev-1.10-r2.ebuild)
1414847987:  ::: completed emerge (1 of 1) sys-fs/eudev-1.10-r2 to /
1414847987:  *** Finished. Cleaning up...
1414847989:  *** exiting successfully.
1414847989:  *** terminating.

Dmesg output

Code: Select all

[   20.424416] udevd[2884]: starting version 1.10
[   20.551017] iwl4965 0000:06:00.0: loaded firmware version 228.61.2.24
[   20.551315] ieee80211 phy0: Selected rate control algorithm 'iwl-4965-rs'
[   20.560475] ACPI Warning: 0x0000000000000828-0x000000000000082f SystemIO conflicts with Region \PMIO 1 (20130328/utaddress-251)
[   20.560482] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
[   20.560486] ACPI Warning: 0x0000000000000530-0x000000000000053f SystemIO conflicts with Region \GPIO 1 (20130328/utaddress-251)
[   20.560490] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
[   20.560491] ACPI Warning: 0x0000000000000500-0x000000000000052f SystemIO conflicts with Region \GPIO 1 (20130328/utaddress-251)
[   20.560495] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
[   20.560497] lpc_ich: Resource conflict(s) found affecting gpio_ich
[   20.567549] input: PC Speaker as /devices/platform/pcspkr/input/input12

Code: Select all

localhost roman # ifconfig -a
dummy0: flags=195<UP,BROADCAST,RUNNING,NOARP>  mtu 1500
        ether 9a:04:XX:XX:XX:XX  txqueuelen 0  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 7  bytes 2807 (2.7 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.0.0.6  netmask 255.255.255.0  broadcast 10.0.0.255
        ether 00:23:XX:XX:XX:XX  txqueuelen 1000  (Ethernet)
        RX packets 5593  bytes 2664709 (2.5 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 5784  bytes 869406 (849.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 16  

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        loop  txqueuelen 0  (Local Loopback)
        RX packets 118  bytes 6148 (6.0 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 118  bytes 6148 (6.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlan0: flags=4098<BROADCAST,MULTICAST>  mtu 1500
        ether 00:1f:XX:XX:XX:XX  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Code: Select all

localhost roman # uname -a
Linux localhost 3.10.41-gentoo-r1_2014_06_06 #1 SMP PREEMPT Fri Jun 6 10:36:07 CEST 2014 x86_64 Intel(R) Core(TM)2 Duo CPU T9500 @ 2.60GHz GenuineIntel GNU/Linux

Summary downgrading of eudev solves my issues regarding uevents beeing processed, wifi functionality gone.

edit the acpi error was definitly not there last time i checked dmesg around 2 months ago. As i am on long term stable kernel release I think the error was introduced recenlty... WEll i ignore it as of now, as I do not know if I buy a newer hardware quite soon. 6 years old notebook.

edit:

Code: Select all

localhost linux # grep GPIO_ICH .config
# CONFIG_GPIO_ICH is not set

The root cause for the acpi warning. As it is a warning and according to https://bugzilla.kernel.org/show_bug.cgi?id=48811 it can be ignored. I changed my config and with next time I will build the kernel it will be fixed.

[franzf]

I think the root cause is that systemd-217 (and with it udev-217 and eudev, if it applied that patch) dropped support for user-space firmware-loading.
I had the "opportunity" to fix sloooow boot on a systemd-machine.

Code: Select all

r8169 0000:02:00.0 eth0: unable to load firmware patch rtl_nic/rtl8168e-3.fw (-12)

The weird thing is that I do not have realtek firmware installed (don't even know which package contains the firmware). It boots fine with 216.
It's really fun to deal with such breakages. Thx Lennart/Kay/Greg...! But probably such issues are needed, so that the user can see that it's actively maintained - in contrast to openrc, which (for me) just works (Yes, I know, openrc has nothing to do with (e)udev, as systemd-PID1 has nothing to do with udev - but things seem to break more often since the whole "core system" merge)
The only fix for the moment is to downgrade.

[Fitzcarraldo]

You may well be correct, franzf, although so far I have not noticed a problem with firmware* apart from the CPU firmware (microcode) problem I described earlier in this thread. Regarding that problem, I now know of a second method of solving it: the in-kernel Early CPU Microcode Update driver discussed in my post in the thread '[solved partly] Howto microcode early'.

* I'm just trying to think what other firmware my laptop needs to upload: iwlwifi-5000-*.ucode for the Ultimate N WiFi Link 5300 card is the only thing I can think of at the moment, and WiFi is still working with eudev-2.1.1.


EDIT: See also Updating Intel CPU microcode from Gentoo Linux.

[Fitzcarraldo]

As I understand it, since kernel version 3.7 the kernel only asks udev for the firmware data if it cannot find the firmware file itself (see LWN.net article Udev and firmware). So, if the firmware is in the expected directory /lib/firmware/, shouldn't the switch from udev-216-r1 to udev-217 make no difference? I assume that, when I was using udev-216-r1, the kernel, not udev, was finding the iwlwifi firmware file in /lib/firmware/ and so was not asking udev for it anyway. After installing udev-217, which is the first version of udev to not support requests from the kernel for firmware data, the process should be the same, namely that the kernel finds the iwlwifi firmware file in /lib/firmware/ and loads it directly. I assume that's why I am still able to use my WiFi card with eudev-2.1.1 (which I assume also does not support kernel firmware requests any more, in the same way that udev-217 doesn't)? Is my reasoning correct?

As can be seen from the following dmesg output, the iwlwifi firmware is indeed being loaded:

Code: Select all

# dmesg | grep iwlwifi
[   16.185370] iwlwifi 0000:03:00.0: can't disable ASPM; OS doesn't have ASPM control
[   16.185512] iwlwifi 0000:03:00.0: irq 30 for MSI/MSI-X
[   16.229278] iwlwifi 0000:03:00.0: loaded firmware version 8.83.5.1 build 33692 op_mode iwldvm
[   16.651131] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEBUG disabled
[   16.651139] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEBUGFS disabled
[   16.651145] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEVICE_TRACING disabled
[   16.651151] iwlwifi 0000:03:00.0: Detected Intel(R) Ultimate N WiFi Link 5300 AGN, REV=0x24
[   16.651259] iwlwifi 0000:03:00.0: L1 Enabled; Disabling L0S
[   34.981541] iwlwifi 0000:03:00.0: L1 Enabled; Disabling L0S
[   34.984530] iwlwifi 0000:03:00.0: Radio type=0x0-0x2-0x0
[   35.115782] iwlwifi 0000:03:00.0: L1 Enabled; Disabling L0S
[   35.118791] iwlwifi 0000:03:00.0: Radio type=0x0-0x2-0x0

The firmware is in the usual place:

Code: Select all

# ls /lib/firmware/iwlwifi-5*
/lib/firmware/iwlwifi-5000-1.ucode  /lib/firmware/iwlwifi-5000-2.ucode  /lib/firmware/iwlwifi-5000-5.ucode  /lib/firmware/iwlwifi-5150-2.ucode

This is what is configured in the kernel in my installation (currently 3.17.1-gentoo-r1):

Code: Select all

# grep '_FW_\|FIRMWARE' /usr/src/linux/.config
# CONFIG_PREVENT_FIRMWARE_BUILD is not set
CONFIG_FW_LOADER=y
CONFIG_FIRMWARE_IN_KERNEL=y
CONFIG_EXTRA_FIRMWARE=""
# CONFIG_FW_LOADER_USER_HELPER_FALLBACK is not set
CONFIG_AIC7XXX_BUILD_FIRMWARE=y
CONFIG_AIC79XX_BUILD_FIRMWARE=y
# CONFIG_CYPRESS_FIRMWARE is not set
CONFIG_FIRMWARE_EDID=y
CONFIG_FIRMWARE_MEMMAP=y
CONFIG_GOOGLE_FIRMWARE=y
# CONFIG_TEST_FIRMWARE is not set

Code: Select all

# grep IWL /usr/src/linux/.config
CONFIG_IWLWIFI=m
CONFIG_IWLWIFI_LEDS=y
CONFIG_IWLDVM=m
# CONFIG_IWLMVM is not set
CONFIG_IWLWIFI_OPMODE_MODULAR=y
# CONFIG_IWLWIFI_DEBUG is not set
# CONFIG_IWL4965 is not set
# CONFIG_IWL3945 is not set

So, is the loading of the iwlwifi firmware just the default kernel behaviour (as stated in the LWN.net article), or is a kernel configuration item causing it to be loaded? If the latter, which one is it in the above list of my kernel configuration items?

[krinn]

I think the problem appears because udev-217 (eudev have the code but not the use flag) the firmware-loader use flag.
And if you re-read the article kernel 3.17 will have a patch to handle that part instead of the userland tool

So a patch for 3.17 may not be inside the 3.17 you are using.
Look at old udev use flag desc
+ - firmware-loader : Enable the userspace firmware loader (DEPRECATED,
replaced by the in-kernel loader starting from 3.8

->kernel 3.8, looks logic, 3.7 get a patch, test, stabilize, feature really add in 3.8

To me it's an error from eudev and udev gentoo maintainers : while (it's still not normal) but i expect such thing as "normal" coming from those stupid lennart & co (that don't care breaking anyone config by fucking userspace tool), i didn't expect eudev and gentoo udev maintainers adopt that idiotic thinking.

[Anon-E-moose]

I saw when eudev-2.1 came out and wanted to emerge, but I blocked it.

It may have something to do with firmware loading (as there was a news article about that). Just a guess as I'm not having problems with eudev < 2.0

Edit to add:

2014-11-07-udev-upgrade
Title Upgrade to udev >= 217 or eudev >= 2.1
Author Samuli Suominen <ssuominen@gentoo.org>
Posted 2014-11-07
Revision 1

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. No action is
required if none of your kernel modules need firmware. See [1] for more
information on the upgrade.

[1] https://wiki.gentoo.org/wiki/Udev/upgra ... 216_to_217

Edit to add 2: I may very well put a permanent block on any newer eudev (I'm tired of the stupidity put out by anyone following LPs cabal so stupidly)

[Fitzcarraldo]

And if you re-read the article kernel 3.17 will have a patch to handle that part instead of the userland tool

So a patch for 3.17 may not be inside the 3.17 you are using.

Not 3.17, 3.7. It's an old article from 2012 and the change to the kernel has been in place since kernel version 3.7. The deprecated (and redundant since udev-217) CONFIG_FW_LOADER_USER_HELPER existed since kernel version 3.9, and its successor CONFIG_FW_LOADER_USER_HELPER_FALLBACK (also redundant since udev-217) since kernel version 3.17.

I'm using kernel 3.17.1-gentoo-r1, not 3.7.

The reason must be something else, surely?

To rephrase my question another way, why are some Gentoo users apparently having firmware-related trouble* with >3.7 kernels and udev-217/eudev-2.1.1 but I'm not?

*See the recent posts in, e.g., cant setup wireles "iwlwifi-4965-2.ucode" failed and [SOLVED] iwlwifi fails to load after upgrade to 3.17.0.

[krinn]

yeah sorry kinda mixup kernel version

why are some Gentoo users apparently having trouble with >3.7 kernels and udev-217/eudev-2.1.1 but I'm not?

Now, i'm really lost (not mixing up number again) ; but you said 217 doesn't work while it do with 216
216 have the use flag with firmware loading support, 217 drop it.

But now you are saying it work even with 217. So you have no issue or i'm just totally lost?

[Fitzcarraldo]

My problem with udev-217/eudev-2.1.1 was specifically with the CPU firmware. As mentioned in my earlier post, I did not have to do anything different to get the firmware for iwlwifi to load. It is still loading with eudev-2.1.1 (and was still loading when I had udev-217 installed, if I recall correctly). My package.use contains:

Code: Select all

# cat package.use | grep udev
dev-python/pyudev pyqt4
sys-fs/eudev -rule-generator static-libs
sys-fs/udev extras static-libs firmware-loader
>=virtual/libgudev-208 static-libs
>=virtual/libudev-208 static-libs
>=virtual/udev-197 static-libs

The firmware-loader USE flag was dropped in udev-217 but still used in udev-216-r1. I added the eudev entry before un-merging udev and merging eudev.

So, it seems that the Gentoo kernel is indeed automatically looking for the iwlwifi firmware in /lib/firmware/ in my case. But I'm curious why apparently it isn't looking automatically for the iwlwifi firmware for some other Gentoo users (see the recent posts in two threads I referenced in my previous post). I assume those users are not still using <3.7 kernels, so there could be some other reason why the iwlwifi firware is being loaded in my case. I'm just wondering if one or more of the kernel configuration items (see my last-but-one post) in my kernel is triggering that, or whether the kernel is doing it automatically as stated in the LWN.net article and elsewhere (e.g. Debian Bug report logs - #718975 - Switch to kernel-based firmware loader).

Is it clear what I'm trying to find out? The iwlwifi firmware is loaded successfully in my case (see the dmesg output I posted earlier). I want to know if the iwlwifi firmware is being loaded automatically by the kernel whatever configuration item is set (as apparently that LWN.net article and above-mentioned Debian log suggests) or whether a specific configuration item or items in the kernel is/are making it happen. If the latter, which one(s) is it? Here again are the kernel configuration items in the kernel I am using:

Code: Select all

# grep '_FW_\|FIRMWARE' /usr/src/linux/.config
# CONFIG_PREVENT_FIRMWARE_BUILD is not set
CONFIG_FW_LOADER=y
CONFIG_FIRMWARE_IN_KERNEL=y
CONFIG_EXTRA_FIRMWARE=""
# CONFIG_FW_LOADER_USER_HELPER_FALLBACK is not set
CONFIG_AIC7XXX_BUILD_FIRMWARE=y
CONFIG_AIC79XX_BUILD_FIRMWARE=y
# CONFIG_CYPRESS_FIRMWARE is not set
CONFIG_FIRMWARE_EDID=y
CONFIG_FIRMWARE_MEMMAP=y
CONFIG_GOOGLE_FIRMWARE=y
# CONFIG_TEST_FIRMWARE is not set

Code: Select all

# grep IWL /usr/src/linux/.config
CONFIG_IWLWIFI=m
CONFIG_IWLWIFI_LEDS=y
CONFIG_IWLDVM=m
# CONFIG_IWLMVM is not set
CONFIG_IWLWIFI_OPMODE_MODULAR=y
# CONFIG_IWLWIFI_DEBUG is not set
# CONFIG_IWL4965 is not set
# CONFIG_IWL3945 is not set

[Anon-E-moose]

It may be that when trying to load some of the firmware that the kernel is trying to pass it off to [e]udev
and since they don't really handle that they may be waiting for an acknowledgment from the kernel.

Just a guess as I don't use either the latest *udev's nor do fancy stuff with _FIRMWARE* kernel flags.

[Fitzcarraldo]

It could be that, if CONFIG_FW_LOADER_USER_HELPER (or CONFIG_FW_LOADER_USER_HELPER_FALLBACK in the case of kernel 3.17) is set, even though udev-217/eudev-2.1.1 no longer supplies firmware to the kernel, udev-217/eudev-2.1.1 still wait for a timeout period before notifying the kernel. That appears to be what a Debian developer wrote (see the link I gave earlier):

> If CONFIG_FW_LOADER_USER_HELPER=n is set, I assume there is no such timeout, if no firmware is found by the kernel?

Indeed.

I think udev should be fixed to fail immediately rather than after 60 seconds if it doesn't support firmware loading. Maarten Lankhorst has recently posted¹ a patch for that on systemd-devel.

¹ http://lists.freedesktop.org/archives/s ... 12554.html

Notice he wrote that over a year ago, but it seems to me that no change was made to udev (see, e.g., the following 10 Aug 2013 post by Kay Sievers: http://lists.freedesktop.org/archives/s ... 12622.html).

In the CPU firmware problem I observed with udev-217 (my first post in this thread referred), there was a delay of (I estimate) 60 seconds before booting continued. In the case of eudev-2.1.1 I gave up waiting after more than two minutes and pressed Ctrl-C to get the boot process to continue (my fourth post referred).

As you can see from my previous post, CONFIG_FW_LOADER_USER_HELPER_FALLBACK is not set in kernel 3.17.1-gentoo-r1 in my case. Therefore the kernel in my installation should not fall back to asking udev/eudev for the CPU firmware if the kernel cannot find it, and hence there should not have been a 60-second delay during boot (if I understand all this stuff correctly, that is). It just doesn't make sense to me.

[nollo]

Hi
I was in trouble with the same problem, I mean "waiting for uevents etc" and I found that is related to have compiled the kernel through genkernel with the flag BUSYBOX=yes, turning off the feature everything was fixed.

Bye

[Fitzcarraldo]

Thanks for the tip, nollo, but I don't have BUSYBOX="yes" as far as I can tell. BUSYBOX="yes" is commented-out in genkernel.conf:

Code: Select all

$ grep BUSYBOX /etc/genkernel.conf 
#BUSYBOX="yes"
#BUSYBOX_CONFIG="/path/to/file"
#BUSYBOX_APPLETS="[ ash sh mount uname echo cut cat"

[Fitzcarraldo]

Hmm... Further to my previous post, I'm not sure now that I've looked at the contents of /var/log/genkernel.log:

Code: Select all

# cat /var/log/genkernel.log | grep -i busybox
* busybox: >> Using cache
*         >> Appending busybox cpio data...

On a different note, I have now deleted the file /etc/udev/rules.d/70-persistent-net.rules (my second post in this thread referred) and initscript /etc/init.d/rename_ethX (given in Gentoo Bug Report No. 453494) as I think they were obsoleted by the following two files in later releases of udev for those of us who want to maintain the kernel naming scheme "eth0" and "wlan0" instead of the systemd/udev 'predictable network interface names':

Code: Select all

# cat /etc/udev/rules.d/80-net-name-slot.rules
# No, I don't want the switch yet. Thanks.
# http://forums.gentoo.org/viewtopic-t-948718-highlight-.html
# End of file.

Code: Select all

# cat /etc/udev/rules.d/80-net-setup-link.rules
# No, I don't want the switch.
# http://forums.gentoo.org/viewtopic-p-7507456.html#7507456
# End of file.