Bug 618315 - default.target missing.
Summary: default.target missing.
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 14
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Lennart Poettering
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 619903 620176 620462 622634 (view as bug list)
Depends On:
Blocks: F14Alpha, F14AlphaBlocker
TreeView+ depends on / blocked
 
Reported: 2010-07-26 16:23 UTC by Jóhann B. Guðmundsson
Modified: 2010-08-27 01:54 UTC (History)
26 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-08-09 07:28:02 UTC


Attachments (Terms of Use)
End of message file / systemd (4.33 KB, text/plain)
2010-07-29 03:43 UTC, GoinEasy9
no flags Details
yum history info systemd-unit (9.82 KB, text/plain)
2010-07-29 15:11 UTC, darrell pfeifer
no flags Details
Output of "yum history info systemd-units (29.14 KB, text/plain)
2010-07-29 17:29 UTC, Gene Snider
no flags Details
/var/log/boot.log with wireless lan startup failure (4.82 KB, text/plain)
2010-07-29 17:30 UTC, Gene Snider
no flags Details
spec patch (862 bytes, patch)
2010-07-30 02:42 UTC, Bill Nottingham
no flags Details | Diff
yum history info systemd-units (73.29 KB, text/plain)
2010-07-30 03:57 UTC, GoinEasy9
no flags Details
Error Output (155.98 KB, image/png)
2010-08-09 05:40 UTC, He Rui
no flags Details

Description Jóhann B. Guðmundsson 2010-07-26 16:23:40 UTC
Description of problem:

Log

Activating default unit: default.target
Failed to load configuration for default.target: No such file or directory
Trying to enqueue job default.target/start
Failed to start default target: Unit default.target failed to load. See logs for default. 

Version-Release number of selected component (if applicable):

4-3

How reproducible:

Always

Steps to Reproduce:
1. Boot with systemd
2.
3.
  
Actual results:

The above

Expected results:

Rainbows what else?

Additional info:

Comment 1 Michal Schmidt 2010-07-27 11:17:12 UTC
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.

Comment 2 Michal Schmidt 2010-07-27 11:20:54 UTC
> systemctl enable getty.service

Correction, s/service/target/

Comment 3 Michal Schmidt 2010-07-27 11:33:27 UTC
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.

Comment 4 GoinEasy9 2010-07-29 03:09:54 UTC
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.

Comment 5 GoinEasy9 2010-07-29 03:42:36 UTC
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.

Comment 6 GoinEasy9 2010-07-29 03:43:55 UTC
Created attachment 435184 [details]
End of message file / systemd

Comment 7 darrell pfeifer 2010-07-29 04:54:21 UTC
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)

Comment 8 Lennart Poettering 2010-07-29 13:18:52 UTC
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.

Comment 9 Michal Schmidt 2010-07-29 14:08:44 UTC
GoinEasy9,
could you attach the output of "yum history info systemd-units"?

Comment 10 darrell pfeifer 2010-07-29 15:11:43 UTC
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.

Comment 11 Michal Schmidt 2010-07-29 15:26:40 UTC
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.

Comment 12 Gene Snider 2010-07-29 15:41:23 UTC
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

Comment 13 Michal Schmidt 2010-07-29 15:57:18 UTC
(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.

Comment 14 GoinEasy9 2010-07-29 16:05:00 UTC
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.

Comment 15 Gene Snider 2010-07-29 17:29:48 UTC
Created attachment 435353 [details]
Output of "yum history info systemd-units

Comment 16 Gene Snider 2010-07-29 17:30:53 UTC
Created attachment 435354 [details]
/var/log/boot.log with wireless lan startup failure

Comment 17 Gene Snider 2010-07-29 17:34:13 UTC
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

Comment 18 Michal Schmidt 2010-07-29 20:40:53 UTC
(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.

Comment 19 Bill Nottingham 2010-07-30 02:42:29 UTC
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.

Comment 20 GoinEasy9 2010-07-30 03:56:32 UTC
I don't now if you still need my output from yum history info systemd-units, but is the attachment anyway.

Comment 21 GoinEasy9 2010-07-30 03:57:10 UTC
Created attachment 435454 [details]
yum history info systemd-units

Comment 22 Bug Zapper 2010-07-30 12:51:31 UTC
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 23 Michal Schmidt 2010-07-30 14:57:10 UTC
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.

Comment 24 Bill Nottingham 2010-07-30 15:45:51 UTC
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.

Comment 25 Michal Schmidt 2010-07-30 16:49:33 UTC
(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.

Comment 26 Jeff Layton 2010-07-31 19:00:39 UTC
*** Bug 619903 has been marked as a duplicate of this bug. ***

Comment 27 Michal Schmidt 2010-08-02 11:07:20 UTC
*** Bug 620176 has been marked as a duplicate of this bug. ***

Comment 28 Lennart Poettering 2010-08-04 01:02:07 UTC
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.

Comment 29 Martin Stransky 2010-08-04 09:17:16 UTC
*** Bug 620462 has been marked as a duplicate of this bug. ***

Comment 30 He Rui 2010-08-09 05:39:28 UTC
Reproduced it after a fresh virt-install of F14-Alpha-RC2

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

Comment 31 He Rui 2010-08-09 05:40:33 UTC
Created attachment 437519 [details]
Error Output

Comment 32 He Rui 2010-08-09 06:54:14 UTC
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)

Comment 33 Michal Schmidt 2010-08-09 07:28:02 UTC
(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.

Comment 34 Nils Philippsen 2010-08-09 10:12:52 UTC
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?

Comment 35 Bill Nottingham 2010-08-11 19:24:44 UTC
*** Bug 622634 has been marked as a duplicate of this bug. ***

Comment 36 Andre Robatino 2010-08-27 01:39:34 UTC
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?

Comment 37 Andre Robatino 2010-08-27 01:54:58 UTC
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


Note You need to log in before you can comment on or make changes to this bug.