Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
[urgent] sys-fs/udev-171-r5 breaks my systems - no keyboard!
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2  
Reply to topic    Gentoo Forums Forum Index Portage & Programming
View previous topic :: View next topic  
Author Message
ultraslinky
Tux's lil' helper
Tux's lil' helper


Joined: 09 Jun 2011
Posts: 80
Location: Milan, Italy

PostPosted: Sat Mar 24, 2012 5:32 pm    Post subject: Reply with quote

Ok i'm posting now from udev-182-r2 and xorg-server-1.12.0-r1! Everything went fine. Udev seems to behave fine here. Although i forgot xorg was in the upgrade bundle and i had to emerge my drivers again from the console, silly me :)

Quote:

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.


Well yes i agree, it isn't a strict requirement if it will be run on another machine. I was thinking about that Libreoffice build requirement, about how it wanted 1024 MB of ram and i have 998 reported to the kernel (shared graphics memory maybe?). I had to set maybe the longest enviromental variable ever to make it compile :D But anyhow, maybe it could come up as an ebuild suggestion (the ones with the yellow dots asterisks them). Now for curiosity i want to see if another kernel without that kernel option would have booted, which would probably be what i'd have done if i hadn't read that readme :)
Back to top
View user's profile Send private message
gerard27
Advocate
Advocate


Joined: 04 Jan 2004
Posts: 2377
Location: Netherlands

PostPosted: Sat Mar 24, 2012 6:18 pm    Post subject: Reply with quote

@UncleVan
I don't have those modules.
What does lsmod show?
Does it have "evdev" in it?
If not then that explains your problem I think.
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
Back to top
View user's profile Send private message
asotirov
n00b
n00b


Joined: 06 Mar 2007
Posts: 16

PostPosted: Sun Mar 25, 2012 1:24 pm    Post subject: Reply with quote

Ok i told ya :) it was a udev problem 182-r2 is perfectly fine now. My temp solution was to simply create the missing nodes in /dev/input. 182-r2 however does that automatically.
Back to top
View user's profile Send private message
Princess Nell
l33t
l33t


Joined: 15 Apr 2005
Posts: 916

PostPosted: Sun Mar 25, 2012 10:28 pm    Post subject: Reply with quote

On a related note, what is the official status of Gentoo /run support? I read Poettering's rationale and decided to play with it. Expecting one tempfs instead of four, I found five ;) Or is this simply a matter of udev versions?
Back to top
View user's profile Send private message
tbart
Apprentice
Apprentice


Joined: 31 Oct 2004
Posts: 151

PostPosted: Fri May 25, 2012 2:51 pm    Post subject: Reply with quote

Alright, spent 3 hours now and I'm truly clueless (and normally I am not, with Linux at least)

x11-drivers re-emerged
udev 171 and 182 tried
DEVTMPFS is in the kernel
/run is there and populated

No input devices in X, this is what happens if I plug in my kbd when X is running:

Code:
[   763.587] (II) config/udev: Adding input device HID 046a:0011 (/dev/input/event8)
[   763.588] (**) HID 046a:0011: Applying InputClass "evdev keyboard catchall"
[   763.588] (**) HID 046a:0011: Applying InputClass "keyboard-all"
[   763.588] (II) Using input driver 'evdev' for 'HID 046a:0011'
[   763.588] (II) Loading /usr/lib64/xorg/modules/input/evdev_drv.so
[   763.588] (**) HID 046a:0011: always reports core events
[   763.588] (**) HID 046a:0011: Device: "/dev/input/event8"
[   763.588] (EE) Unable to open evdev device "/dev/input/event8".
[   763.588] (EE) PreInit returned 2 for "HID 046a:0011"
[   763.588] (II) UnloadModule: "evdev"
[   763.588] (II) Unloading evdev


The device is there!
Code:
blackknight ~ # ll /dev/input/event8
0 crw-r-----  1 root root 13, 72 25. Mai 16:37 event8


This is strange:
Code:
blackknight ~ # cat < /dev/input/event8
-bash: /dev/input/event8: No such device


udev seems to run and work
Code:
blackknight ~ # udevadm monitor
KERNEL[1031.053501] add      /devices/pci0000:00/0000:00:1d.0/usb3/3-1 (usb)
KERNEL[1031.056433] add      /devices/pci0000:00/0000:00:1d.0/usb3/3-1/3-1:1.0 (usb)
KERNEL[1031.056489] add      /devices/pci0000:00/0000:00:1d.0/usb3/3-1/3-1:1.0/0003:046A:0011.0004 (hid)
KERNEL[1031.069403] add      /devices/pci0000:00/0000:00:1d.0/usb3/3-1/3-1:1.0/input/input14 (input)
KERNEL[1031.069436] add      /devices/pci0000:00/0000:00:1d.0/usb3/3-1/3-1:1.0/input/input14/event8 (input)
UDEV  [1031.077196] add      /devices/pci0000:00/0000:00:1d.0/usb3/3-1 (usb)
UDEV  [1031.077848] add      /devices/pci0000:00/0000:00:1d.0/usb3/3-1/3-1:1.0 (usb)
UDEV  [1031.078150] add      /devices/pci0000:00/0000:00:1d.0/usb3/3-1/3-1:1.0/0003:046A:0011.0004 (hid)
UDEV  [1031.078952] add      /devices/pci0000:00/0000:00:1d.0/usb3/3-1/3-1:1.0/input/input14 (input)
UDEV  [1031.079687] add      /devices/pci0000:00/0000:00:1d.0/usb3/3-1/3-1:1.0/input/input14/event8 (input)


Any pointers welcome... I'm giving up for now.

Seems exacly like the post earlier on but I simply cannot get it fixed..
Back to top
View user's profile Send private message
tbart
Apprentice
Apprentice


Joined: 31 Oct 2004
Posts: 151

PostPosted: Sat May 26, 2012 7:35 pm    Post subject: Reply with quote

Partially solved for me!

Found out it was a kernel/udev problem (or at least not X) as the "no such device" thing happens without X as well. The kernel or udev simply did not put the right device behind the device nodes created under /dev/input

evdev was modular and loaded.

I now put evdev directly into the kernel and it works.
Is this considered a bug? Yes it is, I think. Which package is to blame? The kernel or udev? I don't know!

What's still broken is I can't get my USB scanner to work and neither does my fingerprint reader work. So somehow udev(?) also messed up some other things. If you ask me, I wouldn't consider the current version stable...

On a sidenote, I am also on a ThinkPad but I guess this is not related.

Does anyone of those who got it fixed have evdev built as a module and not linked in?

Hope this solves is for the OP (UncleVan) and Dr. Willy!
Back to top
View user's profile Send private message
UncleVan
n00b
n00b


Joined: 08 Feb 2011
Posts: 72

PostPosted: Sat Dec 08, 2012 6:34 pm    Post subject: Reply with quote

Here some points from my experience with the transition to sys-fs/udev-171-*.
Also pls. consider post from tbart.

The 171 version was the first one to move from /dev/.udev to /run/udev (correct ?).

1. In the very beginning I found out that the "/sbin/udevadm info --run" works like following:
In absence of both "/dev/.udev" AND "/run/udev" (or even /run itself) it assumes "/run/udev"

Code:
strace /var/tmp/portage/sys-fs/udev-171-r9/image/sbin/udevadm info --run
.....
access("/run/udev", F_OK)               = -1 ENOENT (No such file or directory)
access("/dev/.udev", F_OK)              = -1 ENOENT (No such file or directory)
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 3), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7736000
write(1, "/run/udev\n", 10/run/udev
.....

This caused the initial transition - when no /run at all - to fail. Why ? Simply there is neither "/run/udev" nor "/dev/.udev" during sysinit. In the sys-fs/udev-164-r2 version there is in /etc/init.d/udev-mount :

Code:
101         # make sure it exists
102         mkdir -p /dev/.udev /dev/.udev/rules.d

and in udev-171 such code for /run/udev is missing, instead it is now in /etc/init.d/udev itself - see code bellow.

2.) Later, with /run (and the link from "/var/run -> /run") in place I got the error that there was no file
"/run/udev/rules.d/90-network.rules"
with soon following message that udev couldnt start. Here is the relevant code snippet from /etc/init.d/udev :

Code:
110 start_pre()
111 {
112         if [ -d /run ]; then
113                 checkpath -d -m 0755 -o root:root -q /run/udev
114         fi
115
116         if is_service_enabled network; then
117                 # disable network hotplugging
118                 local f="$(get_rundir)/rules.d/90-network.rules"
119                 echo "# This file disables network hotplug events calling" >> "${f}"
120                 echo "# old-style openrc net scripts" >> "${f}"
121                 echo "# as we use /etc/init.d/network to set up our network" >> "${f}"
122         fi


The error is, that 90-network.rules should reside in rules.d, which never gets created, so writing to it with echo fails.

I first try to statically create the whole directory structure under /run/udev - but next reboot it "disappears" - probbably udev gets mounted - empty - over it. In "post mortem" state (examined with SystemRescueCD) the whole structure is there again.

Then I simply changed the statement at line 113 to create also /run/udev/rules.d . This time no error message - and no keyboard too, udevd simply quits.

3.) Eventually I made a mistake during the downgrades back to the sys-fs/udev-164-r2, thus leaving under /etc/init.d/ the scripts udev-mount, udev and udev-postmount from the udev-171-* version (with my corrections) and the rest - binaries, rules ? - from udev-164-r2. Suprisingly, it worked again.
So Im assuming that the /sbin/udevd causes the problem.

Could someone else - wcg , krinn - check and confirm this ? Any help in this matter is highly appreciated.

Thanks in advance !
Your UncleVan.
Back to top
View user's profile Send private message
krinn
Watchman
Watchman


Joined: 02 May 2003
Posts: 7470

PostPosted: Sat Dec 08, 2012 10:04 pm    Post subject: Reply with quote

To be honest, i'm not quiet sure what you are doing, and most important, what you have done.
LOL i'm even not able to see where is your error or problem.

So here are my current status for udev, hope this will help you. At least, i'm sure plenty users may enjoy or find it useful to see how a working system looks alike if it run.

Here the require for udev:
- CONFIG_DEVTMPFS=y
- CONFIG_DEVTMPFS_MOUNT=y

Another ones many forgot (may not be present depending on kernel version, but if present MUST be disable):
- CONFIG_SYSFS_DEPRECATED=n
- CONFIG_SYSFS_DEPRECATED_V2=n
- CONFIG_IDE=n

I would suggest any drivers for keyboard built-in kernel (just because if you don't, and udev fail for any reason, you won't have a working keyboard). For usb keyboard :
- CONFIG_USB_HID=y
- CONFIG_USB_HIDDEV=y

a basic /dev populate with null, zero and console. Something you could recreate easy with
NeddySeagoon wrote:
and make the missing devices
Code:
Code:
   
mknod --mode=600 console c 5 1
mknod --mode=666 null c 1 3
mknod --mode=666 zero c 1 5   

And here's my current udev version and options :

Code:
sys-fs/udev-171-r9 was built with the following:
USE="gudev hwdb introspection keymap rule_generator -action_modeswitch -build -debug -edd (-extras) -floppy (-selinux) -test"

Code:
cat /etc/portage/package.mask | grep udev
>sys-fs/udev-init-scripts-16
>virtual/udev-172
>sys-fs/udev-172

And my rc-update status releated to udev/booting
Code:

                 dbus |      default                                 
                devfs |                                        sysinit
        device-mapper | boot                                         
                dmesg |                                        sysinit
                 fsck | boot                                         
             hostname | boot                                         
              keymaps | boot                                         
                local |      default nonetwork                       
           localmount | boot                                         
              modules | boot                                         
                 mtab | boot                                         
             net.eth0 |      default                                 
               net.lo | boot                                         
             netmount |      default                                 
            swapfiles | boot                                          (new need by openrc 0.9.9.3)
                sysfs |                                        sysinit (new need openrc-0.11.6)
              nfsmount |      default                                (new need for openrc-0.11.6 and nfs)
       tmpfiles.setup | boot                                          (new need for openrc-0.11.6)
                 udev |                                        sysinit
           udev-mount |                                        sysinit
       udev-postmount |      default                                 


fstab part :
Code:
shm         /dev/shm   tmpfs      nodev,nosuid,noexec   0 0


mount part (except shm, others are add by udev/gentoo, but not present/mount in/from fstab)
Code:
devtmpfs on /dev type devtmpfs (rw,relatime,size=1552388k,nr_inodes=219521,mode=755)
tmpfs on /run type tmpfs (rw,nosuid,nodev,relatime,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
shm on /dev/shm type tmpfs (rw,nosuid,nodev,noexec,relatime)


As you see /run is tmpfs, so anything you do in it, will be lost on next reboot, so the rules.d directory you keep trying to hack to add the persistent files rules for network is a lost cause.
Quote:
Then I simply changed the statement at line 113 to create also /run/udev/rules.d

Udev is doing it, only if is_service_enabled network is true, and because udev should load your network, this service shouldn't be enable, i suppose this hack is here to help transition from older udev to newer version where network might be start before udev. Or more like they said, for an old openrc version (but they refer to "style", so in fact i suppose this is aiming at baselayout1 and not really openrc)
And all it will do anyway is just writing 90-network.rules to disable hotplug events.
At end, nothing you should really care of.

And to answer your next question, but where then is the rules.d/persistent files are wrote ?
Code:
ls -Rl /etc/udev/
/etc/udev/:
total 16
-rwxr-xr-x 1 root root  786 17 juil.  2005 cdsymlinks.conf
drwxr-xr-x 2 root root 4096  8 déc.  21:44 rules.d
drwxr-xr-x 2 root root 4096  1 mars   2008 scripts
-rw-r--r-- 1 root root  277  2 déc.  10:31 udev.conf

/etc/udev/rules.d:
total 8
-rw-r--r-- 1 root root 1910  3 sept. 20:38 70-persistent-cd.rules
-rw-r--r-- 1 root root  441  2 déc.  10:56 70-persistent-net.rules

/etc/udev/scripts:
total 24
-rwxr-xr-x 1 root root 7195 31 juil.  2005 cdsymlinks.sh
-rwxr-xr-x 1 root root   97 12 janv.  2006 dvb.sh
-rwxr-xr-x 1 root root 1259 12 janv.  2006 ide-devfs.sh
-rwxr-xr-x 1 root root 1174 12 janv.  2006 raid-devfs.sh
-rwxr-xr-x 1 root root 2386 12 janv.  2006 scsi-devfs.sh
Back to top
View user's profile Send private message
UncleVan
n00b
n00b


Joined: 08 Feb 2011
Posts: 72

PostPosted: Sun Dec 09, 2012 3:31 pm    Post subject: Reply with quote

Thank you knirr !...quite a lot to do now .
Code:
tmpfs on /run
is a good hint.
But even so, I cant understand who or what is in charge for the directory infrastructure under /run/udev. In the 164 version the statement is quite clear.
And who is doing the mount ?...

My other CONFs are mostly the same as yours; need to check them carefully.

What I described previously is just what happened/happens when I upgrade from udev-164-r2 to udev-171-*, and Ive done just this - nothing unusual.
First time - around last February - there was no /run in the layout; and then the rest are the problems I stumble at any time when I give it a new try. And those errors are obvious and reproducable. In the case uf rules.d/90-network.rules this caused udev to quit.
And Im not reaching the 70-persistent-XX.rules (udev-postmount ?) .

I still have no explanation why this seems to happen only to me...a years-long running system getting broken in such way by udev upgrade. If somebody else - please leave a note !

In my opinion it is not enough just to build-in critical modules if not sure what is really going on.
Ill continue to work on it and let you know if something new happens ;-)

Your UncleVan.
Back to top
View user's profile Send private message
tbart
Apprentice
Apprentice


Joined: 31 Oct 2004
Posts: 151

PostPosted: Mon Dec 10, 2012 12:10 am    Post subject: Reply with quote

just wanted to chime in:
everything's back to normal for me, the scanner and fingerprint reader stuff is also magically solved..


UncleVan: Did you try to put your keyboard drivers (i8042, atkbd) into the kernel? I normally put stuff I cannot remove/live without into the kernel as there's hardly any use in removing it. In a notebook, especially ;->

I am not going to try to make evdev modular again as I am really afraid of breaking anything... And X needs it anyway.

You might be seeing some init problems as well. Is your OpenRC stable/current? (0.11.6 here)
Back to top
View user's profile Send private message
krinn
Watchman
Watchman


Joined: 02 May 2003
Posts: 7470

PostPosted: Mon Dec 10, 2012 1:07 am    Post subject: Reply with quote

UncleVan wrote:

But even so, I cant understand who or what is in charge for the directory infrastructure under /run/udev. In the 164 version the statement is quite clear.
And who is doing the mount ?...

/etc/init.d/bootmisc

And not only udev goes in /run now, so not only bootmisc use it.
Code:

ls /run/
ConsoleKit    cups        lock         pm-utils       sshd.pid
acpid.pid     dbus        lvm          rpc.statd.pid  timidity.pid
acpid.socket  dbus.pid    metalog.pid  rpcbind.lock   udev
console       gdm.pid     mount        rpcbind.sock   udisks
cron.pid      gdm_socket  openrc       sm-notify.pid  utmp
Back to top
View user's profile Send private message
wcg
Guru
Guru


Joined: 06 Jan 2009
Posts: 588

PostPosted: Wed Dec 12, 2012 12:32 am    Post subject: Reply with quote

I do not think I have anything more to comment on here.
I do not use loadable kernel modules, so why loading
the evdev module on demand would have issues is beyond
me.

This could go:
Code:

/run/udev/rules.d/10-root-link.rules


Every time one needs to explain to a newbie which partitions
are being mounted at boot, that thing obscures the output of
the mount command when using it to list mounted partitions.

(Hey, if some program wants to keep track of which partition
is the root partition, it should do it in its own dynamic config
space without polluting the namespace of the mount command.)
_________________
TIA
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Portage & Programming All times are GMT
Goto page Previous  1, 2
Page 2 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum