In the course of world update sys-fs/udev-164-r2 was replaced with sys-fs/udev-171-r5; afterwards my system got - all of a sudden - unusable in a very troublesome way: The keyboard simply stopped working - no login possible !

Pointing out all of them would take too long, but:
- a writable /run directory is required
- if your / and /usr are separate partitions, your initramfs needs to mount it (note: initramfs by genkernel tends to be bad)
- CONFIG_DEVTMPFS is required in udev 181 (so better to set it now)

Did the keyboard stopped working only in X or in console too ?
Anyway, it sounds as if udev did not start.

3. I dont understand your point about the "writable /run" directory. Pls note: /run under / (root).
There is no such one listed in the File System Hierarchy Standard (FHS) - http://www.pathname.com/fhs/pub/fhs-2.3.html. Who/what is in charge to create "/run" then ?

As far as I know there is only the "/var/run" needed. Is there a new bayse layout ? Im using "sys-apps/baselayout-2.0.3".
In the "old" udev (sys-fs/udev-164-r2:0) the rules in question exists in the "/dev/.udev" where "/dev" is a standard directory.

4. Using separate partition only for /boot

5. Im using genkernel for initramfs because this was configured by some initial live system and I can hardly redo the whole init script manually. I would prefer to boot entirely without it, but didnt find info & time to experiment...

6. I simply cant imagine why a system running well for the last 2 years gets broken in such a rude way. There must be something inportant Ive missed - but what ? Some obscure kernel setting ?

7. Apparently udev fails ; digging for a while in the code one should admit that v171 is a major upgrade though...

Again : Anyone else experiencing this ?

Any links/docs/info in this regard are highly appreciated .
Thanks in advance: UncleVan.

Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.

The problem is, that calling get_rundir() -(118)- before /lib/udev/write_root_link_rule (128) doesnt work; or to be precisely - works wrongly: At this point (before write_root_link) there is initially neither /dev/.udev/ nor /run/udev and

Code:

udevadm info --run

( == get_rundir() ) tends to return /run/udev in such a situation. Which is still not there because it gets created by the /lib/udev/write_root_link_rule !

Hence the errors about missing /run/udev/90-network.rules. And I couldnt retrace whether it really got created - imo not ! (Or is it possible that udev gets started from the initramfs yet before mounting real_root ? )

I wonder if it's really a udev matter.
If the update also had xorg-server in it then you should re-emerge all x11-drivers that are installed!
Gerard._________________To install Gentoo I use sysrescuecd.Based on Gentoo,has firefox to browse Gentoo docs and mc to browse (and edit) files.
The same disk can be used for 32 and 64 bit installs.
You can follow the Handbook verbatim.
http://www.sysresccd.org/Download

I wonder if it's really a udev matter.
If the update also had xorg-server in it then you should re-emerge all x11-drivers that are installed!
Gerard.

It should be a udev i don't have the event nodes in /dev/input i do have ones only for kbd and usb video cam. X log says EE that cannot find event interface. BTW have re-emerged all X11-driver couple of time version up version down same thing pointer devices just don't work, keyboard does though. Mouse and touchpad work with gpm.

Do you have the event interface (CONFIG_INPUT_EVDEV) in your kernel? It seems like you don't.

About /run, it's a relatively new thingy. If you create it, and turn /var/run into a symlink that points to it, the latest openrc will mount tmpfs there at boot. It'll then be used for various stuff, among other things by udev - it'll use /run/udev instead of /dev/.udev. Pretty much all other distros use /run nowadays, even Gentoo (openrc) is prepared to handle it.

I just can't figure out what happaned and why are those nodes not created. Will write some rules over the weekend to manually force them create.

about the /run will try that too although i doesn't seem relevant. It feels like a missing rule or a failing one. there is a segmentation fault at boot with MPT rules something libmpt related too if relevant.

Just to explain it: ist not a portage/compile issue - I got my keyboard controller AND keyboard drivers both compiled as modules : i8042 and atkbd resp.

With the "old" sys-fs/udev-164-r2 they are loaded smoothly; while the "new" sys-fs/udev-171-r5 (and probably later ones ?) doesnt get them.

So it has nothing to do with X evdev etc. , because the keyboard fails right after boot and it is obviously impossible to do anything more. I used for analysis a live system and chroot.

Im guessing for a missing/changed rule but since my small laptop got ruined (due to a glass of Metaxa poored in) I didnt want to experiment with the other one.
Now Ive repaired it and will investigate further soon.

For now Ive masked >sys-fs/udev-164-r2

Strangely, lot of people just dont have the issue and no responce from developers too...

Well well well... I had no idea i had to set CONFIG_DEVTMPFS for udev-182. Since portage checks the kernel config for many ebuilds, i was sure the ebuild would have checked it if it needed to do so. Would udev-182 have bricked my system, if i hadn't now recompiled the kernel with that option? Now i read the readme from the udev tarball and i ticked off all the requirements (DEVTMPFS was the only one i was missing).

Surely everybody thinks that the ebuild should check the user's kernel config before upgrading such a crucial tool as udev? If not it's a bit like saying that portage shouldn't handle dependencies because the user can do it by hand. And this is a kernel option dependency.

Anyhow, compiling now, let's see if i have to pull out my recovery disk

Surely everybody thinks that the ebuild should check the user's kernel config before upgrading such a crucial tool as udev? If not it's a bit like saying that portage shouldn't handle dependencies because the user can do it by hand. And this is a kernel option dependency.

I can think of two good reasons not to require DEVTMPFS=y in the kernel configuration. First, you may be building sys-fs/udev with intent not to install it on the current kernel, but rather to emerge --usepkgonly on another machine or to perform a kernel upgrade before merging the newly built udev to the live filesystem. Second, the user may have a properly configured kernel, but not have the files for Portage to satisfy itself that the kernel is properly configured. Requiring DEVTMPFS=y before building would prevent such users from upgrading.