Tobias, sorry for being so long in coming back around to this, but I
followed a pointer to this bug from another one and am now trying to
understand the regression that you're describing.
You described this as "bricking" your servers, but per the SRU
regression analysis:
Running [networkd] befo
** No longer affects: cloud-init
** No longer affects: cloud-init (Ubuntu)
** No longer affects: cloud-init (Ubuntu Xenial)
** No longer affects: cloud-init (Ubuntu Yakkety)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bu
** Merge proposal linked:
https://code.launchpad.net/~raharper/cloud-init/+git/cloud-init/+merge/317917
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1636912
Title:
systemd-networkd runs too late
** Tags removed: verification-needed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1636912
Title:
systemd-networkd runs too late for cloud-init.service (net)
To manage notifications about this bug
** Also affects: cloud-init
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1636912
Title:
systemd-networkd runs too late for cloud-init.service (net)
To m
Thanks for bricking our servers: http://i.imgur.com/DFFrSs1.png
This fixes it:
cat /etc/systemd/system/systemd-networkd.service.d/override.conf
[Unit]
After=dbus.service
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.
** Bug watch removed: github.com/systemd/systemd/issues #4646
https://github.com/systemd/systemd/issues/4646
** Bug watch removed: freedesktop.org Bugzilla #98254
https://bugs.freedesktop.org/show_bug.cgi?id=98254
--
You received this bug notification because you are a member of Ubuntu
Bug
** Changed in: cloud-init (Ubuntu Yakkety)
Importance: Undecided => Medium
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1636912
Title:
systemd-networkd runs too late for cloud-init.service (net)
** Changed in: systemd (Ubuntu Yakkety)
Importance: Undecided => Medium
** No longer affects: resolvconf (Ubuntu Yakkety)
** No longer affects: resolvconf (Ubuntu Xenial)
** No longer affects: resolvconf (Ubuntu)
** Package changed: resolvconf (Debian) => ubuntu-translations
** Changed in:
The resolvconf portion of this issue has been moved to bug #1649931.
I'm removing resolvconf 1.78ubuntu3 from xenial-proposed and will
replace it with a resolvconf 1.78ubuntu4 with the correct bug ref.
** Changed in: resolvconf (Ubuntu Xenial)
Status: Fix Committed => Invalid
** Changed in
Hello Ryan, or anyone else affected,
Accepted resolvconf into xenial-proposed. The package will build now and
be available at
https://launchpad.net/ubuntu/+source/resolvconf/1.78ubuntu3 in a few
hours, and then in the -proposed repository.
Please help us by testing this new package. See
https://
** Changed in: resolvconf (Debian)
Status: New => Fix Committed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1636912
Title:
systemd-networkd runs too late for cloud-init.service (net)
To ma
The attachment "xenial_resolvconf-lp1636912.debdiff" seems to be a
debdiff. The ubuntu-sponsors team has been subscribed to the bug report
so that they can review and hopefully sponsor the debdiff. If the
attachment isn't a patch, please remove the "patch" flag from the
attachment, remove the "pa
This bug was fixed in the package systemd - 231-9ubuntu2
---
systemd (231-9ubuntu2) yakkety; urgency=medium
[ Dan Streetman ]
* rules: introduce disk/by-id (model_serial) symlinks for NVMe drives
(LP: #1642903)
[ Martin Pitt ]
* Drop systemd-networkd's "After=dbus.service
This bug was fixed in the package systemd - 229-4ubuntu13
---
systemd (229-4ubuntu13) xenial; urgency=medium
[ Martin Pitt ]
* Backport graphical-session{,-pre}.target user units, for future usage from
snaps. (LP: #1640293)
* debian/rules: Clean up *.busname units. They are
** Tags removed: verification-needed
** Tags added: verification-done
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1636912
Title:
systemd-networkd runs too late for cloud-init.service (net)
To man
I've opened a new bug for the DNS networkd/resolvconf issue:
https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1649931
We'll track a new SRU for fixing that issue separately.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
ht
On Tue, Dec 13, 2016 at 10:02 AM, Martin Pitt
wrote:
> Ryan Harper [2016-12-06 12:54 -]:
> > The following change should go against systemd-networkd-wait-
> > online.service
> >
> > + # Ensure that DNS is working before reaching online target
> > + After=systemd-networkd-resolvconf-update.ser
Ryan Harper [2016-12-06 12:54 -]:
> The following change should go against systemd-networkd-wait-
> online.service
>
> + # Ensure that DNS is working before reaching online target
> + After=systemd-networkd-resolvconf-update.service
For the record, this should be the other way around -- add
B
This bug was fixed in the package resolvconf - 1.79ubuntu4
---
resolvconf (1.79ubuntu4) zesty; urgency=medium
* debian/resolvconf.service: Add missing Wants=network-pre.target.
-- Martin Pitt Thu, 08 Dec 2016 10:21:12
+0100
** Changed in: resolvconf (Ubuntu)
Status: Fix
** Changed in: resolvconf (Debian)
Status: Unknown => New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1636912
Title:
systemd-networkd runs too late for cloud-init.service (net)
To manage n
** Also affects: resolvconf (Debian) via
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=847440
Importance: Unknown
Status: Unknown
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1636912
Filed in Debian (resolvconf) https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=847440
** Bug watch added: Debian Bug tracker #847440
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=847440
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to U
** Changed in: resolvconf (Ubuntu Xenial)
Status: Triaged => In Progress
** Changed in: resolvconf (Ubuntu Yakkety)
Status: Triaged => In Progress
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.ne
Add a Wants=network-pre.target for resolvconf
** Patch added: "yakkety_resolvconf-lp1636912-v2.debdiff"
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1636912/+attachment/4788949/+files/yakkety_resolvconf-lp1636912-v2.debdiff
--
You received this bug notification because you are a me
Reuploaded x/y/z to add missing Wants=network-pre.target.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1636912
Title:
systemd-networkd runs too late for cloud-init.service (net)
To manage notifica
Add a Wants=network-pre.target to resolvconf service.
** Patch added: "xenial_resolvconf-lp1636912-v2.debdiff"
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1636912/+attachment/4788950/+files/xenial_resolvconf-lp1636912-v2.debdiff
--
You received this bug notification because you ar
Testing in debian shows that to use network-pre.target, resolvconf needs
to include a Wants=network-pre.target to ensure that it gets pulled in
as a unit. I'm attaching updated debdiffs for xenial and yakkety.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which i
resolvconf uploaded to zesty and x/y SRU review queues. Please forward
to Debian too.
** Changed in: resolvconf (Ubuntu)
Status: Triaged => Fix Committed
** Changed in: resolvconf (Ubuntu)
Assignee: (unassigned) => Ryan Harper (raharper)
--
You received this bug notification because
Adding yakkety debdiff for resolvconf changes.
** Patch added: "yakkety_resolvconf-lp1636912.debdiff"
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1636912/+attachment/4788513/+files/yakkety_resolvconf-lp1636912.debdiff
--
You received this bug notification because you are a member
Adding xenial debdiff for resolvconf changes.
** Patch added: "xenial_resolvconf-lp1636912.debdiff"
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1636912/+attachment/4788512/+files/xenial_resolvconf-lp1636912.debdiff
--
You received this bug notification because you are a member of
I've tested Before=network-pre.target; that works fine. However, for
the networkd case, systemd-networkd-wait-online.target should ensure
that systemd-networkd-resolvconf-update.service has run first otherwise
there might a window where interfaces are configured, but DNS is not.
The following cha
> Before=networking.service
> +Before=systemd-networkd.service
FTR, this should be generalized to Before=network-pre.target. This is
also applicable to Debian.
** Also affects: resolvconf (Ubuntu)
Importance: Undecided
Status: New
** Changed in: resolvconf (Ubuntu)
Status: New
I built a new UC16 image with the systemd proposed package. Initially
networkd running early is fine. However, under closer inspection, in a
networkd-only image, DNS (resolvconf) was not running early enough to
allow DNS service to be available at the time that cloud-init.service
runs (which may
This bug was fixed in the package systemd - 232-7
---
systemd (232-7) unstable; urgency=medium
[ Michael Biebl ]
* Mark liblz4-tool build dependency as
* udev: Try mount -n -o move first
initramfs-tools is not actually using util-linux mount (yet), so making
mount -n --
Hi. This issue affected us on Xenial; we explicitly enable systemd-
networkd on our images (when creating our AMI), and after a recent AMI
rebuild we were no longer able to start our AMIs. When I looked at the
system console we saw things that looked like:
[ 52.866176] cloud-init[721]: Cloud-in
** Changed in: systemd (Ubuntu Xenial)
Assignee: Martin Pitt (pitti) => (unassigned)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1636912
Title:
systemd-networkd runs too late for cloud-init.s
Hello Ryan, or anyone else affected,
Accepted systemd into yakkety-proposed. The package will build now and
be available at
https://launchpad.net/ubuntu/+source/systemd/231-9ubuntu2 in a few
hours, and then in the -proposed repository.
Please help us by testing this new package. See
https://wiki
** Changed in: systemd
Status: New => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1636912
Title:
systemd-networkd runs too late for cloud-init.service (net)
To manage notifica
I suppose you want this for yakkety too, so backported:
https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?h
=ubuntu-yakkety&id=648c659e9
** Description changed:
Ubuntu Core 16 images using cloud-init fail to function when the
DataSource is over the network (Like OpenStack) as ne
Xenial fixes:
https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?h=ubuntu-xenial&id=aeff48d716
https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?h=ubuntu-xenial&id=310753a6
** Changed in: systemd (Ubuntu Xenial)
Status: Triaged => In Progress
--
You recei
** Description changed:
Ubuntu Core 16 images using cloud-init fail to function when the
DataSource is over the network (Like OpenStack) as networking is not yet
available when cloud-init.service runs.
cloud-init service unit deps look like this:
[Unit]
Description=Initial cloud-
** Description changed:
Ubuntu Core 16 images using cloud-init fail to function when the
DataSource is over the network (Like OpenStack) as networking is not yet
available when cloud-init.service runs.
cloud-init service unit deps look like this:
[Unit]
Description=Initial cloud-
I just landed the last PR (https://github.com/systemd/systemd/pull/4710)
in upstreamd master that fully fixes networkd for early boot. The
complete set is too intrusive to backport, but we don't need to in
xenial: Transient (DHCP-acquired) hostname and timezone have never
worked in xenial, and it s
** Changed in: systemd (Ubuntu)
Status: Triaged => In Progress
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1636912
Title:
systemd-networkd runs too late for cloud-init.service (net)
To man
@Martin: Okay sorry, I'm pretty new in this world.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1636912
Title:
systemd-networkd runs too late for cloud-init.service (net)
To manage notifications a
@Kristian: Whatever problem you have, it can almost certainly not be
this one. This is a "future feature" for xenial. I suggest to report a
new bug with details.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.ne
Hi,
Can we get some attention to this? We are unable to use Xenial, since
the instance boots up without a default gateway. Not sure if we are hit
harder because we are using vmware as hypervisor, but should not be a
problem since Trusty works fine.
--
You received this bug notification because y
** Merge proposal linked:
https://code.launchpad.net/~daniel-thewatkins/cloud-init/+git/cloud-init/+merge/311163
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1636912
Title:
systemd-networkd run
** Changed in: cloud-init (Ubuntu)
Status: Fix Released => Triaged
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1636912
Title:
systemd-networkd runs too late for cloud-init.service (net)
To
** Changed in: cloud-init (Ubuntu Xenial)
Status: New => Confirmed
** Changed in: cloud-init (Ubuntu Xenial)
Importance: Undecided => Medium
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/163
Dropping the After=dbus.service isn't regression free after all -- if
networkd starts before dbus.service, then you will lose networkd's D-Bus
control interface. So it seems either of
https://bugs.freedesktop.org/show_bug.cgi?id=98254 or
https://github.com/systemd/systemd/issues/4504 is necessary a
** Changed in: systemd (Ubuntu Xenial)
Status: In Progress => Triaged
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1636912
Title:
systemd-networkd runs too late for cloud-init.service (net)
This bug was fixed in the package cloud-init -
0.7.8-45-g584b843-0ubuntu1
---
cloud-init (0.7.8-45-g584b843-0ubuntu1) zesty; urgency=medium
* New upstream snapshot.
- pep8: fix style errors reported by pycodestyle 2.1.0 [Scott Moser]
- systemd: drop both Wants and After loca
UseHostname: is currently broken anyway
(https://github.com/systemd/systemd/issues/4646), so letting networkd
start earlier than dbus.service does not actually regress anything for
now. This will be different once #4646 gets fixed, as then this will
break functionality.
** Bug watch added: github.
** Merge proposal linked:
https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/310547
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1636912
Title:
systemd-networkd runs too late f
I've added a MP for some doc on cloud-init boot and what it is trying to
accomplish at
https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/310386
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad
For the record: the "hang" was the ~ 10s timeout for IPv6 RA. I was
testing with Yakkety/Zesty's QEMU whose "user" net has a builtin RA (you
get an fec0::* address), while xenial's doesn't.
We enable RA (on the client side) by default, and IMHO should really do
so -- selling a new solution in 2016
> I did play with it, but the networkd in xenial blocks for some non-trivial
> amount of time (10s of seconds) if dbus.service is not up.
I cannot reproduce this. I removed /etc/network/interface*, created
$ cat /etc/systemd/network/ens3.network
[Match]
Name=e*
[Network]
DHCP=yes
then dropped
Steve Langasek [2016-10-29 4:38 -]:
> cloud-init does not *require* you to be online. It *requires* you to
> provide a data source
Yes, I know, that's exactly my point -- by design it should/does not
require you to be online, but by making it wait for
s-n-wait-online.target or network-online
Ryan Harper [2016-10-28 18:46 -]:
> netplan generator only emits the "systemd-networkd" target wants, so
> if we use After=systemd-networkd-wait-online; that's never run since
> nothing wants it.
Right, if you want it, you need to pull it in yourself.
> If we add it explicitly, then it runs e
On Fri, Oct 28, 2016 at 06:46:07PM -, Ryan Harper wrote:
> > > we really want something like
> > > After=networking|networkd-wait-online
> > > which handles determining if networkd was supposed to run or not
> > That already exists, it's network-online.target -- whatever "implements"
> > it (
On Fri, Oct 28, 2016 at 06:02:29PM -, Martin Pitt wrote:
> > However, if there isn't a local seed, then we must search again *once*
> networking is up.
> But this "if there isn't a local seed" isn't something you can express as
> a static condition, hence my thought that it might be better if
On Fri, Oct 28, 2016 at 1:02 PM, Martin Pitt
wrote:
> > However, if there isn't a local seed, then we must search again *once*
> networking is up.
>
> Fair enough, but you can then of course not use that unit to configure
> the network.
Of course we can. We need to cycle the network though.
> However, if there isn't a local seed, then we must search again *once*
networking is up.
Fair enough, but you can then of course not use that unit to configure
the network. But this "if there isn't a local seed" isn't something you
can express as a static condition, hence my thought that it migh
** Changed in: systemd
Status: Unknown => New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1636912
Title:
systemd-networkd runs too late for cloud-init.service (net)
To manage notifications
On Thu, Oct 27, 2016 at 3:57 PM, Martin Pitt
wrote:
> > cloud-init expects networking to be up, like 'networking.service'
> before it runs..
>
>
> It seems to me that this might have to be split into two parts then -- one
> that can provide network config which runs early and does not require
> n
On Thu, Oct 27, 2016 at 3:57 PM, Martin Pitt
wrote:
> > cloud-init expects networking to be up, like 'networking.service'
> before it runs..
>
>
> I think it needs to make up its mind -- why does it want to run
> Before=network-online.target then? I thought the idea was that cloud-init
> is able
> cloud-init expects networking to be up, like 'networking.service'
before it runs..
I think it needs to make up its mind -- why does it want to run
Before=network-online.target then? I thought the idea was that cloud-init is
able to *provide* a network configuration (through the YAML). It seem
> Ubuntu Core 16 has explicitly seeded libnss-resolve in their image
Eek -- this was most definitively not intended. resolved still has
quirks in 231 (plus a lot of backported patches), it's not even remotely
ready in xenial's 229.
> Martin, I don't suppose the snappy team talked to you before se
On Thu, Oct 27, 2016 at 2:50 PM, Martin Pitt
wrote:
> > oddly though when using the ifupdown 'networking.service'; we don't
> need to use that target.
>
> Yes, that's a Type=oneshot, as it just calls "ifup -a". So that's more
> or less equivalent to s-n-wait-online --timeout=30 or After=s-n-wait-
On Thu, Oct 27, 2016 at 01:43:05PM -, Ryan Harper wrote:
> without resolved in 16.04 though the change isn't strictly needed but to
> keep the backported branch closer to trunk, I would expect those to come
> in.
Except it's not correct that we don't have resolved in 16.04. We're not
using r
> I really want to avoid having different cloud-init in any of
xenial/yakkety/zesty.
Me too, and I don't see why this would be conceptually required? 'After
=systemd-networkd.service" is appropriate in all releases (as that's
what you intend to do), after (!) we drop the After=dbus.service from
ne
Oct 27 19:22:27 localhost.localdomain systemd[1]: writable.mount: Unit is bound
to inactive unit dev-vda3.device. Stopping, too.
Oct 27 19:22:27 localhost.localdomain systemd[1]: systemd-networkd.service:
Found ordering cycle on systemd-networkd.service/start
Oct 27 19:22:27 localhost.localdomain
It appears that the networkd in Xenial is sensitive to dbus service
being available; it times out a bit waiting for dbus before continuing;
this is the delay.
If I drop cloud-init.service 'Before=dbus.socket' and
'Before=basic.target'; Add 'After=systemd-networkd-wait-online.service';
then ensure
networkd bringing up eth0 (virtio) on qemu user-net is taking like 40
seconds... why?
root@localhost:~# journalctl --unit systemd-networkd.service | egrep
"(Started|Configured)"
Oct 27 16:31:59 localhost.localdomain systemd[1]: Started Network Service.
Oct 27 16:32:32 localhost.localdomain system
On Thu, Oct 27, 2016 at 8:43 AM, Ryan Harper
wrote:
>
>
> On Thu, Oct 27, 2016 at 5:59 AM, Martin Pitt
> wrote:
>
>> So did I understand this right:
>>
>> * In current xenial, cloud-init runs in late boot, so there is no
>> principal ordering problem between cloud-init and networkd, other than
I really want to avoid having different cloud-init in any of
xenial/yakkety/zesty.
I'm willing to carry a patch, and more so if we believe it to just be a
temporary thing, but its less than ideal. The goal is to have one
cloud-init on each. I realize maybe that is to idealistic for reality,
so i
On Thu, Oct 27, 2016 at 5:59 AM, Martin Pitt
wrote:
> So did I understand this right:
>
> * In current xenial, cloud-init runs in late boot, so there is no
> principal ordering problem between cloud-init and networkd, other than
> that cloud-init.service should declare After=systemd-networkd.ser
** Bug watch added: github.com/systemd/systemd/issues #4504
https://github.com/systemd/systemd/issues/4504
** Also affects: systemd via
https://github.com/systemd/systemd/issues/4504
Importance: Unknown
Status: Unknown
--
You received this bug notification because you are a membe
The "networkd after D-Bus" ordering was introduced in
https://github.com/systemd/systemd/commit/1346b1f038 and later refined
in https://github.com/systemd/systemd/commit/bcbca8291f .
So with the latter, removing this ordering would break the "UseHostname:
yes" flag (when you receive/set your host
So did I understand this right:
* In current xenial, cloud-init runs in late boot, so there is no
principal ordering problem between cloud-init and networkd, other than
that cloud-init.service should declare After=systemd-networkd.service
similar to what it does for ifupdown (After=networking.ser
@Steve:
> There's feedback in the end of that bug that cloud-init should *not*
be using Before=basic.target / Before=dbus.socket, but instead use
Before=sysinit.target.
Correct, that would avoid starting it in between sysinit.target and
basic.target when the sockets start, and avoid the deadlock
On Wed, Oct 26, 2016 at 6:41 PM, Steve Langasek <
steve.langa...@canonical.com> wrote:
> Note that the systemd dependencies shown for cloud-init in xenial (on
> which Ubuntu Core 16 is based) don't match those listed in the bug
> description. Instead, xenial currently has:
>
> After=cloud-init-lo
Note that the systemd dependencies shown for cloud-init in xenial (on
which Ubuntu Core 16 is based) don't match those listed in the bug
description. Instead, xenial currently has:
After=cloud-init-local.service networking.service
Before=network-online.target sshd.service sshd-keygen.service
sys
** Changed in: systemd (Ubuntu)
Importance: Undecided => High
** Changed in: systemd (Ubuntu)
Assignee: (unassigned) => Martin Pitt (pitti)
** Changed in: cloud-init (Ubuntu)
Assignee: (unassigned) => Martin Pitt (pitti)
** Changed in: cloud-init (Ubuntu)
Importance: Undecided =>
cloud-init already has *very* strong dependencies:
Requires=networking.service
Before=basic.target
(which is sorting the early boot fairly strictly). But I guess in the
same vein, if cloud-init wants to run in between networkd and
basic.target, it needs to grow an After=systemd-networkd.servi
87 matches
Mail list logo
