The current udev (udev-141) and openrc(-0.4.3) are filled with problems and should be completely pulled from distribution. To start with udev attempts to install itself on a read-only root filesystem generating hundreds of udev-event errors. I had to all back to udev-124-r1 to avoid this problem. Then there are a host of file system configuration problems associated with the read-only file system. (1) There is no /dev/agpgart so it is impossible to start X windows. The startup of ALSA claims there is no /dev/snd directory. Hald fails to start. When one attempts to enter state 5 (e.g. telinit 5 to attempt to start xdm for a windows based system), the console enters a very strange mode where it does not echo characters and requires a stty sane followed by a return to execute each subsequent step of a state 5 state. The way Gentoo is configured on my system state 3 is a multi-login console state while state 5 is a windows state (xdm, speechd, festivald, etc.). But switching to state 5 should *not* cause the TTY modes on the consoles to change to non-echo. Most importantly I can boot Ubuntu 2.6.28.4 on a Ubuntu root disk in Windows mode on this hardware (and mount and use my user disks) while I can no longer boot and run Gentoo in "Windows" mode (and I have had to fall back on udev to even get a "shell" Gentoo which functions. IMO, the person(s) responsible for approving udev/openrc upgrades have a lot to answer for. This bug report is being filed using Ubuntu because Gentoo is so dysfunctional. Mind you, over the last several years I've had generally good results with Gentoo, but the udev/openrc problems because they can generally make the system unusable have led me to question where I should place my faith.
What do you mean with "udev attempts to install itself on a read-only root filesystem"? First of all, udev mounts its own tmpfs filesystem into /dev so this is read/write by default unless you override this through /etc/fstab. For example this is my /dev mount from udev-141: udev on /dev type tmpfs (rw,nosuid,size=10240k,mode=755) Your description of the problems you're encountering are quite confusing. How about giving us a thorough description on how you did the update from udev-124-r1 to udev-141 (or rather what you missed to do)? Considering that you updated sys-fs/udev from version 124-r1 to -141, did you rc-update add udev sysinit as the ebuild told you? If not, many of your reported problems are caused by your own fault to read the messages which were shown through portage from the corresponding packages. The same applies to openrc which shows you a message like this: You should now update all files in /etc, using etc-update or equivalent before restarting any services or this host. Please read the migration guide available at: http://www.gentoo.org/doc/en/openrc-migration.xml The transition from baselayout-1 to baselayout-2/openrc is not 100% error prone and the update documentation still needs polishing but that's the reason why _both_ udev-141 and openrc are currently _not_ marked stable. If you fail to handle such rather complicated updates you'd better stick with stable (means baselayout-1, no openrc and udev-124-r1) until the upgrade path is smooth enough for all affected packages to become stable. Marking ths as RESOLVED NEEDINFO. Reopen the bug when you provide more detailed information on what is going wrong on your system and how you were setting it up so that it turned into this broken state.
The OpenRC and udev versions you have listed are marked as unstable on all arches because they are still in development and testing. If you are not prepared to help test or fix them, or if you intend to operate a production system, you should not be running them.
I understand that the boot process is supposed to create & mount some temporarary file systems. On the Ubuntu that I am now running I've got a tmpfs mounted as /lib/init/rw, a udev mounted as /dev and an additiional tmpfs mounted as /dev/shm. And if udev-141 / openrc-0.4.3 did that then most of my problems would probably go away. But they don't. Thus far it has proved impossible to fall back from openrc to sysvinit! Bad, bad, bad. The errors include: a) Unable to login as root on the console, due to "Unable to determine your tty name" (which one can work around by booting in "single" mode); and b) INIT: cannot execute /sbin/rc (3 times) -- initially /sbin/rc did not exist but the error persists when /sbin/rc and /sbin/init were copied from an old functional Gentoo root disk onto the active root disk. This was *after* openrc was uninstalled and sysvinit was reinstalled. /sbin/rc exists and has the execute bits set. With regard to booting the current udev/openrc -- the problem appears to be that there is *no* rw tmpfs for /dev that udev can install itself onto -- there needs to be significantly greater checks before attempting to install a pseudo-/dev (udev) FS (before root is remounted rw) that /dev or its functional replacement is indeed rw! -- because now all one gets is hundreds of "udev-event" error messages complaining about a "Read-only file system", e.g. /dev. And I would suggest that Gentoo may need an attitude adjustment (or I may need to switch to Ubuntu). It is not an uncommon situation for users to unmask packages in package.keywords as needed in an attempt to keep up-to-date with the current packages. But changing the Baselayout/Init/OpenRC to enable Gentoo FreeBSD (which many people may have no interest in) without requiring that people read the installation guide is unconscionable. YOU SHOULD NEVER CREATE A SITUATION WHERE "NORMAL" BEHAVIOR (enabling package upgrades) CREATES A NON-FUNCTIONAL SYSTEM. So for changes to packages like udev, openrc, sysvinit, etc. people should be REQUIRED to read the installation notes and be prepared to deal with crap that results from attempting to be on the cutting edge. There is a big difference from installing a cutting edge firefox which breaks my running firefox -- but I can still run epiphany -- and installing cutting edge software which breaks my ability to boot a functional windows (gnome) system. Your "marked as unstable" defense doen't cut it. Ubuntu is able to release beta software which doesn't have the problems which I've encountered with Gentoo over the last 5 months (almost entirely associated with the openrc upgrades).
sys-apps/openrc is _NO_ replacement for sys-apps/sysvinit. You also didn't answer any of my questions so I guess you did not even understand them... Please do yourself a favour and stick with stable Gentoo or completely switch to Ubuntu if you really feel so fine with it. You really seem to have no clue about the system as a whole as you already proved with your two posts in this bug.
I believe the problems started when I installed udev-141. By reinstalling sysvinit (-2.86-r12), backing down to udev-135 & openrc-0.4.3-r1 and copying over a number of files into /sbin (e.g. functions.sh, runscript.sh, etc. and some old files in /etc/init.d) I now have a system that will boot and run gnome. I am not sure how udev is *supposed* to work. But the way it is working on my system now the init startup sequence appears to be sysfs; dmesg; udev and udev appears to start /sbin/udevd and then a number of uevents are run to "populate" /dev. The first 4 mounts on my system are /dev/sda8 as /; proc as /proc; sysfs as /sys and udev as /dev. The problem when things were not working appeared to be that udevd wasn't getting started (allowing the creation of a read/write /dev?). All of the subsequent uevents therefore attempt to create devices on the readonly /dev on the root file system. I'm still getting some errors on booting (missing commands: config, get_options, save_options & keyword) and some errors involving device-mapper with scripts like lvm, hald, etc. involving the fact that I've got scripts designed for baselayout-2 and it seems to think I'm running on baselayout-1 (even though portage claims that I've got baselayout-2 installed).
