On Tue, 2 Feb 2010 08:08:25 +0200 Alan McKinnon wrote: > On Tuesday 02 February 2010 06:03:10 David Relson wrote: > > G'day, > > > > I've been running baselayout-2 for several months and it's been > > working fine AFAICT. Over the weekend I noticed that my USB thumb > > drive is no longer automounting. > > > > This evening I ran "/etc/init.d/udev status" which reported: > > > > * status: stopped". > > > > Running "/etc/init.d/udev start" reported: > > > > * The udev init-script is written for baselayout-2! > > * Please do not use it with baselayout-1!. > > * ERROR: udev failed to start > > > > The message occurs because /etc/init.d/udev checks for > > /etc/init.d/sysfs, which is not present. > > > > Googling indicates that /etc/init.d/sysf comes from > > sys-apps/openrc. I have openrc-0.3.0-r1 installed (from long > > ago). openrc-0.6.0-r1 is available, though keyworded ~amd64. > > Unmasking it and running "emerge -p ..." shows that sysvinit is a > > blocker. > > > > Is it safe to delete sysvinit and emerge openrc-0.6.0-r1? Am I > > likely to get myself into troubleif I do this? If so, how much and > > how deep? > > very very very very deep trouble if you restart the machine and > everything is not complete yet. Do not do that. > > all version of baselayout-2 are marked unstable and you likely have > an old version of sysvinit that is not compatible with the ancient > openrc you do have. That openrc is not in portage anymore. > > You should upgrade to the latest unstable portage (which supports > automatically resolving blockers). You need baselayout, openrc and > sysvinit as well as /etc/init.d/sysfs. I have none of these in world > yet all are present. > > With the latest portage, try again and let portage figure out for > itself what it wants to do.
Hi Alan, Reply appreciated! I've been running unstable versions of portage for many months and currently have 2.1.7.17, which _is_ the newest non-masked version. With it, sysvinit is blocking (capital "B") openrc-0.6.0-r1 and /etc/init.d/sysfs is not present (which makes /etc/init.d/udev unhappy). Since /etc/init.d/udev only _checks_ for the presence of /etc/init.d/sysfs but doesn't run it (or anything), would creating a dummy (zero length) sysfs file be workable? Regards, David
