# udev messages after update

## snIP3r

hi all!

after the recent update to uvdev 149 i get these messages in my /var/log/messages:

```

Mar  8 18:34:37 area52 udevd[13839]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:3

Mar  8 18:34:37 area52 udevd[13839]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:4

Mar  8 18:34:37 area52 udevd[13839]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:3

Mar  8 18:34:37 area52 udevd[13839]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:4

Mar  8 18:34:38 area52 udevd[13839]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:3

Mar  8 18:34:38 area52 udevd[13839]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:4

Mar  8 18:34:40 area52 udevd[13839]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:3

Mar  8 18:34:40 area52 udevd[13839]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:4

Mar  8 18:34:40 area52 udevd[13839]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:3

Mar  8 18:34:40 area52 udevd[13839]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:4

Mar  8 18:34:40 area52 udevd[13839]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:3

Mar  8 18:34:40 area52 udevd[13839]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:4

Mar  8 18:34:40 area52 udevd[13839]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:3

Mar  8 18:34:40 area52 udevd[13839]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:4

Mar  8 18:34:41 area52 udevd[23387]: inotify_add_watch(6, (null), 10) failed: Bad address

Mar  8 18:34:41 area52 udevd[23387]: inotify_add_watch(6, (null), 10) failed: Bad address

Mar  8 18:34:41 area52 udevd[23387]: inotify_add_watch(6, (null), 10) failed: Bad address

Mar  8 18:34:41 area52 udevd[23387]: inotify_add_watch(6, (null), 10) failed: Bad address

Mar  8 18:34:41 area52 udevd[23387]: inotify_add_watch(6, (null), 10) failed: Bad address

Mar  8 18:34:41 area52 udevd[23387]: inotify_add_watch(6, (null), 10) failed: Bad address

Mar  8 18:34:41 area52 udevd[23387]: inotify_add_watch(6, (null), 10) failed: Bad address

Mar  8 18:34:41 area52 udevd[23387]: inotify_add_watch(6, (null), 10) failed: Bad address

Mar  8 18:34:41 area52 udevd[23387]: inotify_add_watch(6, (null), 10) failed: Bad address

Mar  8 18:34:41 area52 udevd[23387]: inotify_add_watch(6, (null), 10) failed: Bad address

Mar  8 18:34:41 area52 udevd[23387]: inotify_add_watch(6, (null), 10) failed: Bad address

Mar  8 18:34:41 area52 udevd[23387]: inotify_add_watch(6, (null), 10) failed: Bad address

Mar  8 18:34:41 area52 udevd[23387]: inotify_add_watch(6, (null), 10) failed: Bad address

Mar  8 18:34:41 area52 udevd[23387]: inotify_add_watch(6, (null), 10) failed: Bad address

Mar  8 18:34:41 area52 udevd[23387]: inotify_add_watch(6, (null), 10) failed: Bad address

Mar  8 18:34:41 area52 udevd[23387]: inotify_add_watch(6, (null), 10) failed: Bad address

Mar  8 18:34:41 area52 udevd[23387]: inotify_add_watch(6, (null), 10) failed: Bad address

Mar  8 18:34:41 area52 udevd[23387]: inotify_add_watch(6, (null), 10) failed: Bad address

Mar  8 18:34:41 area52 udevd[23387]: inotify_add_watch(6, (null), 10) failed: Bad address

Mar  8 18:34:41 area52 udevd[23387]: inotify_add_watch(6, (null), 10) failed: Bad address

Mar  8 18:34:41 area52 udevd[23387]: inotify_add_watch(6, (null), 10) failed: Bad address

Mar  8 18:34:41 area52 udevd[23387]: inotify_add_watch(6, (null), 10) failed: Bad address

Mar  8 18:34:41 area52 udevd[23387]: inotify_add_watch(6, (null), 10) failed: Bad address

Mar  8 18:34:41 area52 udevd[23387]: inotify_add_watch(6, (null), 10) failed: Bad address

Mar  8 18:34:41 area52 udevd[23387]: inotify_add_watch(6, (null), 10) failed: Bad address

Mar  8 18:34:41 area52 udevd[23387]: inotify_add_watch(6, (null), 10) failed: Bad address

Mar  8 18:34:41 area52 udevd[23387]: inotify_add_watch(6, (null), 10) failed: Bad address

Mar  8 18:34:41 area52 udevd[23387]: inotify_add_watch(6, (null), 10) failed: Bad address

Mar  8 18:34:41 area52 udevd[23387]: inotify_add_watch(6, (null), 10) failed: Bad address

Mar  8 18:34:41 area52 udevd[23387]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/70-openct.rules:23

Mar  8 18:34:41 area52 udevd[23387]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/70-openct.rules:27

Mar  8 18:34:41 area52 udevd[23387]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/70-openct.rules:29

Mar  8 18:34:41 area52 udevd[23387]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/70-openct.rules:30

Mar  8 18:34:41 area52 udevd[23387]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/70-openct.rules:32

Mar  8 18:34:41 area52 udevd[23387]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/70-openct.rules:33

Mar  8 18:34:41 area52 udevd[23387]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/70-openct.rules:35

Mar  8 18:34:41 area52 udevd[23387]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/70-openct.rules:37

Mar  8 18:34:41 area52 udevd[23387]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/70-openct.rules:39

Mar  8 18:34:41 area52 udevd[23387]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/70-openct.rules:41

Mar  8 18:34:41 area52 udevd[23387]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/70-openct.rules:48

Mar  8 18:34:41 area52 udevd[23387]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/70-openct.rules:49

Mar  8 18:34:41 area52 udevd[23387]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/70-openct.rules:51

Mar  8 18:34:41 area52 udevd[23387]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/70-openct.rules:52

Mar  8 18:34:41 area52 udevd[23387]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/70-openct.rules:54

Mar  8 18:34:41 area52 udevd[23387]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/70-openct.rules:55

Mar  8 18:34:41 area52 udevd[23387]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/70-openct.rules:56

Mar  8 18:34:41 area52 udevd[23387]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/70-openct.rules:57

Mar  8 18:34:41 area52 udevd[23387]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/70-openct.rules:61

Mar  8 18:34:41 area52 udevd[23387]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/70-openct.rules:63

Mar  8 18:34:41 area52 udevd[23387]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/70-openct.rules:65

Mar  8 18:34:41 area52 udevd[23387]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/70-openct.rules:78

Mar  8 18:34:41 area52 kernel: udev: starting version 149

```

the openct messages can be fixed with help of this bug https://bugs.gentoo.org/show_bug.cgi?id=299739 but i am not sure how to fix lines 23 and 78. can someone perhalps help me with all of this?

thx

snIP3r

----------

## katachi

I'm using a virtual hosting provider, and am experiencing something very similar.  In my case, I updated from udev-141 to udev-149.  I get the same "unknown key 'SYMLINK{unique}'" and "inotify_add_watch(6, (null), 10) failed" messages in /var/log/messages.  I also get this on my console at boot:

```

<clipped>

 * Mounting proc at /proc ...                                             [ ok ]

 * Mounting sysfs at /sys ...                                             [ ok ]

 * /dev is already mounted

mkdir: cannot create directory '/dev/.udev': Read-only file system

mkdir: cannot create directory '/dev/.udev': Read-only file system

mknod: '/dev/kmsg': Read-only file system

ln: cannot remove '/dev/fd': Read-only file system

ln: cannot remove '/dev/stdin': Read-only file system

ln: cannot remove '/dev/stdout': Read-only file system

ln: cannot remove '/dev/stderr': Read-only file system

ln: cannot remove '/dev/core': Read-only file system

touch: cannot touch '/dev/.rcsysinit': Read-only file system

mkdir: cannot create directory '/dev/.udev': Read-only file system

/lib64/udev/write_root_link_rule: line 26: /dev/.udev/rules.d/10-root-link.rules: No such file or directory

/lib64/udev/write_root_link_rule: line 26: /dev/.udev/rules.d/10-root-link.rules: No such file or directory

/lib64/udev/write_root_link_rule: line 26: /dev/.udev/rules.d/10-root-link.rules: No such file or directory

 * Starting udevd ...udevd[1310]: failed to create queue file: No such file or directory

udevd[1310]: error creating queue file

                                                     [ !! ]

No /sbin/udevd found running; none killed

 * Mounting devpts at /dev/pts ...                                        [ ok ]

<clipped>

```

While my system does boot, it's basically screwed.  eth0 doesn't come up, which means Portage is useless.  By experimenting, I've found that the update to 149 itself appears to go fine.  Etc-update, however, wants to merge some updates in the following files:

/etc/init.d/udev

/etc/init.d/udev-mount

/etc/init.d/udev-postmount

  If you don't etc-update, and then reboot, things are OK.  If you do etc-update, and then reboot, the shit hits the fan.

----------

## snIP3r

hi!

i cannot confirm this. using udev 149 on an i686 system (virtual installation) with kernel 2.6.30-gentoo-r8 boots properly. the machine displaying the messages i posted above is an amd64 machine which is not rebooted yet (home server).

if your eth device does not work anymore try to delete this file as suggested:

 *Quote:*   

> 
> 
> persistent-net does assigning fixed names to network devices.                 │
> 
> │If you have problems with the persistent-net rules,                           │
> ...

 

what kernel do you use? see above:

 *Quote:*   

> 
> 
> udev-149 does not support Linux kernel before version 2.6.25!                 │
> 
> │For a reliable udev, use at least kernel 2.6.27
> ...

 

greets

snIP3r

----------

## ecco_the_dolphin

I have the same problem (after latest update):

```
Mar  9 12:47:13 localhost udevd[1260]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:3

Mar  9 12:47:13 localhost udevd[1260]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:4

Mar  9 12:47:13 localhost udevd[1260]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:3

Mar  9 12:47:13 localhost udevd[1260]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:4

Mar  9 12:47:13 localhost udevd[1260]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:3

Mar  9 12:47:13 localhost udevd[1260]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:4

Mar  9 12:47:13 localhost udevd[1260]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:3

Mar  9 12:47:13 localhost udevd[1260]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:4

Mar  9 12:47:13 localhost udevd[1260]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:3

Mar  9 12:47:13 localhost udevd[1260]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:4

Mar  9 12:47:13 localhost udevd[1260]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:3

Mar  9 12:47:13 localhost udevd[1260]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:4

Mar  9 12:47:13 localhost udevd[1260]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:3

Mar  9 12:47:13 localhost udevd[1260]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:4

Mar  9 12:47:13 localhost udevd[1260]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:3

Mar  9 12:47:13 localhost udevd[1260]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:4

Mar  9 12:47:13 localhost udevd[1260]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:3

Mar  9 12:47:13 localhost udevd[1260]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:4

Mar  9 12:47:13 localhost udevd[1260]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:3

Mar  9 12:47:13 localhost udevd[1260]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:4

Mar  9 12:47:13 localhost udevd[1260]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:3

Mar  9 12:47:13 localhost udevd[1260]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:4

Mar  9 12:47:13 localhost udevd[1260]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:3

Mar  9 12:47:13 localhost udevd[1260]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:4

Mar  9 12:47:13 localhost udevd[1260]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:3

Mar  9 12:47:13 localhost udevd[1260]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:4

Mar  9 12:47:13 localhost udevd[1260]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:3

Mar  9 12:47:13 localhost udevd[1260]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:4

Mar  9 12:47:13 localhost udevd[1260]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:3

Mar  9 12:47:13 localhost udevd[1260]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:4

Mar  9 12:47:13 localhost udevd[1260]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:3

Mar  9 12:47:13 localhost udevd[1260]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:4

Mar  9 12:47:13 localhost udevd[1260]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:3

Mar  9 12:47:13 localhost udevd[1260]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:4

Mar  9 12:47:13 localhost udevd[1260]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:3

Mar  9 12:47:13 localhost udevd[1260]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:4

Mar  9 12:47:13 localhost udevd[1260]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:3

Mar  9 12:47:13 localhost udevd[1260]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:4

Mar  9 12:47:13 localhost udevd[1260]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:3

Mar  9 12:47:13 localhost udevd[1260]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:4

Mar  9 12:47:13 localhost udevd[1260]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:3

Mar  9 12:47:13 localhost udevd[1260]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:4

Mar  9 12:47:13 localhost udevd[1260]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:3

Mar  9 12:47:13 localhost udevd[1260]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:4

Mar  9 12:47:13 localhost udevd[1260]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:3

Mar  9 12:47:13 localhost udevd[1260]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:4

Mar  9 12:47:13 localhost udevd[1260]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:3

Mar  9 12:47:13 localhost udevd[1260]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:4

Mar  9 12:47:13 localhost udevd[1260]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:3

Mar  9 12:47:13 localhost udevd[1260]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:4

Mar  9 12:47:14 localhost udevd[1260]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:3

Mar  9 12:47:14 localhost udevd[1260]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:4

Mar  9 12:47:16 localhost udevd[1260]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:3

Mar  9 12:47:16 localhost udevd[1260]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:4

Mar  9 12:47:16 localhost udevd[1260]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:3

Mar  9 12:47:16 localhost udevd[1260]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:4

Mar  9 12:47:16 localhost udevd[1260]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:3

Mar  9 12:47:16 localhost udevd[1260]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:4

Mar  9 12:47:16 localhost udevd[1260]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:3

Mar  9 12:47:16 localhost udevd[1260]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:4

Mar  9 12:47:16 localhost udevd[1260]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:3

Mar  9 12:47:16 localhost udevd[1260]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:4

Mar  9 12:47:16 localhost udevd[1260]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:3

Mar  9 12:47:16 localhost udevd[1260]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:4

Mar  9 12:47:16 localhost udevd[1260]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:3

Mar  9 12:47:16 localhost udevd[1260]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:4

Mar  9 12:47:16 localhost udevd[1260]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:3

Mar  9 12:47:16 localhost udevd[1260]: unknown key 'SYMLINK{unique}' in /lib64/udev/rules.d/50-udev-default.rules:4

Mar  9 12:47:17 localhost udevd[8602]: inotify_add_watch(6, (null), 10) failed: Bad address

Mar  9 12:47:17 localhost udevd[8602]: inotify_add_watch(6, (null), 10) failed: Bad address

Mar  9 12:47:17 localhost udevd[8602]: inotify_add_watch(6, (null), 10) failed: Bad address

Mar  9 12:47:17 localhost udevd[8602]: inotify_add_watch(6, (null), 10) failed: Bad address

Mar  9 12:47:17 localhost udevd[8602]: inotify_add_watch(6, (null), 10) failed: Bad address

Mar  9 12:47:17 localhost udevd[8602]: inotify_add_watch(6, (null), 10) failed: Bad address

Mar  9 12:47:17 localhost udevd[8602]: inotify_add_watch(6, (null), 10) failed: Bad address

Mar  9 12:47:17 localhost udevd[8602]: inotify_add_watch(6, (null), 10) failed: Bad address

Mar  9 12:47:17 localhost udevd[8602]: inotify_add_watch(6, (null), 10) failed: Bad address

Mar  9 12:47:17 localhost udevd[8602]: inotify_add_watch(6, (null), 10) failed: Bad address

Mar  9 12:47:17 localhost udevd[8602]: inotify_add_watch(6, (null), 10) failed: Bad address

Mar  9 12:47:17 localhost udevd[8602]: inotify_add_watch(6, (null), 10) failed: Bad address

Mar  9 12:47:17 localhost udevd[8602]: inotify_add_watch(6, (null), 10) failed: Bad address

Mar  9 12:47:17 localhost udevd[8602]: inotify_add_watch(6, (null), 10) failed: Bad address

Mar  9 12:47:17 localhost udevd[8602]: inotify_add_watch(6, (null), 10) failed: Bad address

Mar  9 12:47:17 localhost udevd[8602]: inotify_add_watch(6, (null), 10) failed: Bad address

Mar  9 12:47:17 localhost udevd[8602]: inotify_add_watch(6, (null), 10) failed: Bad address

Mar  9 12:47:17 localhost udevd[8602]: inotify_add_watch(6, (null), 10) failed: Bad address

Mar  9 12:47:17 localhost udevd[8602]: inotify_add_watch(6, (null), 10) failed: Bad address

Mar  9 12:47:17 localhost udevd[8602]: inotify_add_watch(6, (null), 10) failed: Bad address

Mar  9 12:47:17 localhost udevd[8602]: inotify_add_watch(6, (null), 10) failed: Bad address

Mar  9 12:47:17 localhost udevd[8602]: inotify_add_watch(6, (null), 10) failed: Bad address

Mar  9 12:47:17 localhost udevd[8602]: inotify_add_watch(6, (null), 10) failed: Bad address

Mar  9 12:47:17 localhost udevd[8602]: inotify_add_watch(6, (null), 10) failed: Bad address

Mar  9 12:47:17 localhost udevd[8602]: inotify_add_watch(6, (null), 10) failed: Bad address

Mar  9 12:47:17 localhost udevd[8602]: inotify_add_watch(6, (null), 10) failed: Bad address

Mar  9 12:47:17 localhost udevd[8602]: inotify_add_watch(6, (null), 10) failed: Bad address

Mar  9 12:47:17 localhost udevd[8602]: inotify_add_watch(6, (null), 10) failed: Bad address

Mar  9 12:47:17 localhost udevd[8602]: inotify_add_watch(6, (null), 10) failed: Bad address

Mar  9 12:47:17 localhost udevd[8602]: inotify_add_watch(6, (null), 10) failed: Bad address

Mar  9 12:47:17 localhost udevd[8602]: inotify_add_watch(6, (null), 10) failed: Bad address

Mar  9 12:47:17 localhost udevd[8602]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/90-r5u87x-loader.rules:6

Mar  9 12:47:17 localhost udevd[8602]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/90-r5u87x-loader.rules:7

Mar  9 12:47:17 localhost udevd[8602]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/90-r5u87x-loader.rules:8

Mar  9 12:47:17 localhost udevd[8602]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/90-r5u87x-loader.rules:9

Mar  9 12:47:17 localhost udevd[8602]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/90-r5u87x-loader.rules:10

Mar  9 12:47:17 localhost udevd[8602]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/90-r5u87x-loader.rules:11

Mar  9 12:47:17 localhost udevd[8602]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/90-r5u87x-loader.rules:12

Mar  9 12:47:17 localhost udevd[8602]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/90-r5u87x-loader.rules:13

Mar  9 12:47:17 localhost udevd[8602]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/90-r5u87x-loader.rules:14

Mar  9 12:47:17 localhost udevd[8602]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/90-r5u87x-loader.rules:15

Mar  9 12:47:17 localhost udevd[8602]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/90-r5u87x-loader.rules:16

Mar  9 12:47:17 localhost udevd[8602]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/90-r5u87x-loader.rules:17

Mar  9 12:47:17 localhost udevd[8602]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/90-r5u87x-loader.rules:18

Mar  9 12:47:17 localhost udevd[8602]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/90-r5u87x-loader.rules:19

Mar  9 12:47:17 localhost udevd[8602]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/90-r5u87x-loader.rules:20

Mar  9 12:47:17 localhost udevd[8602]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/90-r5u87x-loader.rules:21

Mar  9 12:47:17 localhost kernel: [44504.945046] udev: starting version 149

```

My kernel is: linux-2.6.31-gentoo-r6.

----------

## ecco_the_dolphin

After I unmerged udev , "rm -rf /etc/udev/ ", and then re-emerged udev the problem is gone.

----------

## snIP3r

 *ecco_the_dolphin wrote:*   

> After I unmerged udev , "rm -rf /etc/udev/ ", and then re-emerged udev the problem is gone.

 

thanks for the workaround but i think this is not an appropriate method. there must be some other way to fix this. any suggestions?

greets

snIP3r

----------

## katachi

 *snIP3r wrote:*   

>  *ecco_the_dolphin wrote:*   After I unmerged udev , "rm -rf /etc/udev/ ", and then re-emerged udev the problem is gone. 
> 
> thanks for the workaround but i think this is not an appropriate method.

 

Agreed.  Deleting /etc/udev might get rid of the log events, but the log events are there to alert us that there is a problem.  I find the "unknown key 'SYMLINK{unique}'" very troubling since – if I recall correctly – that refers to block devices on the system.  I would think that such an error would indicate a serious issue.  At the same time, the lack of similar errors found by Google leads me to believe that there is something unique about our systems that is causing the problem.  Obviously, not everybody with udev-149 is experience this same issue.

Not a solution, but perhaps a piece of the puzzle:

I am using a 2.6.32 kernel, and I can replicate the problem with a .31 kernel as well.  Ironically, while emerging udev, it complained that my kernel was not new enough (a .27 or newer kernel is suggested).   I attribute this to the fact that my system is a virtual guest running on Xen.  Also, I do not have my kernel sources installed, which is perhaps the reason why such a complaint occurred.

----------

## Decibels

I have the kernel source installed, no virtual hosting and still got the messages during boot. But everything seems to be working still.

Haven't investigated further. The system has been up since rebooted yesterday, will look into it later.

----------

## hennep

Did you delete these files: rm /etc/udev/rules.d/70-persistent-net.rules

I got these messages after: "emerge --oneshot sys-fs/udev" 

```
>>> Installing (1 of 1) sys-fs/udev-149

 *                                     

 * Updating persistent-net rules file  

 *                                     

 * restarting udevd now.               

 *                                     

 * If after the udev update removable devices or CD/DVD drives

 * stop working, try re-emerging HAL before filling a bug report

 *                                                              

 * persistent-net does assigning fixed names to network devices.

 * If you have problems with the persistent-net rules,          

 * just delete the rules file                                   

 *      rm /etc/udev/rules.d/70-persistent-net.rules            <-------------------------------

 * and then reboot.                                             

 *                                                              

 * This may however number your devices in a different way than they are now.

 *                                                                           

 * If you build an initramfs including udev, then please                     

 * make sure that the /sbin/udevadm binary gets included,                    

 * and your scripts changed to use it,as it replaces the                     

 * old helper apps udevinfo, udevtrigger, ...                                

 *                                                                           

 * mount options for directory /dev are no longer                            

 * set in /etc/udev/udev.conf, but in /etc/fstab                             

 * as for other directories.                                                 

 *                                                                           

 * devfs-compat use flag is enabled (by default).                            

 * This enables devfs compatible device names.                               

 * If you use /dev/md/*, /dev/loop/* or /dev/rd/*,                           

 * then please migrate over to using the device names                        

 * /dev/md*, /dev/loop* and /dev/ram*.                                       

 * The devfs-compat rules will be removed in the future.                     

 * For reference see Bug #269359.                                            

 *                                                                           

 * For more information on udev on Gentoo, writing udev rules, and           

 *          fixing known issues visit:                                       

 *          http://www.gentoo.org/doc/en/udev-guide.xml                      

 * Messages for package sys-fs/udev-149:

 * 

 * udev-149 does not support Linux kernel before version 2.6.25!

 * For a reliable udev, use at least kernel 2.6.27              

 *                                                              

 * Updating persistent-net rules file

 *

 * restarting udevd now.

 *

 * If after the udev update removable devices or CD/DVD drives

 * stop working, try re-emerging HAL before filling a bug report

 *

 * persistent-net does assigning fixed names to network devices.

 * If you have problems with the persistent-net rules,

 * just delete the rules file

 *      rm /etc/udev/rules.d/70-persistent-net.rules

 * and then reboot.

 *

 * This may however number your devices in a different way than they are now.

 *

 * If you build an initramfs including udev, then please

 * make sure that the /sbin/udevadm binary gets included,

 * and your scripts changed to use it,as it replaces the

 * old helper apps udevinfo, udevtrigger, ...

 *

 * mount options for directory /dev are no longer

 * set in /etc/udev/udev.conf, but in /etc/fstab

 * as for other directories.

 *

 * devfs-compat use flag is enabled (by default).

 * This enables devfs compatible device names.

 * If you use /dev/md/*, /dev/loop/* or /dev/rd/*,

 * then please migrate over to using the device names

 * /dev/md*, /dev/loop* and /dev/ram*.

 * The devfs-compat rules will be removed in the future.

 * For reference see Bug #269359.

 *

 * For more information on udev on Gentoo, writing udev rules, and

 *          fixing known issues visit:

 *          http://www.gentoo.org/doc/en/udev-guide.xml

>>> Auto-cleaning packages...

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

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

```

----------

## katachi

 *snIP3r wrote:*   

> if your eth device does not work anymore try to delete this file as suggested

 

 *hennep wrote:*   

> Did you delete these files: rm /etc/udev/rules.d/70-persistent-net.rules

 

I don't know about other people, but I actually do not have this file on my system.  Neither before, nor after the update to 149.

----------

## katachi

I've been testing more and have narrowed down the problem to running etc-update on /etc/init.d/udev-mount

Here are the differences:

```

Showing differences between /etc/init.d/udev-mount and /etc/init.d/._cfg0000_udev-mount

--- /etc/init.d/udev-mount      2009-11-19 08:26:17.000000000 +0000

+++ /etc/init.d/._cfg0000_udev-mount    2010-03-14 07:56:44.000000000 +0000

@@ -13,16 +13,16 @@

 # Maybe something like udevd --test || exit $?

 check_kernel()

 {

-       if [ $(get_KV) -lt $(KV_to_int '2.6.15') ]; then

+       if [ $(get_KV) -lt $(KV_to_int '2.6.25') ]; then

                eerror "Your kernel is too old to work with this version of udev."

-               eerror "Current udev only supports Linux kernel 2.6.15 and newer."

+               eerror "Current udev only supports Linux kernel 2.6.25 and newer."

                return 1

        fi

 

        yesno "${unreliable_kernel_warning:-yes}" || return 0

 

-       if [ $(get_KV) -lt $(KV_to_int '2.6.22') ]; then

-               ewarn "You need at least Linux kernel 2.6.22 for reliable operation of udev."

+       if [ $(get_KV) -lt $(KV_to_int '2.6.27') ]; then

+               ewarn "You need at least Linux kernel 2.6.27 for reliable operation of udev."

        fi

        return 0

 }

@@ -30,13 +30,20 @@

 

 mount_dev_directory()

 {

+       if mountinfo -q /dev; then

+               einfo "/dev is already mounted"

+               return 0

+       fi

+

        # No options are processed here as they should all be in /etc/fstab

        ebegin "Mounting /dev"

-       if fstabinfo --quiet /dev; then

-               mount -n /dev

-       else

+       if ! fstabinfo --mount /dev; then

+               # we mount devtmpfs if supported

+               local fs=tmpfs

+               grep -qs devtmpfs /proc/filesystems && fs=devtmpfs

+

                # Some devices require exec, Bug #92921

-               mount -n -t tmpfs -o "exec,nosuid,mode=0755,size=10M" udev /dev

+               mount -n -t "$fs" -o "exec,nosuid,mode=0755,size=10M" udev /dev

        fi

        eend $?

 }

@@ -99,7 +106,7 @@

        fi

 

        # make sure it exists

-       mkdir -p /dev/.udev

+       mkdir -p /dev/.udev /dev/.udev/rules.d

        

        seed_dev
```

Running etc-update on the other udev files that need updating seems to not produce any problems.

Can anyone else confirm this?

----------

## snIP3r

 *katachi wrote:*   

>  *snIP3r wrote:*   if your eth device does not work anymore try to delete this file as suggested 
> 
>  *hennep wrote:*   Did you delete these files: rm /etc/udev/rules.d/70-persistent-net.rules 
> 
> I don't know about other people, but I actually do not have this file on my system.  Neither before, nor after the update to 149.

 

hi katachi!

what version did you upgrade? and did you reboot your machine after the upgrade?

greets

snIP3r

----------

## snIP3r

 *katachi wrote:*   

> I've been testing more and have narrowed down the problem to running etc-update on /etc/init.d/udev-mount
> 
> Here are the differences:
> 
> ```
> ...

 

hi!

i upgraded from udev-146-r1 to udev-149 and did a diff on a backup file:

```

rea52 ~ # diff /etc/init.d/udev-mount /backup/20100224/etc/init.d/udev-mount

33,37d32

<       if mountinfo -q /dev; then

<               einfo "/dev is already mounted"

<               return 0

<       fi

<

40,44c35,37

<       if ! fstabinfo --mount /dev; then

<               # we mount devtmpfs if supported

<               local fs=tmpfs

<               grep -qs devtmpfs /proc/filesystems && fs=devtmpfs

<

---

>       if fstabinfo --quiet /dev; then

>               mount -n /dev

>       else

46c39

<               mount -n -t "$fs" -o "exec,nosuid,mode=0755,size=10M" udev /dev

---

>               mount -n -t tmpfs -o "exec,nosuid,mode=0755,size=10M" udev /dev

109c102

<       mkdir -p /dev/.udev /dev/.udev/rules.d

---

>       mkdir -p /dev/.udev

```

so it looks like yours expect the kernel version testing lines...

HTH

snIP3r

----------

## katachi

More testing.  Here is the problem (for me, anyway):

/etc/init.d/udev-mount

```

+       if mountinfo -q /dev; then 

+               einfo "/dev is already mounted" 

+               return 0 

+       fi 

+ 

```

All other modifications to this file appear OK, but the above line causes the problems I've been experiencing.

What version of baselayout are you guys running?

----------

## snIP3r

 *katachi wrote:*   

> More testing.  Here is the problem (for me, anyway):
> 
> /etc/init.d/udev-mount
> 
> ```
> ...

 

area52 ~ $ emerge -s baselayout

Searching...

[ Results for search key : baselayout ]

[ Applications found : 2 ]

*  sys-apps/baselayout

      Latest version available: 1.12.13

      Latest version installed: 1.12.13

----------

## katachi

 *snIP3r wrote:*   

> *  sys-apps/baselayout
> 
>       Latest version available: 1.12.13
> 
>       Latest version installed: 1.12.13

 

That's the same version I have.  On a whim, I tried installing baselayout-2, openrc, and udev-151-r1.  I did this based on a reference I found on a webpage (which I have now unfortunately lost) that the mountinfo "command" (aside: mountinfo is not a command, is it?)– which seemed to be giving problems (see previous post) – is not present in baselayout-1, but is in openrc.  While the install of these ebuilds was successful, udev-151-r1 wanted to merge similar updates to /etc/init.d/udev-mount.  Rebooting produced nearly identical boot-time errors.

----------

## katachi

I have come to the conclusion that my problems are being caused by an incompatibility between recent versions of udev (greater than 141), and the Xen kernel my guest is running.  While I cannot guarantee that this is indeed the problem, I have found incompatibility reports here and here.  As a side note, a very helpful gentleman by the name of Andrew Lyon is providing ebuilds of more recent versions of the Xen kernel for Gentoo based on releases originally made for openSUSE.  I have not tested them, but I suppose that these could possibly solve the problem for those who have the flexibility to install alternate Xen kernels.

For better or worse, I've decided to comment out the troublesome line in /etc/init.d/udev-mount, as it does not appear to negatively impact the system, but rather helps it (for now...).

That said, you guys are not running Gentoo in a virtual environment, yet are still experiencing problems. snIP3r, you indicated that you are getting your log errors on your server even before rebooting, correct?  So you have not rebooted yet?

----------

## snIP3r

 *katachi wrote:*   

> I have come to the conclusion that my problems are being caused by an incompatibility between recent versions of udev (greater than 141), and the Xen kernel my guest is running.  While I cannot guarantee that this is indeed the problem, I have found incompatibility reports here and here.  As a side note, a very helpful gentleman by the name of Andrew Lyon is providing ebuilds of more recent versions of the Xen kernel for Gentoo based on releases originally made for openSUSE.  I have not tested them, but I suppose that these could possibly solve the problem for those who have the flexibility to install alternate Xen kernels.
> 
> For better or worse, I've decided to comment out the troublesome line in /etc/init.d/udev-mount, as it does not appear to negatively impact the system, but rather helps it (for now...).
> 
> That said, you guys are not running Gentoo in a virtual environment, yet are still experiencing problems. snIP3r, you indicated that you are getting your log errors on your server even before rebooting, correct?  So you have not rebooted yet?

 

hi katachi!

thx for your detailed information. to answer your question: yes and no. i am running a gentoo home server (amd64) which shows the messages after teh update. no reboot yet. but udevd restarted, so the messages are displayed. i also have a virtual gentoo installation (i386, for testing purposes) which does not display these messages. so i am not sure what to do next...

greets

snIP3r

----------

## katachi

@snIP3r

I wish I could provide more help. I suppose that your only options are:

1) cross your fingers and reboot (hopefully you've got a backup from before the udev update).  I don't know if this is possible, but maybe you could keep a downloaded version of the ebuild/source of your previously-working udev version on the home server, and fall back on that if you are unable to boot with a working net connection.  I've never tried such a thing, and don't even know if it's possible.

2) move back down to the previously-working udev version before you reboot, and then mask that nothing above that version should be emerged

3) wait for someone who is more knowledgeable about this issue.

Am I correct in assuming that the log errors are not reoccurring -- that is, they appeared in the log after udev restarted, but have not appeared since then?

----------

## snIP3r

 *katachi wrote:*   

> @snIP3r
> 
> I wish I could provide more help. I suppose that your only options are:
> 
> 1) cross your fingers and reboot (hopefully you've got a backup from before the udev update).  I don't know if this is possible, but maybe you could keep a downloaded version of the ebuild/source of your previously-working udev version on the home server, and fall back on that if you are unable to boot with a working net connection.  I've never tried such a thing, and don't even know if it's possible.
> ...

 

hi katachi!

yes the errors have not reoccurred yet. they only showed while restarting udev during upgrade. rebooting is not an option actually (i will wait for a newer kernel until next reboot) and as far as i have read, machines boot correctly after restart. but now i think its time to open a bug for further help...

greets

snIP3r

----------

## Randy Andy

Hi Folks,

i guess you have overlooked to change your kernel config accordingly, to the hints into the log.file at the beginning of this thread.

Did you all Disable CONFIG_SYSFS_DEPRECATED _and_ CONFIG_SYSFS_DEPRECATED into the kernel config?

See also here:

https://forums.gentoo.org/viewtopic-t-712186-highlight-configsysfs+deprecated.html

and work accordingly. 

Then everthing should work with your packages higher than udev-149 and the belonging rules / config files.

I hope this will solve you trouble...

Andy.

----------

## snIP3r

 *Randy Andy wrote:*   

> 
> 
> Did you all Disable CONFIG_SYSFS_DEPRECATED _and_ CONFIG_SYSFS_DEPRECATED into the kernel config?
> 
> 

 

hi randy andy!

thx for your advice, but i had it disabled for some time, cause it is suggested to disable in earlier versions of udev:

```

area52 ~ # less /usr/src/linux/.config |grep SYSFS

# CONFIG_SYSFS_DEPRECATED_V2 is not set

CONFIG_ACPI_SYSFS_POWER=y

# CONFIG_GPIO_SYSFS is not set

CONFIG_SYSFS=y

```

greets

snIP3r

----------

## snIP3r

hi all!

for me this issue is solved now. after re-emerging udev 149 and replacing the faulty 70-openct-rules file (from gentoo-bug tracking list #299440) i got no more error messages while restarting udev.

```

...

Mar 16 18:26:28 area52 kernel: udev: starting version 149

...

```

even though the issue is solved for me i will leave this thread open so others can get help.

HTH

snIP3r

----------

## katachi

@snIP3r

Thank you for the follow-up!

----------

