On Wed, 18.08.10 18:45, Dave Jones (da...@redhat.com) wrote: > > On Thu, Aug 19, 2010 at 12:32:01AM +0200, Lennart Poettering wrote: > > On Wed, 18.08.10 18:15, Dave Jones (da...@redhat.com) wrote: > > > > > > # systemctl enable ge...@.service prefdm.service getty.target > rc-local.service remote-fs.target > > > > > > > > And that should make things work again. > > > > > > even after doing this, I still haven't managed to get a single box > running systemd. > > > They all hang after complaining that it failed to load configuration for > default.target > > > (and a bunch of other services like distcache, livesys-late, cman) > > > > Have you seen the two follow-up messages I posted to this one? You need > > to create the default.target link as well. See those two mails for details. > > ah, missed that in the noise. thanks. > > > > It tells me to see the logs for details, but there's not a single message > > > from systemd in the logs. > > > > There should be an explanation in dmesg, that it cannot find > default.target. > > at the stage that it stopped, I guess syslog wasn't running, so it never made > it into the boot logs.
Hmm, could be. Note that we log to kmsg as long as syslog isn't up, so nothing should get lost -- as long as you manage to get a shell somehow. BTW, as a side note: a simply fix to bypass the problem with a missing default.target is to pass "5" on the kernel command line. This will then boot into gdm regardless whether default.target exists or not. the git version of systemd will automatically enter signle user mode if default.target is missing or borked. > > When systemd initializes we will initialize autofs too (by opening > > /dev/autofs), and that will fail if the module is not loaded (and the > > usual module-autoloading won't work for the autofs device node since > > udev isn't around yet, and the device node is hence not created yet). > > this seems like a rube goldberg machine to me, but ok. Well, we have autofs support anyway, and using it is very simple in systemd, and given that these API mounts are optional and backed by seldomly used kernel modules this seemed like a sensible thing to do these things. This way all those ugly scripts which manually modprobe and mount the respective modules can go away, everything is available in the file system namespace right-away and even the privileges problem is gone. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
