Re: [HEADS-UP] adding missing systemd links in rawhide upgrades
On Thu, Aug 19, 2010 at 01:40:10AM +0200, Lennart Poettering wrote: On Wed, 18.08.10 19:35, Dave Jones (da...@redhat.com) wrote: On Wed, Aug 18, 2010 at 07:00:16PM -0400, Dave Jones wrote: On Thu, Aug 19, 2010 at 12:53:44AM +0200, Lennart Poettering wrote: 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. So I got it booting after creating the default.target symlink, but the network no longer comes up automatically (nor services dependant upon it, like sshd). Did I miss another mail ? related to this I guess ? [ 44.659412] init[1]: Failed to load configuration for NetworkManager-by-dbus.service: No such file or directory [ 44.659596] init[1]: D-Bus activation failed for NetworkManager-by-dbus.service: Invalid argument Yupp, If any of the problems being discussed are common to people who will install F14 Alpha, can I ask you guys to put some information on the Common F14 bugs page please? https://fedoraproject.org/wiki/Common_F14_bugs Thanks. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ Where open source multiplies: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] adding missing systemd links in rawhide upgrades
On Thu, 19.08.10 10:02, Paul W. Frields (sticks...@gmail.com) wrote: So I got it booting after creating the default.target symlink, but the network no longer comes up automatically (nor services dependant upon it, like sshd). Did I miss another mail ? related to this I guess ? [ 44.659412] init[1]: Failed to load configuration for NetworkManager-by-dbus.service: No such file or directory [ 44.659596] init[1]: D-Bus activation failed for NetworkManager-by-dbus.service: Invalid argument Yupp, If any of the problems being discussed are common to people who will install F14 Alpha, can I ask you guys to put some information on the Common F14 bugs page please? https://fedoraproject.org/wiki/Common_F14_bugs To my understanding these bugs are visible only if you upgrade from odler to newer rawhide/f14, resp. when installing an NM version that entered f14 post alpha. People installing a fresh f14 image should not see these issues. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] adding missing systemd links in rawhide upgrades
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. 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. as an aside: it also prints out some bogus messages about autofs and ipv6 being missing. if you could remove those, that would likely save some pointless bug reports. Well, systemd by default uses autofs for certain API vfs mounts, such as binfmt_misc: we create the mount point and only when it is accessed we actually mount the file system on it. This has the effect that we'll load the binfmt kernel module only when somebody actaully writes something to the fs. i.e. we make the mount points availabale all the time in the file system, but the backing module is not necessarily loaded. Something similar applies to a couple of other non-essential virtual API file systems. 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). systemd also configures the lo network device by default as part of early bootup, as part of its normal startup code (in C). here too module autoloading doesn't work, since configuring an ipv6 address on lo will not cause the protocol module to be loaded. So, in summary, we have to modprobe autofs and ipv6 manually before we go on with the startup, and given that this is how it is I don't think it makes much sense compiling them as a module anymore. It's similarly pointless as compiling unix.ko as a module, or the RTC module. It just slows down the boot and will be loaded into the kernel anyway. And that's why we complain. (note that systemd will still boot if autofs and ipv6 aren't available at all, it's not essential and we actually do honour the modprobe blacklist) Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] adding missing systemd links in rawhide upgrades
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. as an aside: it also prints out some bogus messages about autofs and ipv6 being missing. if you could remove those, that would likely save some pointless bug reports. Well, systemd by default uses autofs for certain API vfs mounts, such as binfmt_misc: we create the mount point and only when it is accessed we actually mount the file system on it. This has the effect that we'll load the binfmt kernel module only when somebody actaully writes something to the fs. i.e. we make the mount points availabale all the time in the file system, but the backing module is not necessarily loaded. Something similar applies to a couple of other non-essential virtual API file systems. 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. systemd also configures the lo network device by default as part of early bootup, as part of its normal startup code (in C). here too module autoloading doesn't work, since configuring an ipv6 address on lo will not cause the protocol module to be loaded. So, in summary, we have to modprobe autofs and ipv6 manually before we go on with the startup, and given that this is how it is I don't think it makes much sense compiling them as a module anymore. It's similarly pointless as compiling unix.ko as a module, or the RTC module. It just slows down the boot and will be loaded into the kernel anyway. And that's why we complain. (note that systemd will still boot if autofs and ipv6 aren't available at all, it's not essential and we actually do honour the modprobe blacklist) we had to revert the ipv6=y change for rhel6 because someone showed that it's actually costly in high performance networking cases where ipv6 isn't even used. rhel7 may be a long ways away, but eventually, systemd will have to be made to handle that case, so it may as well get it right from the start. There will always be use cases for disabling ipv6, so building it in seems ill advised. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] adding missing systemd links in rawhide upgrades
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
Re: [HEADS-UP] adding missing systemd links in rawhide upgrades
On Thu, Aug 19, 2010 at 12:53:44AM +0200, Lennart Poettering wrote: 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. So I got it booting after creating the default.target symlink, but the network no longer comes up automatically (nor services dependant upon it, like sshd). Did I miss another mail ? Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] adding missing systemd links in rawhide upgrades
On Wed, 18.08.10 19:00, Dave Jones (da...@redhat.com) wrote: 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. So I got it booting after creating the default.target symlink, but the network no longer comes up automatically (nor services dependant upon it, like sshd). Did I miss another mail ? The NM packages didn't properly enable its service. dcbw has already fixed this now, but it isn't in f14 yet. You should be able to work around this by invoking systemctl enable NetworkManager.service and systemctl start NetworkManager.service. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] adding missing systemd links in rawhide upgrades
On Wed, 18.08.10 19:35, Dave Jones (da...@redhat.com) wrote: On Wed, Aug 18, 2010 at 07:00:16PM -0400, Dave Jones wrote: On Thu, Aug 19, 2010 at 12:53:44AM +0200, Lennart Poettering wrote: 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. So I got it booting after creating the default.target symlink, but the network no longer comes up automatically (nor services dependant upon it, like sshd). Did I miss another mail ? related to this I guess ? [ 44.659412] init[1]: Failed to load configuration for NetworkManager-by-dbus.service: No such file or directory [ 44.659596] init[1]: D-Bus activation failed for NetworkManager-by-dbus.service: Invalid argument Yupp, Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] adding missing systemd links in rawhide upgrades
On 04/08/10 00:10, Lennart Poettering wrote: Heya, just a little heads up for when you upgrade a rawhide system that is a few weeks old to current rawhide: since we changed the way how some of the default symlinks of systemd are created you will end up with an installation that lacks many of the necessary symlinks -- but only if you upgrade from a systemd version from older rawhide to current rawhide. It's really only a problem in this case. It is not a problem with fresh F14 installations, and it is not a problem with upgrades from F13. The fix is easy: after upgrading just run this command as root and the missing links should be created: # systemctl enable ge...@.service prefdm.service getty.target rc-local.service remote-fs.target And that should make things work again. Sorry for the late heads-up. Lennart Ah, thanks. You've saved my day. Matthias -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
