http://www.gentoo.org/doc/en/udev-guide.xml 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. Reproducible: Always Steps to Reproduce: 1. remove devfs (automatically mount at boot) support from kernel 2. emerge udev 3. reboot 4. read error message Actual Results: 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. Okay. > 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 someone else. 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 wranglers.
(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 > wranglers. 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. =)
