udevd - rmdir(/dev/.udev/failed) failed: Permission denied
 

I'm getting this in syslog (and on console at boot).


Elsewise things seem pretty normal - but it has screwed up nVidia so I've fallen back to using the "nv" module. What's going on? How to fix it?

/dev/.udev doesn't contain "failed" but does have "db" in it..

Show the output of the following commands:
ls /var/log/packages/{sysvinit,udev}*
uname -r

/var/log/packages/sysvinit-2.84-i486-69 /var/log/packages/udev-097-i486-10

---

2.6.16.13pbhj (self compiled)

---

Actually, for the moment I've cured this. I recompiled my kernel. No change in the src used, probably a slightly different config (as am now using USB DSL modules for my speedtouch modem).

Weirdly, if I boot the old kernel the error comes back. This error only appeared recently though and I've been using that kernel for a good while.

What were you going to suggest, udev is a mystery to me???!

I was going to suggest that you try to reproduce the issue on the official 2.6.17.13 kernel included with Slackware :)
I've been helping (in some small way) PiterPunk with the udev and sysvinit experimentation, and we've found that quite a few of the bug reports we get are due to improperly configured custom kernels.

RW

Well thanks for the suggestion. I've never installed a slackware kernel other than the one that came with Slackware when I first installed (Slack 9 for this computer, though I used it on previous computers - loaded from floppies).

I just read the other day that I'm supposed to keep the kernel source at /usr/src/linux untouched and do my compiling elsewhere! News to me and I've only been compiling kernels for about 5 years or so!!

At least if anyone gets that error now then they know to "use the official kernel".

I think "supposed to" is a bit strong. The whole "leave /usr/src/linux alone" is largely a remnant from the days when the kernel headers weren't shipped as a separate package. In those days, the distribution maintainer either copied or symlinked the kernel headers in /usr/src/linux-$VERSION/include/{linux,asm} to /usr/include/{linux,asm}. From what I've read, the symlink was more popular; essentially, the maintainers symlinked /usr/src/linux to /usr/src/linux-$VERSION, then made the include symlinks to /usr/src/linux. After the distro shipped, if the user installed a newer kernel and changed the /usr/src/linux symlink to point to the running kernel sources, then see Linus Torvalds' explanation of what can happen:
http://uwsg.iu.edu/hypermail/linux/k...07.3/0587.html

If I remember correctly, Slackware was one of the first (if not the first) distributions to start shipping a separate package of the kernel headers that were used to compile glibc, thereby making the symlink to /usr/src/linux completely irrelevant. As a side note, Pat's warning about upgrading the kernel-headers package probably makes a bit more sense now...

To my knowledge, the only reason for the continuing presence of the /usr/src/linux symlink to the running kernel sources is due to the fact that some external software that builds kernel modules looks there. The proper place to look now is /lib/modules/$(uname -r)/source, and *most* applications do that now, but there are still a few non-compliant ones out there. If you run across these, please contact the author and kindly ask them to fix it.

Anyway, to sum up, it really doesn't matter whether you build kernels in /usr/src/ or /home/imadumbshit - the proper links to the source directory will be created by the 'make modules_install' run (just make sure you don't delete that source directory). As for building as a normal user or as root, you'll find valid arguments for each. Ultimately, it's your call.

To clarify, that's not to say that you should *USE* the official kernels necessarily, but if you're experiencing a problem that might be related to kernel configuration, you should reproduce the issue on an official kernel. I wish I could get back all the time I've spent debugging issues (both my own and others') due to incomplete/incorrect kernel configs. If a problem can be reproduced with one of the official kernels, then it's much more likely that it's actually a problem with the other piece of the puzzle (in this case, udev).

Sorry for the book :)

RW

Interesting reading..
I too am experiencing a LARGE WHACK of odd 'errors' from udev during bootup, since recompiling my kernel again. I have made about 40 kernels to date, and about 97% of them worked and booted fine, no problems; whether they performed exactly how I had planned was a different issue, but either way, they all booted perfectly, EXCEPT for TWO compilations.
The one I am using right now (2.6.17.13) was 100% perfect until I :
-- installed the nVidia driver for my Geforce4 MX440 AGP8X video card, and...
-- had to recompile the kernel WITHOUT nVidia framebuffer support, per instructions given by the
nVidia driver installer.

The kernel itself works perfectly, as does the nVidia driver now installed. However, during boot I get about (guessing) 100 udev errors scrolling by telling me that such-and-such in the directory 'dev/.udev/blah..blah...blah..vm-something or other...symlink already exists'
And shortly after that another series of about a dozen similar udev errors, again referring to the 'dev/.udev/' directory about 'file-not-found error'.

I don't recall what version or circumstances of the kernel were in effect the last time this happened, but since functionality-wise everything appears to be working as it should right now, I have been looking high and low for information about udev in general and/or about the stuff inside the hidden folder 'dev/.udev/'.
Can anyone tell me/us what this folder's contents are for? I am tempted to relocate the contents and see what happens, but would like more info first.

Thanks!

Perhaps I should add as a footnote:
1.. I thought /dev was a virtual-type of filesystem, which was recreated with each boot.. If that's the case (I am seemingly wrong on this one) then how can one be getting 'Symlink already exists' errors?

2... I tried last night 'deleting' everything in /dev (I actually moved it all into a folder) and tried rebooting. LOL, of course the kernel panic'd and stopped. I hadda load ubuntu and move all the /dev junk back to where I got it.

3.. Oh, and yes, I would love to post a sample of the mass of errors I get, but I can't seem to locate any log of them, in dmesg, syslog, debug, or messages. Where might I find them?

4.. If I have everything I need compiled into my kernel for ALL of my hardware, do I even need to use udev and/or hotplug? Or would I be jumping the gun in chmodding rc.udev and/or rc.hotplug to UN-executable?
:)

I don't recall the exact cause of those, but iirc, it has something to do with the deprecated WAIT_FOR_SYSFS calls. That's gone from the newer udev stuff that PiterPunk has been working on.

Hehe... yeah, don't do that. I'm not looking at the init scripts from 11.0 right now (and it's more trouble than I'm willing to go through at the moment to look at them), but iirc, rc.udev doesn't start early enough in the boot process to allow complete removal of the devs package (and thus its contents). There's work ongoing in this area.

Again, iirc, another issue with where rc.udev is started in 11.0 - it's started before syslogd if my memory serves correctly. I may be wrong though...

That should be fine - if you have *all* needed hardware support compiled statically into your kernel and/or you use /etc/rc.d/rc.modules to "force-load" any needed modules, then you shouldn't need hotplug/udev at all.

Udev
 

Oddly enough, I recently upgraded to udev 103 or 105, I think.. By upgrade, I mean, I uninstalled my original one, downloaded the newer one, and installed it. The odd part is that when I use swaret or slackpkg to search my system for udev, they tell me that I am using 071..
Weird.
Anyways, to get to my point: I moved the start of syslog to directly before the first call to rc.udev in my rc. scripts, and then directed the outputs of every udev function to a file which gets recreated during boot so I would have a record of what is going on.
Here is the average results from udev-related- functions during my boot:
cp: cannot stat `/dev/swap': No such file or directory
cp: cannot stat `/dev/swap': No such file or directory
cp: cannot stat `/dev/defaults': No such file or directory
cp: cannot stat `/dev/0': No such file or directory
FATAL: Module input:b0011v0002p0005e0055_e0,1,2,k110,111,112,r0,1,8,amlsfw not found.
FATAL: Module input:b0019v0000p0001e0000_e0,1,k74,ramlsfw not found.
FATAL: Module pci:v00008086d000024C2sv00001462sd00005800bc0Csc03i00 not found.
FATAL: Module input:b0019v0000p0002e0000_e0,1,k74,ramlsfw not found.
FATAL: Module pci:v00008086d000024C4sv00001462sd00005800bc0Csc03i00 not found.
FATAL: Module pci:v00008086d000024C7sv00001462sd00005800bc0Csc03i00 not found.
FATAL: Module pci:v00008086d000024CDsv00001462sd00003981bc0Csc03i20 not found.
FATAL: Module pci:v00008086d0000244Esv00000000sd00000000bc06sc04i00 not found.
FATAL: Module pnp:dPNP0c04 not found.
FATAL: Module pci:v00008086d000024CBsv00001462sd00005800bc01sc01i8a not found.
FATAL: Module floppy not found.
FATAL: Module i8042 not found.
FATAL: Module pnp:dPNP0b00 not found.
FATAL: Module pcspkr not found.
FATAL: Module serial8250 not found.
FATAL: Module vesafb not found.
FATAL: Module pci:v00008086d000024C3sv00001462sd00005800bc0Csc05i00 not found.
FATAL: Module pci:v00008086d00002561sv00000000sd00000000bc06sc04i00 not found.
FATAL: Module input:b0011v0001p0001eAB41_e0,1,4,11,14,k71,72,73,74,75,76,77,79,7A,7B,7C,7D,7E,7F,80,8C,8E,8F,96,9B ,9C,9D,9E,9F,A3,A4,A5,A6,AD,B7,B8,B9,D9,E2,ram4,l0,1,2,sfw not found.
FATAL: Module pnp:dPNP0a03 not found.
FATAL: Module pnp:dPNP0200 not found.
FATAL: Module pcspkr not found.
FATAL: Module pci:v00008086d000024C5sv00001462sd00005800bc04sc01i00 not found.
FATAL: Module pnp:dPNP0c02 not found.
FATAL: Module pnp:dPNP0f13 not found.
FATAL: Module floppy not found.
FATAL: Module pnp:dINT0800 not found.
FATAL: Module atkbd not found.
FATAL: Module pnp:dPNP030b not found.
FATAL: Module pci:v00008086d00002560sv00001462sd00005800bc06sc00i00 not found.
FATAL: Module pci:v00008086d000024C0sv00000000sd00000000bc06sc01i00 not found.


Perhaps this will help someone debug the udev boot process, and if someone has handy a good email address where I should maybe send this stuff for the 'experts' to examine, please do post it.
I will update again once I determine for sure which udev I am running.
PS--- Despite the above junk, my system runs perfectly, no device errors or anything during operation.

If you are interested in testing bleeding edge versions of udev in Slackware, then see PiterPunk's site: http://piterpunk.info02.com.br/extra/ He is the guy who does most (if not all) of the initial work on getting newer udev releases ready for inclusion in Slackware.

To be honest (and to sound somewhat brutal), we're not interested in "bug reports" of self-compiled udev (unless, perhaps, you use the sources from PiterPunk to compiled it).

Both of those tools use the Slackware pkgtool(8) suite to determine versions of installed software. If something is added to the system using a method other than pkgtool(8) and friends, then there's no way that the slackpkg/swaret/slapt-get tools are going to know about it. What you have on your system right now is a mixture of udev-071 and udev-whatever_other_version_you_installed. The udev-071 is installed to /usr (as packaged software should be), and the other one is probably installed to /usr/local (assuming you didn't change any of the build arguments). You're almost certainly using the rc.udev from udev-071, and coupled with the fact that you've got two different versions of udev sitting around in different places (with some of each probably getting executed depending on other factors), I'm extremely surprised that you're not having problems (or that your system even boots).

See the post above for my recommendation. You will need to uninstall all of your custom udev handiwork (hopefully the Makefile has an 'uninstall' target) and either reinstall the stock udev version (which, by the way, was NOT 071 in Slackware 11.0) and/or one of PiterPunk's testing versions (now at 104). If you plan to test PiterPunk's stuff, be sure to read (and FOLLOW) all directions on his site. I realize that his English isn't perfect [1], so if something isn't clear, feel free to ask me.

[1] His coding is great though :)

Ok cool, thanks for the tips. To clarify:
This is not any custom-compiled udev's, they are as they came and compiled normally.
And yes, everything boots and runs perfectly, and infact while I used to have 650+ things lying around in /dev, it is now significantly less, which I like.
RE: The original udev was 09x, NOT 071 as I incorrectly stated above.
No build arguments were used as I said.
And, I used package-tool to remove the installed versions BEFORE installing the new one with the same tool. Swaret is simply reporting back to me the last udev version I installed with Swaret, which is obviously incorrect (learn something new every day huh? :) ) I do not have several versions mixed together.
;) Brutality is good, especially where it concerns honesty. I can't imagine anyone being willing to debug custom compiled things, that would be a never ending proposition.
BTW, I got udev 103 (Correction) from one of the Slackware mirrors in the current/extra directory. Is is indeed UDEV 103, as verifed using UDEVINFO --v
While I'm not particularly interested in becoming a full-time-bleeding-edge-tester, I'm not about to shy away from testing a newer version of something in the hopes that old problems will be resolved, and matter of fact, in this case, I have reduced the udev-errors during boot from well over 100 or more, to what you now see above; before this upgrade, every single error was related to items in the udev/.udev/failed folder, whereas now, I dunno where they are sprouting from. One **guess** is that the errors are based on items which USED to be in my /dev folder every boot, and which the new udev is aware of, but are no longer needed for anything. I mean, my media and HD's are all mounted fine, fstab stuff is all working, all devices and everything work fine, etc.. So it isn't a *big* deal, but if there's more I can do to maybe get rid of the errors totally, I'll experiment more.
PS - Yes, it is installed to /usr, there's no udev stuff in /local or anywhere else, I tend to closely follow the compiler output and pay attention to the install/remove stdout details and paths, mainly to see that the new version of something goes to where the old one came from ;).

Okay, well, you're definitely in better shape than I originally thought :)

To clarify my "custom installation" comment, I was using the term "custom" to mean any software installed with make && make install as opposed to using pkgtool(8) (or one of its parts) or one of the third-party tools that uses them (and as such, leaves a record in /var/log/packages). That's why I figured it would be installed to /usr/local, but if you installed a prepackaged version from someone else (or built one using a SlackBuild script), then it most likely puts it in /usr (and either way, you would have installed it with upgradepkg(8), so it wouldn't matter much anyway).

You mention that you got the udev-103 package from a current/extra repo somewhere. I'm curious - I *know* it didn't come from the official Slackware -current tree yet (as of 20070303), and I'm aware of only three places that host udev-103 packages. PiterPunk has them on his site (which I linked earlier), I have them on my site (http://rlworkman.net - and they are identical to PiterPunk's packages except for the BUILD identifier), and LP had some that Ken Z did. I can't speak for Ken's packages on LP, although I *think* his udev package is made to run on a stock 11.0 system. However, I know for certain that the udev-103 package from PiterPunk/me is *NOT* designed to work on a stock 11.0 system - it also requires our newer sysvinit-2.86 package (with many changed init scripts).

http://www.us.kernel.org/pub/linux/u...ernel/hotplug/

This is where I got the UDEV 103 from :)

Hmmm, as far as the 103 of you guys *not* supposed to work on a "stock" Slack-11 system, what do you mean by "stock" ? Mine gets farther from stock every day :P LOL I have changed almost all of my rc.scripts from a tiny bit to.. Well, to more than a tiny bit. I've changed rc.M and rc.S , re: the order in which services are started relative to udev and the syslogger..I've changed the udev/uevents junk over to the newer way with udevtrigger and udevsettle.. The kernel is 2.6.20..
I just got my dual screen/dual X stuff working yesterday (unrelated, but cool :) )
Anyways, I'm keen to know what you may know about the udev103 I got from that link, as well as your feedback on the "stock 11 vs. non-stock" situation, and on what you might suggest I try doing with/to my current udev install to tune it up a little more.
...Just compiling a new kernel as we speak, small experiment, so I'll check back in a little while :)
Take care ;)
Sasha

Okay, then we've got a misunderstanding with respect to custom compiled software. The location pasted above is the upstream source of udev - in other words, that's what the udev developers release. You can certainly get that and compile it locally (as you already know :)), but there are often some other things that need to be taken into account to make sure the whole system is going to play nicely with it (this is especially important with respect to udev).

By a "stock" system, I mean a full installation of Slackware 11.0 that has not been modified. For the purposes of udev development testing, the important parts are the kernel and the init scripts. In order to get good (usable) feedback from testing, we like for people to use the official 2.6.17.13 kernel from /extra or the 2.6.18 kernel from /testing (or the 2.6.18.7 compiled from the same config) and our modified versions of the init scripts as included in the sysvinit-2.86 package.

If you've figured out all (or even most) of the needed changes to stuff for newer udev (especially the ones needed to the rules files), then we'd definitely love to get you involved in testing our stuff.

In reference to your changes of rc.* - well, I understand; sometimes there's just no way around it, and even when there is, sometimes it's the best way. That being said, modifying the stock rc.* scripts (especially rc.{S,M,6}, make upgrades a tremendous headache. Once you go through an upgrade cycle and fight with trying to figure out if your changes are even needed any more, where to put them, and so on, in the new scripts, you'll probably decide that rc.local is a *wonderful* place to put things after all... ;-)

:) LOL @ rc.local.. Hehehe I have a bunch of things in there.. My hdparm settings are in there (rather than make **another** rc.file (which I did first) I just put my IDE device IO settings, save-settings, power-down settings, and also rc.local initializes my motherboard HWsensors stuff.)
Umm, as far as a stock installation, I guess mine doesn't count. However, I do have almost 300 GB free, and it would be small beans to install another Slack-11 installation in another partition, fresh off of the CD's.. In fact, I have been meaning to do this for some time, as it would be a perfect learning/testing ground where I wouldn't risk my actual 'real' install.. You should know, I came full-speed from Windoze XP about 2 months ago after it DESTROYED my old HD and I finally 'threw it out the window' (Windoze I mean, once and for all ;) ) so I am far from an expert, but I am definitely a tuner/tweaker/perfectionist when it comes to this puter :).
That said, I'd be happy to install a 'stock' slack-11 with which to play with your new udev's, for the good of all.
Keep me posted.
Sasha

Just an update for anyone else who might come across this thread, the issues of udev not being able to "rmdir" due to the fact that /dev is a "read-only filesystem" and the "file exists" error when the kernel/boot scripts try to create symlinks which already exists is, indeed related to the kernel config.

I'm running 2.6.24 which I downloaded from kernel.org and just compiled and installed myself. With the stock kernel, no error messages on boot; with the custom (i.e. configured to fit my machine, as opposed to the configuration which comes with Slackware 12) kernel, I get hundreds of these errors. Other than slowing down the boot process, wasting my battery, and annoying me, they don't seem to have any effect. I still have to work on my configuration to get my sound card working and such, but I was hoping that I could get this udev business sorted out first. Since I'm not sure how to find out which options cause it, nor how to find out if my kernel has been compiled "incorrectly," I'm a bit stuck on the "fixing udev errors" front.

I'll post back if I figure it out. In the meantime, if anyone has any suggestions...

I had this same problem; I believe the solution was to enable tempfs support in the kernel under "File systems" -> "Pseudo filesystems" -> "Virtual memory file system support".

That worked for me, no more udev boot errors. Thanks. By the way,
it makes sense because rc.udev checks for tmpfs, which I will have to
look more in detail to know what it does.

Also, the boot message "Triggering udev events" appears twice in my boot,
one some place early and the other one near the end, second one adding "--retry-failed". Don't know what this is.

I reverted back to the stock Slackware 11 configuration and it fixed my problem. I just checked and saw that tempfs is, indeed, enabled. For anyone who's looking for it in the kernel config (as of 2.6.24):

-> File systems
-> Pseudo filesystems
-> Virtual memory file systems support (former shm fs)