Hide Forgot
Please add a descriptive phrase to the summary, and more in-depth description here (be sure to note any arch-specific issues): (ccing others for feedback.) $RELEASE has switched from a static /dev directory to a dynamic /dev using udev for device management. This allows device nodes to be created on demand as drivers are loaded. For more information on udev, see <???>. ... Do we want to add bits on how to do a live upgrade without screwing yourself?
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...