Bug 618315

Same here.

/etc/systemd/system/default.target simply does not exist. Not sure which package or script is supposed to create it.

Booting with "systemd.unit=multi-user.target" got me further: all the usual services started, but then the progress stopped before the mingettys started, so I could not login. I booted with upstart to investigate and found that /etc/systemd/system/multi-user.target.wants/ contained suspiciously few files (only one: avahi-daemon.service). So I did manually:

systemctl enable getty.service
systemctl enable getty@.service

After next boot, I got the mingettys running.

Conclusion: systemd is misconfigured out of box.

> systemctl enable getty.service

Correction, s/service/target/

I see systemd-units-4-3.fc14.x86_64 contains a post-install scriptlet which would enable the missing services. But it's only run on install of the package, not on upgrade. I did have an older systemd installed before, so it did not run in my case.

To fix it I did:
rpm -e --nodeps systemd-units
yum install systemd-units

This created the correct symlinks automatically and on the next boot I did not have to provides any special parameters.

It means this issue will only affect the early testers of systemd, not common users.

I did not have systemd installed previously and systemd-4-4.fc14.i686 came in with tonights updates.  My boot also ended with a failure to load default.service and subsequently a failure to start default.service resulting in a lock up of the boot process.  I used init=/sbin/upstart to get boot to complete.  I will try the fix in Comment 3 and see if it helps.

Fix in comment #3 worked to complete boot, which brought on a host of other problems.  One core of my AMD Phenom II X4 955 was at 99%, which I checked by restarting a couple of times.  Shutdown/Restart froze shutdown, had to power down to restart.  End of messages file attached.

Created attachment 435184 [details]
End of message file / systemd

Same problem as Comment 5 for me. In my case Xorg is taking 100% CPU on one core.

(also had to use Comment 3 to get a working systemd-units. I had an old version from rawhide that also didn't make the symlinks)

Hmm, I really wonder if we should fix this, given that this breaks when upgrading from rawhide only. I figure it will be ok, just announcing this as a heads-up on fedora-devel.

GoinEasy9,
could you attach the output of "yum history info systemd-units"?

Created attachment 435327 [details]
yum history info systemd-unit

Another example of systemd-units history. I had the same problem with links not being created.

darrell,
your yum history shows that you updated to systemd-units-4-3 from an older version (in transaction ID 1301). This case is already known to cause the trouble. Please use the workaround described in comment #3.

I've never tested systemd, but when I updated today, systemd-units was updated rather than installed.  Does this mean that all users who updated from F13 to rawhide will need to follow the steps in Post #3 to force systemd-units to create the necessary symlinks?

Gene

(In reply to comment #12)
> I've never tested systemd, but when I updated today, systemd-units was updated
> rather than installed.

May I see your "yum history info systemd-units" too?

> Does this mean that all users who updated from F13 to
> rawhide will need to follow the steps in Post #3 to force systemd-units to
> create the necessary symlinks?

It seems the early version of systemd-units was pulled in for Rawhide users by dependency from avahi. That's unfortunate - the most of Rawhide users must be affected by the issue, not just those who tested systemd intentionally.
But those who upgrade from F-13 to Rawhide today will have the symlinks created automatically by the scriptlet.

I won't be home till 10PM EST to run the command on my rawhide box, but, if your trying to find out if I had an earlier version of systemd-init, I did.

Created attachment 435353 [details]
Output of "yum history info systemd-units

Created attachment 435354 [details]
/var/log/boot.log with wireless lan startup failure

Michael,

I attached the file you requested.  From a quick look, systemd-units was dep-installed when avahi was updated for me, as well.  Also, I attached my first boot.log with systemd.  My wireless is configured to start at boot, and it failed with systemd.  Should I create a new bug for this issue?

Thanks,
Gene

(In reply to comment #17)
> I attached the file you requested.  From a quick look, systemd-units was
> dep-installed when avahi was updated for me, as well.

Yes, that's right. Thanks for confirming.

> My wireless is configured to start at boot, and
> it failed with systemd.  Should I create a new bug for this issue?

Yes please.

Created attachment 435448 [details]
spec patch

Honestly, I think the attached is simple and safe - always create default.target if it doesn't exist. Should fix any weirdness on upgrades automatically, and not have side effects.

Long term, I think we should change where some of these are packaged... the units that start rc.local, rc.sysinit might as well just live with those scripts in initscripts, and so on.

I don't now if you still need my output from yum history info systemd-units, but is the attachment anyway.

Created attachment 435454 [details]
yum history info systemd-units

This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle.
Changing version to '14'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment on attachment 435448 [details]
spec patch

Bill,

>@@ -118,7 +118,9 @@ if [ $1 -eq 1 ] ; then
> 
>         # And symlink what we found to the new-style default.target
>         /bin/ln -sf "$target" /etc/systemd/system/default.target 2>&1 || :
>+fi
> 
>+if [ $1 -eq 1 ] ; then
>         # Enable the services we install by default.
>         /bin/systemctl enable \
>                 getty@.service \

I'd drop this hunk of the patch. Not having gettys and prefdm running is almost as bad as not having default.target.

The admin may want to change the number of gettys, etc., but we can come up with another way to do that in packaging better.

(In reply to comment #24)
> The admin may want to change the number of gettys, etc.

Sure, but then default.target will be already there, so the scriptlet will not run.

*** Bug 619903 has been marked as a duplicate of this bug. ***

*** Bug 620176 has been marked as a duplicate of this bug. ***

So, yepp, this is borked for upgrades from old to new rawhide. Sorry for this. I have now posted a heads-up explaining what to do on fedora-devel:

http://lists.fedoraproject.org/pipermail/devel/2010-August/140294.html

Given that this issue is limited to rawhide installs I hope this should be enough.

*** Bug 620462 has been marked as a duplicate of this bug. ***

Reproduced it after a fresh virt-install of F14-Alpha-RC2

systemd-5-2.fc14.i686
udev-160-8.fc14.i686

Created attachment 437519 [details]
Error Output

Propose it as Alpha blocker due to:

13. In most cases, the installed system must boot to a functional graphical environment without user intervention (see Blocker_Bug_FAQ) 
(https://fedoraproject.org/wiki/Fedora_14_Alpha_Release_Criteria)

(In reply to comment #30)
> Reproduced it after a fresh virt-install of F14-Alpha-RC2
> 
> systemd-5-2.fc14.i686

You're seeing bug 621200 (it's already set as Alpha blocker). systemd-5-2 has a known problem which would cause default.target (and other links) not to be created in the postinstall scriptlets when SELinux is enabled.

Just for my understanding: what are the reasons to create the default.target symlink only on package installation ("if [ $1 -eq 1 ]") rather than if it's missing (for whatever reason)? AIUI, systemd without default.target isn't useful -- what am I missing?

*** Bug 622634 has been marked as a duplicate of this bug. ***

After being forced to hard power off F14 about 2 days ago, apparently due to a bad systemd update, whenever I boot now, I'm dropped into rescue mode and it says to run "systemctl default" to activate default mode. But doing this gives the error message

Failed to issue method call: Unit default.target failed to load: No such file or directory. You might find more information in the logs.

I can run "telinit 5" to get into the GUI but I have to do this every time. This is a clean install of F14 from the F14 Alpha x86_64 DVD ISO.

Is this an existing systemd bug (I don't know anything about systemd so don't have a clue), or a one-time side effect of the earlier bad update?

Fixed it with the command

ln -sf /lib/systemd/system/graphical.target /etc/systemd/system/default.target

from

http://lists.fedoraproject.org/pipermail/devel/2010-August/141898.html