# udevd-event do not use %e it is deprecated

## -=GGW=- $ol!d $n4>|e

ok, on startup i'm trying to do a framebuffer boot. The problem is, everytime before the progress bar starts moving i get 2 ugly warnings at the top that say something like

 *Quote:*   

> 
> 
> udevd-event do not use %e it is depricated and will be removed, use <something> instead.
> 
> udevd-event do not use %e it is depricated and will be removed, use <something> instead.
> ...

 

I can't give what it actually says because i cant find it in /var/log/messages and dunno where else to look. Does anyone know where I should go to change this, it is really annoying and has been like this for at least half a year.

----------

## alienjon

This problem isn't new. I've had it for a while now. It's just something in the code itself, but from what I hear does not actually do any harm. I'm afraid all I can say is to not worry about it.

(I don't know for you, but in mine it only appears for a moment or two and then dissapears)

----------

## jstead1

I also have the same problem.

As I recall, the issue is with how udev will name a device using the variable, I think it is that if two devices are detected near simultaneously, they could be named the same thing.

I didn't try real hard, but I couldn't come up with something that works better.  So for now, don't try to cram four usb keys into your box at the same time, and you should be fine.

On second thought, if someone would like to give it a shot, and actually cause a problem by doing something like that, it would be pretty cool   :Smile: 

----------

## ferreirafm

I have the same problem as well.

```

* Letting udev process events ...

udevd-event[4835]: find_free_number: %e is deprecated, will be removed and is

unlikey to work correctly. Don't use it.

```

What does it means??   :Rolling Eyes: 

----------

## WhiteSpade

I had this too so I looked all around and I think I may have found the answer here. *Quote:*   

> W.r.t. the "%e is deprecated" warning, I had it too, here's how I fixed it; I'm using Gentoo not Mepis (which I presume is a Linux distro), your setup maybe a little different.
> 
> The default rules file that came with my distro (/etc/udev/rules.d/50-udev.rules) contained the following:
> 
> # cdrom symlinks and other good cdrom naming
> ...

 I hope this helps.  I'm going to try it later (after I hunt down the answers to a few other minor annoyances I'm having).

---Alex

----------

## WhiteSpade

It works, gloriously.  I made a few changes to what he suggested since I have a DVD and a DVD-RW drive (as opposed to CD-RW and DVD).  If the original author could test this out and then mark [SOLVED] for this thread (provided it works for him too)  that would be great.

---Alex

----------

## ferreirafm

It's also works on my box. However, I just remove the "%e" staff, keeping SYMLINKS unaltered.

```

ENV{ID_CDROM}=="?*",            SYMLINK+="cdrom", GROUP="cdrom"

ENV{ID_CDROM_CD_RW}=="?*",      SYMLINK+="cdrw"

ENV{ID_CDROM_DVD}=="?*",        SYMLINK+="dvd"

ENV{ID_CDROM_DVD_R}=="?*",      SYMLINK+="dvdrw"

```

G'Ĺuck

----------

## dj_farid

I have also hadd this problem for ages. Shouldn't this be filed as a bug, so that it gets changed in the future releases?

----------

## whiskas

I solved this by upgrading to the latest unstable sys-fs/udev release (103 at the time of writing this). Paff, the problem went away and no new ones have appeared since then.

----------

## Headrush

 *whiskas wrote:*   

> I solved this by upgrading to the latest unstable sys-fs/udev release (103 at the time of writing this). Paff, the problem went away and no new ones have appeared since then.

 

ditto.

Forget the bug report as this has been know for a long time already.

-=GGW=- $ol!d $n4>|e, I believe you can enabled boot logging in /etc/conf.d/rc to gather boot log messages. (RC_BOOTLOG="no")

----------

## Zwartoog

 *Quote:*   

> I solved this by upgrading to the latest unstable sys-fs/udev release (103 at the time of writing this). Paff, the problem went away and no new ones have appeared since then.

 

According to the udev changelog, updating to version 094 is enough. I do not like to upgrade a critical system package to the most unstable version. Note that you have to unmerge coldplugging first if you have it installed:

```

rc-update del coldplug

emerge -C coldplug

emerge -C udev

echo "~sys-fs/udev-094 ~amd64" >> /etc/portage/package.keywords

emerge -1 udev

```

----------

## dj_farid

 *Zwartoog wrote:*   

>  *Quote:*   I solved this by upgrading to the latest unstable sys-fs/udev release (103 at the time of writing this). Paff, the problem went away and no new ones have appeared since then. 
> 
> According to the udev changelog, updating to version 094 is enough. I do not like to upgrade a critical system package to the most unstable version. Note that you have to unmerge coldplugging first if you have it installed:
> 
> ```
> ...

 

Why do you have to unemerge coldplug? I never did...

----------

## Zwartoog

 *Quote:*   

> 
> 
> Why do you have to unemerge coldplug? I never did...
> 
> 

 

From /usr/portage/sys-fs/udev/udev-094.ebuild:

```

# still rely on hotplug (need to fix that), but now we implement coldplug

DEPEND="sys-apps/hotplug-base"

RDEPEND="!sys-apps/coldplug"

```

And after emerging, this will be displayed if there is some coldplug left:

```

        if [[ ${coldplug_stale} == "1" ]] ; then

                ewarn "A stale coldplug init script found. You should run:"

                ewarn

                ewarn "      rc-update del coldplug"

                ewarn "      rm -f /etc/init.d/coldplug"

                ewarn

                ewarn "udev now provides its own coldplug functionality."

        fi

```

Perhaps coldplug was never installed on your system...

----------

