Patchwork [v2] systemd: set default.target to multi-user.target

login
register
mail settings
Submitter Radu Moisan
Date Jan. 25, 2013, 2:59 p.m.
Message ID <1359125976-26763-1-git-send-email-radu.moisan@intel.com>
Download mbox | patch
Permalink /patch/43379/
State New
Headers show

Comments

Radu Moisan - Jan. 25, 2013, 2:59 p.m.
this fixes a service dependency issue;
while graphical.target is the default mode, systemd
will try to start display-manager.service which is not
available.

Signed-off-by: Radu Moisan <radu.moisan@intel.com>
---
 meta/conf/distro/include/default-distrovars.inc |    3 +++
 meta/recipes-core/systemd/systemd_196.bb        |    5 +++++
 2 files changed, 8 insertions(+)
Ross Burton - Jan. 25, 2013, 3:04 p.m.
On 25 January 2013 14:59, Radu Moisan <radu.moisan@intel.com> wrote:
> +# "multi-user" vs "graphical"
> +SYSTEMD_DEFAULT_TARGET ?= "multi-user"

Default to "graphical", so we're not regressing and just introducing a
warning if someone doesn't set this and doesn't have X.

> @@ -95,6 +95,11 @@ do_install() {
>         install -m 0644 ${WORKDIR}/var-run.conf ${D}${sysconfdir}/tmpfiles.d/
>
>         install -m 0644 ${WORKDIR}/00-create-volatile.conf ${D}${sysconfdir}/tmpfiles.d/
> +
> +
> +       if [ -n ${SYSTEMD_DEFAULT_TARGET} ]; then
> +               ln -s ${systemd_unitdir}/system/${SYSTEMD_DEFAULT_TARGET}.target ${D}${sysconfdir}/systemd/system/default.target
> +       fi

This will have to happen at image construction time and not package
generation time, as different images may have different targets but
share the same systemd package.

A rootfs-time postinstall script would work, but isn't very nice.  I
wonder if there's a better solution, hooking into the image creation
should work.

(thinks)

Ross
Richard Purdie - Jan. 25, 2013, 3:10 p.m.
On Fri, 2013-01-25 at 15:04 +0000, Burton, Ross wrote:
> On 25 January 2013 14:59, Radu Moisan <radu.moisan@intel.com> wrote:
> > +# "multi-user" vs "graphical"
> > +SYSTEMD_DEFAULT_TARGET ?= "multi-user"
> 
> Default to "graphical", so we're not regressing and just introducing a
> warning if someone doesn't set this and doesn't have X.
> 
> > @@ -95,6 +95,11 @@ do_install() {
> >         install -m 0644 ${WORKDIR}/var-run.conf ${D}${sysconfdir}/tmpfiles.d/
> >
> >         install -m 0644 ${WORKDIR}/00-create-volatile.conf ${D}${sysconfdir}/tmpfiles.d/
> > +
> > +
> > +       if [ -n ${SYSTEMD_DEFAULT_TARGET} ]; then
> > +               ln -s ${systemd_unitdir}/system/${SYSTEMD_DEFAULT_TARGET}.target ${D}${sysconfdir}/systemd/system/default.target
> > +       fi
> 
> This will have to happen at image construction time and not package
> generation time, as different images may have different targets but
> share the same systemd package.
> 
> A rootfs-time postinstall script would work, but isn't very nice.  I
> wonder if there's a better solution, hooking into the image creation
> should work.
> 
> (thinks)

The point here is that images shouldn't give errors at runtime. Nothing
above does anything to address that. There is something going to have to
happen at image creation time so that systemd is correctly configured in
the current scheme of things.

Cheers,

Richard
Martin Jansa - Jan. 25, 2013, 3:12 p.m.
On Fri, Jan 25, 2013 at 03:04:25PM +0000, Burton, Ross wrote:
> On 25 January 2013 14:59, Radu Moisan <radu.moisan@intel.com> wrote:
> > +# "multi-user" vs "graphical"
> > +SYSTEMD_DEFAULT_TARGET ?= "multi-user"
> 
> Default to "graphical", so we're not regressing and just introducing a
> warning if someone doesn't set this and doesn't have X.

Or empty by default (add quotes in that test -n below).

> 
> > @@ -95,6 +95,11 @@ do_install() {
> >         install -m 0644 ${WORKDIR}/var-run.conf ${D}${sysconfdir}/tmpfiles.d/
> >
> >         install -m 0644 ${WORKDIR}/00-create-volatile.conf ${D}${sysconfdir}/tmpfiles.d/
> > +
> > +
> > +       if [ -n ${SYSTEMD_DEFAULT_TARGET} ]; then
> > +               ln -s ${systemd_unitdir}/system/${SYSTEMD_DEFAULT_TARGET}.target ${D}${sysconfdir}/systemd/system/default.target
> > +       fi
> 
> This will have to happen at image construction time and not package
> generation time, as different images may have different targets but
> share the same systemd package.
> 
> A rootfs-time postinstall script would work, but isn't very nice.  I
> wonder if there's a better solution, hooking into the image creation
> should work.
> 
> (thinks)
> 
> Ross
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Ross Burton - Jan. 25, 2013, 5:50 p.m.
Hi,

Been chatting to Richard.  How about systemd ships a symlink to
multi-user, and the X11 init script packages change the symlink to
graphical in their postinst.

(we must remember to put this in the release notes for anyone who has
a custom X init script)

Ross
Andreas Müller - Jan. 25, 2013, 5:53 p.m.
On Fri, Jan 25, 2013 at 6:50 PM, Burton, Ross <ross.burton@intel.com> wrote:
> Hi,
>
> Been chatting to Richard.  How about systemd ships a symlink to
> multi-user, and the X11 init script packages change the symlink to
> graphical in their postinst.
>
> (we must remember to put this in the release notes for anyone who has
> a custom X init script)
>
> Ross
>
Have not yet tested but how about:

pkg_postinst_systemd () {
if [ -n "$D" ]; then
	# no display-manager.service around?
	if [ ! -e ${D}${systemd_unitdir}/systemd/system/display-manager.service -a \
	     ! grep 'Alias=display-manager.service'
${D}${systemd_unitdir}/systemd/system ]; then
		ln -s ${systemd_unitdir}/system/multi-user.target
${D}${systemd_unitdir}/systemd/system/default.target
	fi
fi

...

Andreas
Martin Jansa - Jan. 25, 2013, 6:06 p.m.
On Fri, Jan 25, 2013 at 06:53:54PM +0100, Andreas Müller wrote:
> On Fri, Jan 25, 2013 at 6:50 PM, Burton, Ross <ross.burton@intel.com> wrote:
> > Hi,
> >
> > Been chatting to Richard.  How about systemd ships a symlink to
> > multi-user, and the X11 init script packages change the symlink to
> > graphical in their postinst.
> >
> > (we must remember to put this in the release notes for anyone who has
> > a custom X init script)
> >
> > Ross
> >
> Have not yet tested but how about:
> 
> pkg_postinst_systemd () {
> if [ -n "$D" ]; then
> 	# no display-manager.service around?
> 	if [ ! -e ${D}${systemd_unitdir}/systemd/system/display-manager.service -a \

I think you wanted $D ^ here.

> 	     ! grep 'Alias=display-manager.service'
> ${D}${systemd_unitdir}/systemd/system ]; then
> 		ln -s ${systemd_unitdir}/system/multi-user.target
> ${D}${systemd_unitdir}/systemd/system/default.target
> 	fi
> fi

Cannot we just just u-a for default.target ? And each possible target
providing own u-a alternative (DMs with higher prio then systemd)?

Cheers,
Andreas Müller - Jan. 25, 2013, 6:35 p.m.
On Fri, Jan 25, 2013 at 7:06 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
> On Fri, Jan 25, 2013 at 06:53:54PM +0100, Andreas Müller wrote:
>> On Fri, Jan 25, 2013 at 6:50 PM, Burton, Ross <ross.burton@intel.com> wrote:
>> > Hi,
>> >
>> > Been chatting to Richard.  How about systemd ships a symlink to
>> > multi-user, and the X11 init script packages change the symlink to
>> > graphical in their postinst.
>> >
>> > (we must remember to put this in the release notes for anyone who has
>> > a custom X init script)
>> >
>> > Ross
>> >
>> Have not yet tested but how about:
>>
>> pkg_postinst_systemd () {
>> if [ -n "$D" ]; then
>>       # no display-manager.service around?
>>       if [ ! -e ${D}${systemd_unitdir}/systemd/system/display-manager.service -a \
>
> I think you wanted $D ^ here.
Yes there are more of this but before cleaning up & run into tests:
Would this find friends?

> Cannot we just just u-a for default.target ? And each possible target
> providing own u-a alternative (DMs with higher prio then systemd)?
Sorry but I don't understand this

Andreas
Martin Jansa - Jan. 25, 2013, 7:34 p.m.
On Fri, Jan 25, 2013 at 07:35:51PM +0100, Andreas Müller wrote:
> On Fri, Jan 25, 2013 at 7:06 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
> > On Fri, Jan 25, 2013 at 06:53:54PM +0100, Andreas Müller wrote:
> >> On Fri, Jan 25, 2013 at 6:50 PM, Burton, Ross <ross.burton@intel.com> wrote:
> >> > Hi,
> >> >
> >> > Been chatting to Richard.  How about systemd ships a symlink to
> >> > multi-user, and the X11 init script packages change the symlink to
> >> > graphical in their postinst.
> >> >
> >> > (we must remember to put this in the release notes for anyone who has
> >> > a custom X init script)
> >> >
> >> > Ross
> >> >
> >> Have not yet tested but how about:
> >>
> >> pkg_postinst_systemd () {
> >> if [ -n "$D" ]; then
> >>       # no display-manager.service around?
> >>       if [ ! -e ${D}${systemd_unitdir}/systemd/system/display-manager.service -a \
> >
> > I think you wanted $D ^ here.
> Yes there are more of this but before cleaning up & run into tests:
> Would this find friends?
> 
> > Cannot we just just u-a for default.target ? And each possible target
> > providing own u-a alternative (DMs with higher prio then systemd)?
> Sorry but I don't understand this

Something like:

systemd:
inherit update-alternatives
ALTERNATIVE_${PN} = "systemd-def-target"
ALTERNATIVE_TARGET[systemd-def-target] = "${systemd_unitdir}/system/multi-user.target"
ALTERNATIVE_LINK_NAME[systemd-def-target] = "${systemd_unitdir}/systemd/system/default.target"
ALTERNATIVE_PRIORITY[systemd-def-target] ?= "1"

xserver-nodm-init and DMs:
inherit update-alternatives
ALTERNATIVE_${PN} = "systemd-def-target"
ALTERNATIVE_TARGET[systemd-def-target] = "${systemd_unitdir}/system/graphical.target"
ALTERNATIVE_LINK_NAME[systemd-def-target] = "${systemd_unitdir}/systemd/system/default.target"
ALTERNATIVE_PRIORITY[systemd-def-target] ?= "10"

Cheers,
Ross Burton - Jan. 25, 2013, 8:21 p.m.
On Friday, 25 January 2013 at 19:34, Martin Jansa wrote:
> Something like:
> 
> systemd:
> inherit update-alternatives
> ALTERNATIVE_${PN} = "systemd-def-target"
> ALTERNATIVE_TARGET[systemd-def-target] = "${systemd_unitdir}/system/multi-user.target"
> ALTERNATIVE_LINK_NAME[systemd-def-target] = "${systemd_unitdir}/systemd/system/default.target"
> ALTERNATIVE_PRIORITY[systemd-def-target] ?= "1"
> 
> xserver-nodm-init and DMs:
> inherit update-alternatives
> ALTERNATIVE_${PN} = "systemd-def-target"
> ALTERNATIVE_TARGET[systemd-def-target] = "${systemd_unitdir}/system/graphical.target"
> ALTERNATIVE_LINK_NAME[systemd-def-target] = "${systemd_unitdir}/systemd/system/default.target"
> ALTERNATIVE_PRIORITY[systemd-def-target] ?= "10"

Can you make those conditional on the systemd feature so that we don't get complaints from people using something else?

You could use different names and map them to ALTERNATIVE_* inside systemd.bbclass, assuming/enforcing that everyone who wants to set the default target inherits that class I guess.

Ross
Martin Jansa - Jan. 25, 2013, 8:26 p.m.
On Fri, Jan 25, 2013 at 08:21:05PM +0000, Ross Burton wrote:
> On Friday, 25 January 2013 at 19:34, Martin Jansa wrote:
> > Something like:
> > 
> > systemd:
> > inherit update-alternatives
> > ALTERNATIVE_${PN} = "systemd-def-target"
> > ALTERNATIVE_TARGET[systemd-def-target] = "${systemd_unitdir}/system/multi-user.target"
> > ALTERNATIVE_LINK_NAME[systemd-def-target] = "${systemd_unitdir}/systemd/system/default.target"
> > ALTERNATIVE_PRIORITY[systemd-def-target] ?= "1"
> > 
> > xserver-nodm-init and DMs:
> > inherit update-alternatives
> > ALTERNATIVE_${PN} = "systemd-def-target"
> > ALTERNATIVE_TARGET[systemd-def-target] = "${systemd_unitdir}/system/graphical.target"
> > ALTERNATIVE_LINK_NAME[systemd-def-target] = "${systemd_unitdir}/systemd/system/default.target"
> > ALTERNATIVE_PRIORITY[systemd-def-target] ?= "10"
> 
> Can you make those conditional on the systemd feature so that we don't get complaints from people using something else?

xserver-nodm-init:
ALTERNATIVE_${PN}-systemd = "systemd-def-target"

And only people which install xserver-nodm-init-system in image will see
that.

> You could use different names and map them to ALTERNATIVE_* inside systemd.bbclass, assuming/enforcing that everyone who wants to set the default target inherits that class I guess.

I don't understand what you mean.

Cheers,
Andreas Müller - Jan. 25, 2013, 9:09 p.m.
On Fri, Jan 25, 2013 at 9:26 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
> On Fri, Jan 25, 2013 at 08:21:05PM +0000, Ross Burton wrote:
>> On Friday, 25 January 2013 at 19:34, Martin Jansa wrote:
>> > Something like:
>> >
>> > systemd:
>> > inherit update-alternatives
>> > ALTERNATIVE_${PN} = "systemd-def-target"
>> > ALTERNATIVE_TARGET[systemd-def-target] = "${systemd_unitdir}/system/multi-user.target"
>> > ALTERNATIVE_LINK_NAME[systemd-def-target] = "${systemd_unitdir}/systemd/system/default.target"
>> > ALTERNATIVE_PRIORITY[systemd-def-target] ?= "1"
>> >
>> > xserver-nodm-init and DMs:
>> > inherit update-alternatives
>> > ALTERNATIVE_${PN} = "systemd-def-target"
>> > ALTERNATIVE_TARGET[systemd-def-target] = "${systemd_unitdir}/system/graphical.target"
>> > ALTERNATIVE_LINK_NAME[systemd-def-target] = "${systemd_unitdir}/systemd/system/default.target"
>> > ALTERNATIVE_PRIORITY[systemd-def-target] ?= "10"
>>
>> Can you make those conditional on the systemd feature so that we don't get complaints from people using something else?
>
> xserver-nodm-init:
> ALTERNATIVE_${PN}-systemd = "systemd-def-target"
>
> And only people which install xserver-nodm-init-system in image will see
> that.
>
>> You could use different names and map them to ALTERNATIVE_* inside systemd.bbclass, assuming/enforcing that everyone who wants to set the default target inherits that class I guess.
>
> I don't understand what you mean.
>
Please let's remember how it started: avoiding a single warning for
missing display-manager.service on console images...

Andreas
Richard Purdie - Jan. 25, 2013, 11:52 p.m.
On Fri, 2013-01-25 at 22:09 +0100, Andreas Müller wrote:
> Please let's remember how it started: avoiding a single warning for
> missing display-manager.service on console images...

Don't be too quick to trivialise this. You start with accepting one
warning at boot. Another appears, well its only one more and there was a
warning anyway, you can't remember which was always there and is safe to
ignore. Before long you have lots of warnings at boot and its ok, we had
warnings anyway, right?

Warnings show how much we care about the thing we're producing. Whist
this is annoying, lets fix it once and for all, properly.

Cheers,

Richard
Radu Moisan - Jan. 28, 2013, 9:41 a.m.
On 01/25/2013 05:10 PM, Richard Purdie wrote:
> On Fri, 2013-01-25 at 15:04 +0000, Burton, Ross wrote:
>> On 25 January 2013 14:59, Radu Moisan <radu.moisan@intel.com> wrote:
>>> +# "multi-user" vs "graphical"
>>> +SYSTEMD_DEFAULT_TARGET ?= "multi-user"
>> Default to "graphical", so we're not regressing and just introducing a
>> warning if someone doesn't set this and doesn't have X.
>>
>>> @@ -95,6 +95,11 @@ do_install() {
>>>          install -m 0644 ${WORKDIR}/var-run.conf ${D}${sysconfdir}/tmpfiles.d/
>>>
>>>          install -m 0644 ${WORKDIR}/00-create-volatile.conf ${D}${sysconfdir}/tmpfiles.d/
>>> +
>>> +
>>> +       if [ -n ${SYSTEMD_DEFAULT_TARGET} ]; then
>>> +               ln -s ${systemd_unitdir}/system/${SYSTEMD_DEFAULT_TARGET}.target ${D}${sysconfdir}/systemd/system/default.target
>>> +       fi
>> This will have to happen at image construction time and not package
>> generation time, as different images may have different targets but
>> share the same systemd package.
>>
>> A rootfs-time postinstall script would work, but isn't very nice.  I
>> wonder if there's a better solution, hooking into the image creation
>> should work.
>>
>> (thinks)
> The point here is that images shouldn't give errors at runtime. Nothing
> above does anything to address that.

I don't understand what you mean. The patch addresses exactly that, 
warning at runtime, to be more specific the warning about 
display-manager.service
However though, I understand the issues with this approach, so I'll dig 
a little more into Martin's approach with update-alternatives.

Radu
Ross Burton - Jan. 28, 2013, 10:44 a.m.
On 25 January 2013 20:26, Martin Jansa <martin.jansa@gmail.com> wrote:
> ALTERNATIVE_${PN}-systemd = "systemd-def-target"

Let's not introduce packages controlled on distro features whose sole
purpose is to contain a single file.  systemd enabled -> units go into
$PN.

Or, if we accept PN-systemd packages, then I expect to see PN-sysvinit packages.

Ross
Otavio Salvador - Jan. 28, 2013, 11:20 a.m.
On Mon, Jan 28, 2013 at 8:44 AM, Burton, Ross <ross.burton@intel.com> wrote:
> On 25 January 2013 20:26, Martin Jansa <martin.jansa@gmail.com> wrote:
>> ALTERNATIVE_${PN}-systemd = "systemd-def-target"
>
> Let's not introduce packages controlled on distro features whose sole
> purpose is to contain a single file.  systemd enabled -> units go into
> $PN.
>
> Or, if we accept PN-systemd packages, then I expect to see PN-sysvinit packages.

I expect to see PN-sysvinit so we can void them ;-)

--
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br
Andreas Müller - Jan. 28, 2013, 11:48 a.m.
On Mon, Jan 28, 2013 at 11:44 AM, Burton, Ross <ross.burton@intel.com> wrote:
> On 25 January 2013 20:26, Martin Jansa <martin.jansa@gmail.com> wrote:
>> ALTERNATIVE_${PN}-systemd = "systemd-def-target"
>
> Let's not introduce packages controlled on distro features whose sole
> purpose is to contain a single file.  systemd enabled -> units go into
> $PN.
It's more than that: postinst and companions to auto enable/disable services.

Andreas
Ross Burton - Jan. 28, 2013, 11:50 a.m.
On 28 January 2013 11:48, Andreas Müller <schnitzeltony@googlemail.com> wrote:
> On Mon, Jan 28, 2013 at 11:44 AM, Burton, Ross <ross.burton@intel.com> wrote:
>> On 25 January 2013 20:26, Martin Jansa <martin.jansa@gmail.com> wrote:
>>> ALTERNATIVE_${PN}-systemd = "systemd-def-target"
>>
>> Let's not introduce packages controlled on distro features whose sole
>> purpose is to contain a single file.  systemd enabled -> units go into
>> $PN.
> It's more than that: postinst and companions to auto enable/disable services.

Which are controlled by a distribution feature, so have no need to be
in a separate package.

Ross
Martin Jansa - Jan. 28, 2013, 6:27 p.m.
On Mon, Jan 28, 2013 at 10:44:08AM +0000, Burton, Ross wrote:
> On 25 January 2013 20:26, Martin Jansa <martin.jansa@gmail.com> wrote:
> > ALTERNATIVE_${PN}-systemd = "systemd-def-target"
> 
> Let's not introduce packages controlled on distro features whose sole
> purpose is to contain a single file.  systemd enabled -> units go into
> $PN.

So I guess upgrade path from meta-systemd won't be ever provided (e.g.
with RPROVIDES/RCONFLICTS/RREPLACES combo).

 * check_data_file_clashes: Package dbus-1 wants to install file
 * /lib/systemd/system/multi-user.target.wants/dbus.service
        But that file is already provided by package  * dbus-systemd
 * check_data_file_clashes: Package dbus-1 wants to install file
 * /lib/systemd/system/dbus.socket
        But that file is already provided by package  * dbus-systemd
 * check_data_file_clashes: Package dbus-1 wants to install file
 * /lib/systemd/system/sockets.target.wants/dbus.socket
        But that file is already provided by package  * dbus-systemd
 * check_data_file_clashes: Package dbus-1 wants to install file
 * /lib/systemd/system/dbus.target.wants/dbus.socket
        But that file is already provided by package  * dbus-systemd
 * check_data_file_clashes: Package dbus-1 wants to install file
 * /lib/systemd/system/dbus.service
        But that file is already provided by package  * dbus-systemd

> Or, if we accept PN-systemd packages, then I expect to see PN-sysvinit packages.

I wouldn't mind PN-sysvinit, PN-upstart, PN-openrc

It was easy to blacklist sysvinit scripts and then control which packages
should have systemd support just by IMAGE_INSTALL.

Cheers,
Ross Burton - Jan. 28, 2013, 7:27 p.m.
On 28 January 2013 18:27, Martin Jansa <martin.jansa@gmail.com> wrote:
> So I guess upgrade path from meta-systemd won't be ever provided (e.g.
> with RPROVIDES/RCONFLICTS/RREPLACES combo).

I'd prefer not too, but if we have to we can.

> I wouldn't mind PN-sysvinit, PN-upstart, PN-openrc

But what's the point when its a distro variable? With systemd daemons
are actively making code changes instead of it merely being a
different init file, so an image feature just won't work.

Ross
Martin Jansa - Jan. 28, 2013, 7:48 p.m.
On Mon, Jan 28, 2013 at 07:27:22PM +0000, Burton, Ross wrote:
> On 28 January 2013 18:27, Martin Jansa <martin.jansa@gmail.com> wrote:
> > So I guess upgrade path from meta-systemd won't be ever provided (e.g.
> > with RPROVIDES/RCONFLICTS/RREPLACES combo).
> 
> I'd prefer not too, but if we have to we can.
> 
> > I wouldn't mind PN-sysvinit, PN-upstart, PN-openrc
> 
> But what's the point when its a distro variable? With systemd daemons
> are actively making code changes instead of it merely being a
> different init file, so an image feature just won't work.

to control which packages should have systemd support just by IMAGE_INSTALL.

With latest systemd.bbclass you can still install them but not enable
them by default, but even after SYSTEMD_AUTO_RRECOMMENDS was introduced
I prefered to turn that off and control what I want in images (or
install from feed).

Imagine situation when someone wants ntpd package just for ocassional
manual sync, but someone else wants to pull ntpd to image together with
systemd .service file to make sure his device is always using right
time.

Cheers,

Patch

diff --git a/meta/conf/distro/include/default-distrovars.inc b/meta/conf/distro/include/default-distrovars.inc
index f073547..c21d9a3 100644
--- a/meta/conf/distro/include/default-distrovars.inc
+++ b/meta/conf/distro/include/default-distrovars.inc
@@ -22,6 +22,9 @@  DISTRO_FEATURES_LIBC_class-nativesdk = "${DISTRO_FEATURES_LIBC_DEFAULT}"
 DISTRO_FEATURES_INITMAN ?= "sysvinit"
 DISTRO_FEATURES ?= "alsa argp bluetooth ext2 irda largefile pcmcia usbgadget usbhost wifi xattr nfs zeroconf pci 3g x11 ${DISTRO_FEATURES_LIBC} ${DISTRO_FEATURES_INITMAN}"
 
+# "multi-user" vs "graphical"
+SYSTEMD_DEFAULT_TARGET ?= "multi-user"
+
 IMAGE_FEATURES ?= ""
 
 # This is a list of packages that are used by the build system to build the distribution, they are not
diff --git a/meta/recipes-core/systemd/systemd_196.bb b/meta/recipes-core/systemd/systemd_196.bb
index a78a8a6..4b97774 100644
--- a/meta/recipes-core/systemd/systemd_196.bb
+++ b/meta/recipes-core/systemd/systemd_196.bb
@@ -95,6 +95,11 @@  do_install() {
 	install -m 0644 ${WORKDIR}/var-run.conf ${D}${sysconfdir}/tmpfiles.d/
 
 	install -m 0644 ${WORKDIR}/00-create-volatile.conf ${D}${sysconfdir}/tmpfiles.d/
+
+
+	if [ -n ${SYSTEMD_DEFAULT_TARGET} ]; then
+		ln -s ${systemd_unitdir}/system/${SYSTEMD_DEFAULT_TARGET}.target ${D}${sysconfdir}/systemd/system/default.target
+	fi
 }
 
 python populate_packages_prepend (){