Note: just enable devtmpfs. Don't enable the keep-mounted or whatever option just under that.

That does work fine, since udev-mount (which is needed by udev in sysinit) mounts /dev from devtmpfs if it can; but it'll also work fine with CONFIG_DEVTMPFS_MOUNT (you just get an ok message saying /dev is already mounted.)

Having it enabled just makes things easier when you have a problem booting and start a rescue shell/ single-user mode, especially if you have lvm partitions, since they will now be accessible under their kernel names. (And if you have them listed under those in /etc/fstab then they can easily be mounted with mount -a.)

=======
Summary:
=======
If you have /usr and/or /var on a separate partition (including lvm) and you don't currently have an initramfs, then your options are:
1) The supported route: Setup an initramfs.
2) Use a couple of patches to openrc initscripts to make udev start after localmount.
3) Use sys-apps/eudev

Potentially the list of required partitions could include /opt if third-party drivers or support scripts are installed there (or directories are read or written to by the same.)

I have /usr on its own partition. I have been so busy that I have been dealing with this udev issue by simply not rebooting my system - LOL! I finally got around to setting up initramfs to mount /usr early. To do this I chose to follow The Gentoo Wiki - Early_Userspace_Mounting. When I rebooted I was presented with an error that was similar to:

Code:

803 on /mnt/root failed

It also complained that the file or directory did not exist. Eek! Well, this error dropped me to the rescue shell thank goodness. So I mounted root manually and also mounted /usr and /boot. This gave me:

Code:

/mnt/root
/mnt/root/usr
/mnt/root/boot

I then chroot /mnt/root (Note that the chroot is necessary for the repackaging of the image to work) and edited the /usr/src/initramfs/init provided in the wiki mentioned above. There is a function in that script called uuidlabel_root. I commented out everything in that function and replaced it with an explicit mount to my root. This happens to be:

Code:

mount -o ro /dev/sda5 /mnt/root

I don't really understand why the fancy method which detects the correct device node for root was failing, but an explicit mount for my particular system got me up and running. After making that change I followed the instructions to re-package the image on boot and then rebooted my system. I am happy once again.

This is really just an FYI to anyone following that wiki.

By the way, how will we be informed when udev is fixed. I will want to get rid of this initramfs hack once it is no longer required.

I have /usr on its own partition. I have been so busy that I have been dealing with this udev issue by simply not rebooting my system - LOL! I finally got around to setting up initramfs to mount /usr early. To do this I chose to follow The Gentoo Wiki - Early_Userspace_Mounting. When I rebooted I was presented with an error that was similar to:

Code:

803 on /mnt/root failed

It also complained that the file or directory did not exist. Eek! Well, this error dropped me to the rescue shell thank goodness. So I mounted root manually and also mounted /usr and /boot. This gave me:

Code:

/mnt/root
/mnt/root/usr
/mnt/root/boot

I then chroot /mnt/root (Note that the chroot is necessary for the repackaging of the image to work) and edited the /usr/src/initramfs/init provided in the wiki mentioned above. There is a function in that script called uuidlabel_root. I commented out everything in that function and replaced it with an explicit mount to my root. This happens to be:

Code:

mount -o ro /dev/sda5 /mnt/root

I don't really understand why the fancy method which detects the correct device node for root was failing, but an explicit mount for my particular system got me up and running. After making that change I followed the instructions to re-package the image on boot and then rebooted my system. I am happy once again.

This is really just an FYI to anyone following that wiki.

By the way, how will we be informed when udev is fixed. I will want to get rid of this initramfs hack once it is no longer required.

Sincerely,

dustfinger.

using latest stable udev-197, /usr on separate partition, no initramfs and system boots._________________Only two things are infinite, the universe and human stupidity and I'm not sure about the former - Albert Einstein
ProjectFootball

According to DaggyStyle the latest stable version of udev is no longer affected by this issue. You no longer need to mount the /usr partition early using initramfs. I have not tried to remove my initramfs yet, nor have I looked at the bug reports to see exactly when the fix was made for udev. I am just so darn busy all of the time

Well... My english is not very good but i'll try to explain.
I haven't /usr separate, but i have an openvz kernel. And openvz kernel doesn't have DEVTMPSFS option.
So, I can't update udev.
For the moment, this works, but how long ?
What will I have to do when udev update will be required to maintain all my system ?
Have I to forget openvz ?
This situation is not good at all.

Well... My english is not very good but i'll try to explain.
I haven't /usr separate, but i have an openvz kernel. And openvz kernel doesn't have DEVTMPSFS option.
So, I can't update udev.
For the moment, this works, but how long ?
What will I have to do when udev update will be required to maintain all my system ?
Have I to forget openvz ?
This situation is not good at all.

I don't understand all what you mean, my english is really too bad, but, I'm certain openvz doesn't contain devtmpfs, and a lot of users are not happy with that.
You should look openvz kernel sources better :

I don't understand all what you mean, my english is really too bad, but, I'm certain openvz doesn't contain devtmpfs, and a lot of users are not happy with that.
You should look openvz kernel sources better :

The "!VE" makes all the difference. You CAN'T activate it with openvz, because devels consider OpenVZ can't work with DEVTMPFS.

OK, I stand corrected. I'm afraid your only option is to copy old sys-fs/udev to local overlay then, along with sys-apps/module-init-tools.
The OpenVZ developers need to fork udev if they don't plan in supporting DEVTMPFS. Crazy as it sounds.