udev 147 outputs warnings about default rules

[Michael Marley]

Binary package hint: udev

After the latest udev upgrade on Karmic x64 (related to the transition to upstart jobs), my computer produces several udev errors when it is booting. None appear to be serious, and the system still boots properly, but they may be important on other architectures, so I decided to report a bug. I attached a picture of the errors.

This occurred on 32 bit systems as well.

[Alessandro Ghersi (alessandro-ghersi)]

Same here after upstart transition

[syscon-hh (syscon-kono)]

Same to me using -> karmic i386

[Jeremy Wilkins (wjeremy)]

I can also conform that this is occuring on 64bit karmic since latest updates. Not sure if this is because the updates are incomplete or if there is a real problem either, but that notice does not look good.

[Jeremy Wilkins (wjeremy)]

It looks like the two lines that it is failing on are non-essential unless you use the /dev/block/* or /dev/char/* symlinks, but this should not happen nonetheless. It stops the boot splash which is also annoying.

[ilna (a-gaydenko)]

The same for amd64. It seems like the bug prevent evdev to find mouse and keyboard. I have used 'old way' xorg mouse and keyboard drivers and fluxbox to be able to report this confirmation (KDE is not usable - it seems like kwin still needs something provided by udev - only apps canvas are shown - without desktop (which is black) and windows decorations).

[Hilario J. Montoliu (hjmf) (hmontoliu)]

I believe that this is the same as bug #430272 If you try to boot in single you'll get stuck after scripts/init-bootom

[Martin Erik Werner (arand)]

Captured errors in vm.

[Martin Erik Werner (arand)]

Second screenshot

[ilna (a-gaydenko)]

bug #430272 is too wide :-) ATM I have the only issue - exactly as described here - and have no other problems as described in that bug.

[FriedChicken (domlyons)]

Bug #430272 seems to be fixed after the newest updates. But as ilna wrote this bug is not the same. I've got the same error masseages as arand.

[Scott James Remnant (Canonical) (canonical-scott)]

This is perfectly normal, and is to be expected.

We're running a GIT HEAD version of udev to do some testing, the warnings will be fixed with udev upstream next week and result in the udev 147 release proper.

[ilna (a-gaydenko)]

Scott, are there any workarounds for those with single-boot single machine?

There are plenty of reports wrt the issue among bugs and forum threads. Does such massive feedback guess a Low priority?

[ilna (a-gaydenko)]

Just as another illustration the issue importance - say, /dev/dri/ devices are not created, and, as a result, drm is off.

[Scott James Remnant (Canonical) (canonical-scott)]

On Wed, 2009-09-16 at 15:37 +0000, ilna wrote:

> Scott, are there any workarounds for those with single-boot single
> machine?
>
You don't need a workaround for a warning message.

Scott
--
Scott James Remnant
<email address hidden>

[Scott James Remnant (Canonical) (canonical-scott)]

On Wed, 2009-09-16 at 15:52 +0000, ilna wrote:

> Just as another illustration the issue importance - say, /dev/dri/
> devices are not created, and, as a result, drm is off.
>
That would be unrelated to these messages, and thus a different bug
which should be filed separately.

Scott
--
Scott James Remnant
<email address hidden>

[blakamin (blakamin)]

Is this bug going to be present in alpha 6?

[Klaus Doblmann (moviemaniac)]

Yes it is, as alpha 6 will be out today and the bug will be fixed next week.

[knarf (launchpad-ubuntu-f)]

Edit that file (/lib/udev/rules.d/50-udev-default.rules) and remove the 'unique' classifiers. The attached patch will accomplish this. This solved the issue for me.

[Scott James Remnant (Canonical) (canonical-scott)]

On Thu, 2009-09-17 at 11:19 +0000, knarf wrote:

> Edit that file (/lib/udev/rules.d/50-udev-default.rules) and remove the
> 'unique' classifiers. The attached patch will accomplish this. This
> solved the issue for me.
>
> ** Attachment added: "Revert to normal SYMLINK, remove the 'unique' classifiers"
> http://launchpadlibrarian.net/31965047/udev-50-default-rules-remove-unique.patch
>
DO NOT DO THIS.

You could potentially hose your system. Please just leave this file
alone, it will be fixed next week.

Scott
--
Scott James Remnant
<email address hidden>

[jcwinnie (jcwinnie)]

It would seem to be a problem with more than karmic 64. A similar warning appears at boot up on a Dell Latitude D600 with 2.6.31-10-generic and most recent updates.

[Jasmine Hassan (jasmine-aura)]

This is really lousy of udev developers, knowing such warnings exist, which could be trivially fixed before the release, and yet they release it as it is... At least if they had the courtesy to think that others may well be working on usplash, xsplash, and other *splash stuff, testing things out so they too, can make things "pretty" and meet deadlines before the release date in october... One whole week, *splash developers, splash themes designers, will have wasted while waiting for a udev update for these warnings to go away, and possibly thousands of users will have to put up with the annoyance, 'cause someone thought it was just fine and dandy to release a udev package that just spits out 6 warnings for a week's worth of testing...
If the problem wasn't always reproducible, I'd give them some slack, but IT IS!

[Madis (madisliias)]

I assume this would consume time that could not be consumed on this. And I'm pretty sure Beta is more prioritized than the alpha 6.

[Travis Watkins (amaranth)]

These warnings are not the reason why you aren't seeing usplash. If usplash was running you wouldn't see them at all.

You aren't seeing usplash because it was disabled.

[starslights (starslights)]

Hello,

I have forget to say, after it make the Udev errors, it auto "fcsk" to can boot, i dunno if come from crypto or from this bug

[Daniel Swarbrick (pressureman)]

With respect to the /dev/dri issue, I see that happening too, and it coincided with the appearance of these udev error messages. Without DRM, X is very, very slow. This happens on my system about once in every five boots.... I don't know whether the failure to create /dev/dri nodes are linked to the udev errors, or whether I'm just not seeing the error messages when KMS is successfully enabled. They seem to go hand in hand at the moment though.

See https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/431178

[Robbie Williamson (robbiew)]

changed to Medium because it affects boot experience.

[Keith Drummond (kd353)]

I am affected by this too. Running Karmic Alpha 6, on an Advent 4211 netbook with an Atom processor.

Basically seeing text on start-up (mentioning udev) and after shutdown.

[starslights (starslights)]

kubuntu karmic 64 2.6.31-10-generic

2009-09-19 21:24:03 udevd[1264] NAME="%k" is superfluous and breaks kernel supplied names, please remove it from /lib/udev/rules.d/40-ppc.rules:3
2009-09-19 21:24:03 udevd[1264] NAME="%k" is superfluous and breaks kernel supplied names, please remove it from /lib/udev/rules.d/40-ppc.rules:4
2009-09-19 21:24:03 udevd[1264] NAME="%k" is superfluous and breaks kernel supplied names, please remove it from /lib/udev/rules.d/40-ppc.rules:5
2009-09-19 21:24:03 udevd[1264] unknown key 'SYMLINK{unique}' in /lib/udev/rules.d/50-udev-default.rules:3
2009-09-19 21:24:03 udevd[1264] unknown key 'SYMLINK{unique}' in /lib/udev/rules.d/50-udev-default.rules:4
2009-09-19 21:24:10 dbus-daemon Reloaded configuration

[Dylan Taylor (dylanmtaylor)]

I am also affected by this bug. Running Karmic with all updates installed on x86 build.

[Jasmine Hassan (jasmine-aura)]

In comment #24 by Travis Watkins:
>These warnings are not the reason why you aren't seeing usplash. If usplash was running you wouldn't see them at all.
>You aren't seeing usplash because it was disabled.

I'm pretty sure usplash is enabled... It was working absolutely fine, up until the udev upgrade. Moreoever, the framebuffer module is loaded from initramfs, evidently because the console resolution is changed to 1024x768 right before the udev errors appear on the screen (before anything else).
At reboot, usplash certainly splashes the all-too-familiar shutdown screen, and I'm pretty certain it's not xsplash or anything else, because I had previously purged xsplash.

I remember in the days of using gentoo and fbsplash, if there were such early errors/warning, sometimes they would show through the fbsplash image, but ..

usplash is not fbsplash.. :)

Moreover, the issue is not only with a custom kernel, because it is also exhibited with booting any of the generic kernels..

And I just upgraded udev to ~147-2 from the latest updates, and the issue still persists (the warnings still show very first thing on console after kernel bootstrap)

[zniavre (zniavre2048-gmail)]

as jasmineaura i upgraded udev few minutes ago and it 's exactly the same as before.

karmic on 2.6.31-10-generic

good evening (bon courage)

[Jasmine Hassan (jasmine-aura)]

Moreover, there's a thread on ubuntuforums:

http://ubuntuforums.org/showthread.php?t=1267658&page=3

You can see on the first post on that third page of the thread a sarcastic comment "The error is nice for bootscreen", clearly implying no usplash after the udev upgrade. Similar to the original poster's comment (first post in thread): "I now see some crazy boot messages that delay or keep xsplash from working"

Certainly, I'm not the only one out there with usplash-stopped-working-due-to-udev-warnings problem :)

[Andrew Rodland (arodland-comcast)]

Correction: you're not the only one who *thinks* they have such a problem, due to ignorant people shouting ignorant things in an echo chamber.

[Jasmine Hassan (jasmine-aura)]

@ Andrew Rodland

Let's not ASSUME things, because assuming makes an *** out of U and ME :)

jas@dcptc:/etc$ ls -l rc*.d/*usplash
lrwxrwxrwx 1 root root 17 2009-09-17 22:07 rc0.d/K02usplash -> ../init.d/usplash
lrwxrwxrwx 1 root root 17 2009-09-17 22:07 rc1.d/K02usplash -> ../init.d/usplash
lrwxrwxrwx 1 root root 17 2009-09-17 22:07 rc2.d/S98usplash -> ../init.d/usplash
lrwxrwxrwx 1 root root 17 2009-09-17 22:07 rc3.d/S98usplash -> ../init.d/usplash
lrwxrwxrwx 1 root root 17 2009-09-17 22:07 rc4.d/S98usplash -> ../init.d/usplash
lrwxrwxrwx 1 root root 17 2009-09-17 22:07 rc5.d/S98usplash -> ../init.d/usplash
lrwxrwxrwx 1 root root 17 2009-09-17 22:07 rc6.d/K02usplash -> ../init.d/usplash

jas@dcptc:/etc$ sudo grep "splash quiet" /boot/grub/grub.cfg | wc -l
6
jas@dcptc:/etc$ sudo grep "vmlinuz" /boot/grub/grub.cfg | wc -l
6
jas@dcptc:/etc$ sudo grep "initrd" /boot/grub/grub.cfg | wc -l
6

jas@dcptc:/etc$ cat initramfs-tools/modules | grep -v "^#"
neofb
fbcon
vgastate
tileblit
font
bitblit

jas@dcptc:/etc$ apt-cache policy usplash
usplash:
  Installed: 0.5.37
  Candidate: 0.5.37
  Version table:
 *** 0.5.37 0
        500 http://archive.ubuntu.com karmic/main Packages
        100 /var/lib/dpkg/status

jas@dcptc:/etc$ apt-cache policy udev
udev:
  Installed: 147~-2
  Candidate: 147~-2
  Version table:
 *** 147~-2 0
        500 http://archive.ubuntu.com karmic/main Packages
        100 /var/lib/dpkg/status

Cheers

[knarf (launchpad-ubuntu-f)]

PS Scott #20, why would there be any danger of hosing the system by fixing a bug? Those {unique} parameters currently cause problems, they are a new addition to the rules file, it works fine without (just check the file used in Debian for an example). If and when udev starts supporting them they can be put back in the config file. For now they should not be there as they cause problems.

[knarf (launchpad-ubuntu-f)]

PPS: yes I know that usplash has been deactivated...

[Ryan Ash (metalsand)]

knarf,

I'm eager to get booting under 2.6.31, can you explain exactly what needs to
be edited in order for me to squash this bug.

Best,
ashzilla

On Mon, Sep 21, 2009 at 11:55 AM, knarf <email address hidden>wrote:

> PS Scott #20, why would there be any danger of hosing the system by
> fixing a bug? Those {unique} parameters currently cause problems, they
> are a new addition to the rules file, it works fine without (just check
> the file used in Debian for an example). If and when udev starts
> supporting them they can be put back in the config file. For now they
> should not be there as they cause problems.
>
> --
> udev 147 outputs warnings about default rules
> https://bugs.launchpad.net/bugs/430654
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Jasmine Hassan (jasmine-aura)]

Well, everyone keeps saying usplash was disabled, I figured I must be missing something obvious. But it didn't seem as though, because I was mislead...

On September 2nd, 2008, Scott Remnant wrote, on:
http://www.netsplit.com/2009/09/02/making-a-splash/

>You could also argue that we could load the KMS drivers earlier, in the initramfs for example. While possible, this adds a significant time to the boot time for the extra loading and probing required. If we load the KMS driver in the initramfs, it takes about 8-10s to load the X server; if we load the KMS driver in the full system, it only takes about 6-8s to load the X server. Easy win.

>But what if we have to check the filesystem, or enter a decryption passphrase to mount it? That’s why we still have usplash. In those cases we will start usplash to display the progress or request the key. The usplash theme will be themed such that when it finishes, and X starts up, it looks ok frozen for the short time until xsplash replaces it with an identical theme.

So I was under the impression that usplash was here to stay, with the addition of xsplash..

However, on a minimal / "command-line" installed system, xsplash may be too much for the system to handle, in terms of resources, and in terms of graphical support, if a minimal X environment was later installed. For instance, on my test-bed system, a neomagic 256ZX with 4mb video ram is not capable of supporting 24-bit color depth, as its max supported resolution is 1024x768 @ 16-bit depth.

To make matters worse, the new "feature" added by the stream of fixes described in bug #427356 "Boot performance updates", the newly added option "USPLASH=y" to initramsfs-tools was nowhere to be mentioned.. Not in the default /etc/initramfs-tools/initramfs.conf file, nor in `man initramfs.conf`, nor in any of the usplash package files :(
I guess I should open a new seperate bug report to add mention for this new option to `main initramfs.conf` and to at least include "USPLASH=n" in the default initramfs.conf

Apologies to Scott for all the space I wasted here, off-topic.

[SRElysian (srelysian)]

IMO, when using a alpha-state release, one should be glad they are only seeing warnings instead of errors. I've had the same warnings as everyone else and so long as my system is operating properly, I don't care about the warnings so long as I know they will be fixed. As for the off-topic usplash conversation, they are replacing usplash with xsplash. Which I found here: http://digitizor.com/2009/09/19/ubuntu-9-10-does-away-with-the-usplash/

[Launchpad Janitor (janitor)]

This bug was fixed in the package udev - 147~-3

---------------
udev (147~-3) karmic; urgency=low

  * Update to GIT HEAD (still pre 147 release):
    - includes fix from previous revision
    - rename interfaces to <iface>_rename if rename fails. LP: #416782.
    - drop most NAME keys since 2.6.31 supplies them.
    - especially those with just "%k". LP: #430654.
    - fixed SYMLINK option parsing. LP: #430654.

  * Remove 40-alsa.rules now it's not shipped upstream.

 -- Scott James Remnant <email address hidden> Mon, 21 Sep 2009 16:02:32 -0700

[Scott James Remnant (Canonical) (canonical-scott)]

On Fri, 2009-09-18 at 05:59 +0000, jasmineaura wrote:

> This is really lousy of udev developers, knowing such warnings exist, which could be trivially fixed before the release,
> and yet they release it as it is
>
What are you on?

This hasn't been released. There's been no udev 147 release yet, as I
clearly said above *and* in the changelog, we've gone with a pre-release
for testing purposes.

And Ubuntu 9.04 hasn't been released yet either.

Stop bitching about things in a DEVELOPMENT version of Ubuntu.

Scott
--
Scott James Remnant
<email address hidden>

[Jasmine Hassan (jasmine-aura)]

@ #40 SRElysian
Thanks, agreed... Perhaps it was a naive decision of me to upgrade someone's production system (based on their request) to Alpha stage merely for the reason of wanting bleeding edge packages that contain additional language support. Never again :p
Luckily, the (trivial) bug is now fixed and the warnings are gone :)

As to your comment about *splash, I doubt xsplash will replace usplash, simply because u cannot load an X server while running `fsck`, fs requiring encrypted password, etc... Even in the non-exceptional cases, having both usplash and xsplash, usplash kicks in for most of the boot time than xsplash does on my test-bed slow (minimal install) system - P3 500mhz, 192mb PC100 RAM.. That is, usplash for about 16 seconds, no *splash for about a 7-8 second gap, then xsplash for 4-5 seconds :p
Meanwhile, discussion about this is taking place in bug #427356 (Boot Performance Updates), as we agreed this is off-topic here..

[GokuH12 (gokuh12)]

Its fixed for me too the bug itself, but the problem with Xsplash not loading keep going **off-topic
thx for the work :D

[Jasmine Hassan (jasmine-aura)]

@ Scott in #42
>What are you on?

Must've been some really burnt coffee beans, never again :P

I know it's a pre-release, and I know this is all too possible in ALPHA stage, just thought that with the october release deadline drawing close, such surprises weren't very probable, I guessed wrong. I probably was all emo then due to the fact that I auto-clean'ed my apt-cache and there was no way for me to revert back to 147~-1 or earlier..

I apologized in #39 for the wasted space on off-topic discussion due to my ignorance, and I apologize again for my earlier "bitching"... I appreciate all the work, and I actually got a little high off the flaming, lol... Thanks, and keep up the good work :)

[starslights (starslights)]

Hello,

It's fixed for me for the udev but at start it continue to boot with:

clean sda/ .... and it delete something before start normally.

My biggest problem are to need advice, i need to know how i can stop the boot to can copy the message of the execution of the clean process. Now i have no time with 4 cores to can do that.

If someone can help me , that's will be great!

Before make a new report , i will wait a answer, anyway this is appear when udev have make problem, not early.

my best

[starslights (starslights)]

Hello,

The last update done the 23.09.09 for Kubuntu Karmic 64 , have fixed the boot message and start normally yet.

Thanks very much, fixed for me :)

my best

Stars

[dominique (dominiqueoudin)]

me too
  my best too

dom

[nerling (nerling)]

Kubuntu Karmic x64,
I'm experimenting the same issue as ilna describes:
After a upgrade KDE starts, but mouse and keyboard(s) are not usable.
I tried with gdm, but it does not start. (upstart)
I see that no upstart service will be started on boot in my machine. Maybe this is the whole problem!
udev is not starting,too! no pts, no psaux! no tty!

The last upgrade (as from Thu Sep 24 10:33:11 2009 ) does not fix the issue.

Well, I'm not grounching, since it is alpha software, but I was really loving to use Karmic.

[Florian (winks)]

Got it with alpha 5.
Got it again with alpha 6 (reinstall).
First I suspected a "creative" partition layout of
sda1 = NTFS
sda2 = FAT32
sdaX = boot
sdaY = swap
rest = encrypted with LVM inside

It boots fine and all is working, but the message is still there (hp nx7010 laptop)

[bwat47 (bwat47)]

This is NOT fixed for me with a gateway m6862 running karmic 64 bit with all latest updates. specs are (2.0 ghz core2, 4 gb ram, mobility 2600 with fglrx driver)

When I boot I see text messeges saying things like "warning unsupported bios version" and other things, it only goes to the boot screen for a split second most of my boot is text.

[Dan Andreșan (danyer)]

@bwat47, please read the title of this bug.

Check if text you see on screen is coming from udev. It should not, as this is fixed.
The "other" text items might still appear (I have them on my computer), but this is not traced by this bug.

[Kaïs Bejaoui (kais)]

Hi,

I am using the beta and I a still having udev error messages.

can not read '/etc/udev/rules.d/z80_user.rules' f9

z80_user.rules is a symlink to /etc/udev/user.rules which is empty.

[The Recorder (arthurbm)]

I, also, am using the beta and I a still having udev error messages.

can not read '/etc/udev/rules.d/z80_user.rules'

z80_user.rules is a symlink to /etc/udev/user.rules which is empty.

[dlvetter (dlvetter64-deactivatedaccount)]

HOW DO i UNSUBSCRIBE TO THIS

[Michele Mordenti (micmord)]

At dlvetter, search your name on the Subscribers list on the right of this page and click on the unsubscribe icon.