Description of problem: 'Couldn't find an alternative telinit implementation to spawn.' when doing e.g. `init 3`. Version-Release number of selected component (if applicable): systemd-26-2.fc15.x86_64 How reproducible: Upgrade from f14 to F15 Steps to Reproduce: 1. run single user 2. type init 3 3. see output Actual results: Couldn't find an alternative telinit implementation to spawn. Expected results: runlevel 3 Additional info: https://bugzilla.redhat.com/show_bug.cgi?id=701461 The notion that one report can only have one cause is very simplistic, very outdated and does not speak of customer friendliness. Whatever action yields the same erroneous results should be regarded as a thing to fix if the actions were reasonable.
Oh, yes, selinux is very much disabled.
Also we get emails: & 36 Message 36: From root@xxxxxx Sun Jun 12 03:23:08 2011 Return-Path: <root@xxxxxx> Date: Sun, 12 Jun 2011 03:23:07 +0200 From: Anacron <root@xxxxxxx> To: root@xxxxxxxx Content-Type: text/plain; charset="ANSI_X3.4-1968" Subject: Anacron job 'cron.daily' on xxxxxx Status: R /etc/cron.daily/prelink: Couldn't find an alternative telinit implementation to spawn.
# telinit q Couldn't find an alternative telinit implementation to spawn.
# which telinit /sbin/telinit # rpm -qf /sbin/telinit systemd-26-2.fc15.i686
(In reply to comment #0) > https://bugzilla.redhat.com/show_bug.cgi?id=701461 > The notion that one report can only have one cause is very simplistic, very > outdated and does not speak of customer friendliness. > Whatever action yields the same erroneous results should be regarded as a thing > to fix if the actions were reasonable. You are NOT a customer and Bugzilla is NOT a customer support portal. Bugzilla is a bug-tracking system and therefore it makes perfect sense to track different bugs under separate Bugzilla numbers. It makes work easier for the maintainers this way. Conflating several issues together would help nobody. Now let me repeat a part of my comment https://bugzilla.redhat.com/show_bug.cgi?id=701461#c9 : ... and report the output of: stat /sys/fs/cgroup /sys/fs/cgroup/systemd
[root@epia ~]# stat /sys/fs/cgroup /sys/fs/cgroup/systemd stat: cannot stat `/sys/fs/cgroup': No such file or directory stat: cannot stat `/sys/fs/cgroup/systemd': No such file or directory [root@epia ~]# cd /usr/src/linux [root@epia linux]# grep CGROUP .config CONFIG_CGROUPS=y # CONFIG_CGROUP_DEBUG is not set CONFIG_CGROUP_NS=y CONFIG_CGROUP_FREEZER=y CONFIG_CGROUP_DEVICE=y CONFIG_CGROUP_CPUACCT=y CONFIG_CGROUP_MEM_RES_CTLR=y CONFIG_CGROUP_MEM_RES_CTLR_SWAP=y CONFIG_CGROUP_MEM_RES_CTLR_SWAP_ENABLED=y # CONFIG_CGROUP_PERF is not set CONFIG_CGROUP_SCHED=y CONFIG_BLK_CGROUP=m # CONFIG_DEBUG_BLK_CGROUP is not set # CONFIG_NET_CLS_CGROUP is not set
For some reason the cgroups did not get mounted. The config options look OK to me. Let's see the log. Boot with "log_buf_len=1M systemd.log_level=debug systemd.log_target=kmsg" and attach the output of 'dmesg'.
Actually, forget the info request. > stat: cannot stat `/sys/fs/cgroup': No such file or directory This means not only that the filesystem is not mounted, but that the mountpoint does not even exist. Either you are running a kernel older than 2.6.36 (that's when the mountpoint was added), or you do not have in fact CONFIG_CGROUPS enabled in the running kernel (contrary to comment #6, so that would imply a mistake on your side). Whichever of the possibilities it is, you must have broken it yourself, so you get to keep both pieces. We can reopen if the problem persists with a Fedora kernel.