[HEADS-UP] adding missing systemd links in rawhide upgrades

[Dave Jones]

On Thu, Aug 19, 2010 at 12:32:01AM +0200, Lennart Poettering wrote:
 > On Wed, 18.08.10 18:15, Dave Jones (davej at redhat.com) wrote:
 > 
 > >  >     # systemctl enable getty at .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