For more information on udev, see udev(8) manpage.
Additional rules for udev should be placed in seperate file in
/etc/udev/rules.d/.
Additional permission rules for udev should be placed in seperate file
in /etc/udev/permissions.d/.

The steps to upgrade without anaconda or a rescue CD are (NOT
recommended):
- start from a kernel-2.6
- make sure /sys is mounted
- install the new initscripts
- install the new udev
- execute /sbin/start_udev
- install the new mkinitrd
- install a new kernel 
- or mkinitrd for your existing kernel(s)

I was comparing the start_udev scripts from fedora's udev-032-2
package with Greg KH's kernel.org/utils* udev-032 release tarball. 

There's enough differences, many involving file
existance/stateof/attribute checks in the fedora version of udev to
cause it, in some cases, not to execute, although if you've shifted
your ways over to udev, then it just needs to execute in order to boot
up, having a working /dev/tty[0-9], etc.

The other group of start_udev differences are fedora's heavy
interrelated selinux checks. 

I've been keeping up to date with the fedora dev/rawhide tree for a
long time, and I agree that due to a lack of decent documentation in
fedora's package, that its tremendously easy to come up with a
non-bootable system just by installing and/or updating udev. The
problems will come in when udev doesn't run or create a full set of
devices due to the a) start_udev differences, b) /etc/udev/udev.conf
being overwritten, /etc/udev/rules.d/50*.rules being overwritten, and
/etc/udev/permissions.d/* being overwritten. 

By making a couple of changes to fedora's udev (if you have trouble
booting), these things might not need doing (and I realize its only in
some configurations that are likely incorrect):
1) overwriting it's start_udev with the original kernel.org one
2) not letting 'yum update udev' overwrite udev.conf, rules.d/* or
permissions.d/* unless it's as some option or intelligent merge,
3) mostly, as this bug is all about, having good documentation about
the things that're different about fedora's implementation vs. the
vanilla udev. 

After my last yum update udev, I had an unbootable system that
required 2 changes to bring back to life. The first was (after booting
into linux rescue and chroot) to copy my backup copy of
rules.d/50*.rules over the one written by the fedora package, and the
2nd try on booting required that I overwrite the start_udev script in
/sbin with the standard kernel.org one. 

Pretty easy, but reading the fedora udev docs that wind up in
/usr/share/** somewhere (forgot at the moment), they're clearly at
least a year old and have little useful information about changing
things to work with fedora. One of them even talks about you
installing a 'udev' script in /etc/init.d and adding it as a service
in tandem with reordering statements in rc.sysinit, but those are just
examples of what gets the fedora list periodically full of people
unable to boot their systems after unknowingly installing udev (or so
it seems).

Ok, I'm rambling on, when my only real point was the amount of trouble
people can get in when changing to udev fedora style. I think that
even if udev is selected to be installed, that the steps you guys have
come up with (or will) for doing a clean changeover should somehow be
forced into the installer's face and forced to be acknowledged before
they wind up discouraged and booting some other os, linux rescue, or
giving up and reinstalling (way too many horror stories on the fedora
lists)

Mick

How does this look:

$RELEASE has switched from a static /dev/ directory to one that is
dynamically managed via udev. This allows device nodes to be
created on demand as drivers are loaded.

For more information on udev, see the udev(8) manpage.

Additional rules for udev should be placed in a separate file in
/etc/udev/rules.d/.

Additional permission rules for udev should be placed in a separate
file in /etc/udev/permissions.d/.

Although *not* recommended, it is possible to performa "live" upgrade
to udev using the following steps:

1. Ensure that you are running a 2.6 kernel.

2. Ensure that /sys/ is mounted

3. Install the initscripts RPM supplied with $RELEASE

3. Install the new udev RPM supplied with $RELEASE

4. Execute /sbin/start_udev

5. Install the new mkinitrd RPM supplied with $RELEASE

6a. Install the new kernel RPM supplied with $RELEASE

OR:

6b. Re-run mkinitrd for your existing kernel(s)

WARNING: Improperly performing these steps can result in a system
configuration that will not boot properly.

Sounds good to me.

Bill -- thanks!  It's in there; closing...

you may also look here:
http://people.redhat.com/~harald/udev.html

Harald -- that's a great document!  Have you ever thought about
leaving all this software junk and working for Docs? :-)

I'd like to include a pointer to this document in the release notes;
would you be ok with that?  I just wanted to ask, in case you were
planning on taking the page down or moving it...

in fact I wanted to upload it to fedora.redhat.com, then the cvs
server did not allow me to. I was too lazy to contact any
"authoritive" person, which wasn't awake or online anyway, so I used
php to generate a static page and uploaded it on people.

Well, it's good information, and I'll link to it wherever it lives.
:-)  Thanks for writing that and letting me know about it!  Closing...