Somewhere in this guide, it should be added that if you are switching from devfs
to udev, you must delete the /dev/.devfsd file manually. If that file is left
there, udev will not start, and if there is no longer any devfs (automatically
mount at boot) support in your kernel, devfs won't start either and you get a
kind message from the gentoo devs saying you have support for neither and to
read the above page. When you delete that file, udev starts up fine.
This fix could also be added to the udev ebuild.
Steps to Reproduce:
1. remove devfs (automatically mount at boot) support from kernel
2. emerge udev
4. read error message
no /dev/hd* devices in /dev
Umm, I used the same guide to switch from defs to udev and faced *no* such
issues what so ever. I'm tending towards a WORKSFORME here.
(In reply to comment #0)
> Steps to Reproduce:
> 1. remove devfs (automatically mount at boot) support from kernel
> 2. emerge udev
> 3. reboot
> 4. read error message
The steps in guide ask you to emerge udev, hotplug, coldplug and then go onto
the kernel parts. Also the RC_DEVICE_TARBALL part is quite important. Have you
tried that? Do you still get the same error?
Do as you like, I just switched 2 servers to udev, from devfs and faced the same
issue on both of them. Maybe the ebuild for udev has been changed since you did
it, I'm not sure. Either way, the ONLY thing I had to do, was remove a static
file from /dev called .devfsd and udev worked perfectly. I followed the
directions to the letter, just put them in the wrong order on the bug report.
When I hit "If you want to use the udev-tweaks Gentoo added to make your life
comfortable, then read no more." I stopped. ;)
Maybe the rc-device-tarball kept that file. I'm not sure.
(In reply to comment #3)
> Do as you like, I just switched 2 servers to udev,
We don't do as we like, or I'd have marked this WORKSFORME a long time back and
we won't be having this discussion. We're trying to sort out a possible
issue...that tone of yours doesn't help at all.
> it, I'm not sure. Either way, the ONLY thing I had to do, was remove a static
> file from /dev called .devfsd and udev worked perfectly. I followed the
> directions to the letter, just put them in the wrong order on the bug report.
> Maybe the rc-device-tarball kept that file. I'm not sure.
If you had that set to yes, then chances are that's the cause of your issues.
Since that creates a tarball of /dev and uses that tarball at startup. It would
have preserved the .devfsd file as well. Did you have it set to yes?
i've converted 4 computers from devfs to udev recently, and i've not had this
problem. i don't think this is a docs bug. if you are really having this issue,
perhaps this bug should be filed to the maintainer/herd of udev
How's this for tone.
The point of this bug was just to let you know of an issue I was having that may
affect others. A simple note on the page or something along those lines would
have been sufficient. If you took offense to my tone, that was not my intention
at all. I'm converting another server from devfs to udev later today following
the instructions on that page and I'll see how it goes from there. Thank you.
hey now... no need to get hostile. either of you.
the point is simply that we can't reproduce this problem.
No problem at all, now that I know what I'm looking for. I'll be able to
document the steps taken and see if it happens again so it can be reproduced by
On the 2 systems I have done already. RC_DEVICE_TARBALL="yes" was specified, so
I'm pretty sure that's what happened. Thanks for the suggestion Shyam.
if you search bugzilla this has come up from time to time
usually it's with very old installs though
I had no problem switching to udev, either.
Robert, the problem lays under the udev maintainer plaground, not docs-team,
because the udev guide is not a troubleshooting guide. Generally, the docs-team
tries not to insert troubleshooting content into the normal guides (there are
also troubleshooting guides which treat those problems). So, if the problem
indeed exists, it should be solved by the udev installation process
automatically and not by manual tricks (like deleting /dev/.devsfd).
I everyone agrees, please reassing this bug to the udev maintainer or to the bug
(In reply to comment #11)
> also troubleshooting guides which treat those problems). So, if the problem
> indeed exists, it should be solved by the udev installation process
> automatically and not by manual tricks (like deleting /dev/.devsfd).
> I everyone agrees, please reassing this bug to the udev maintainer or to the bug
Alin, RC_DEVICE_TARBALL was set to yes, which caused the .devfsd file to be
saved. So, there is no bug as such. And the guide did specify that
RC_DEVICE_TARBALL had to be set to no. Hence I see no point in re-assigning....
I converted one other box to udev tonight and had the same result as before,
most of these are 1-2+ year old installs. After setting the RC_DEVICE_TARBALL
var to no, it seems to have started with a fresh /dev and fixed itself.
The "If you want to use the udev-tweaks Gentoo added to make your life
comfortable, then read no more." statement is still a little misleading, but
that's okay. Thanks to everyone for clearing that up for me, and take it easy. =)