Public bug reported:
I have been banging my head a bit with this one, especially as I am sure
it *used* to work although in theory it should never have done! I would
imagine a systemd update would have broken things.
I can't get cloud-init to configure the network when using `distro:
arch`. What seems to happen is this:
- systemd looks at current units/services to start and begins boot.
- cloud-init-local.service runs, mode in cmd/main.py is 'local'.
- init.apply_network_config happens with bringup=False.
- arch.py writes out a netctl config and enables it using netctl reenable
enp0s3.
- netctl creates a new systemd unit (netctl@enp0s3) and enables it
- systemd list of services already resolved, so does not start netctl@enp0s3
as it was created after the boot process started
So after the system is fully brought up, the interface is configured but
NOT started. A subsequent reboot makes the network become available.
A few things and thoughts:
- I tried making bringup=True by force but cloud-init-local is too early in
the boot process and netctl barfs when trying to do a restart on an interface
here.
- Debian and RHEL based seem to have their own ways of managing network that
involve putting files in a certain place that an *already existing* service
then comes along and processes later.
- Tried from "master" and from 0.7.9.tar.gz
I can't think of a way netctl could ever work with cloud-init. Possibly
using systemd-networkd instead would be wise but then things like
Vagrant and no doubt other "cloud" providers expect Arch to be using
netctl.
Thoughts? Ideas? Even a .patch so I can bodge something to work would be
a big help right now but everything I have tried fails for one reason or
another.
** Affects: cloud-init
Importance: Undecided
Status: New
** Description changed:
I have been banging my head a bit with this one, especially as I am sure
it *used* to work although in theory it should never have done! I would
imagine a systemd update would have broken things.
I can't get cloud-init to configure the network when using `distro:
arch`. What seems to happen is this:
- - systemd looks at current units/services to start and begins boot.
- - cloud-init-local.service runs, mode in cmd/main.py is 'local'.
- - init.apply_network_config happens with bringup=False.
- - arch.py writes out a netctl config and enables it using netctl reenable
enp0s3.
- - netctl creates a new systemd unit (netctl@enp0s3) and enables it
- - systemd list of services already resolved, so does not start
netctl@enp0s3 as it was created after the boot process started
+ - systemd looks at current units/services to start and begins boot.
+ - cloud-init-local.service runs, mode in cmd/main.py is 'local'.
+ - init.apply_network_config happens with bringup=False.
+ - arch.py writes out a netctl config and enables it using netctl reenable
enp0s3.
+ - netctl creates a new systemd unit (netctl@enp0s3) and enables it
+ - systemd list of services already resolved, so does not start
netctl@enp0s3 as it was created after the boot process started
So after the system is fully brought up, the interface is configured but
- NOT started. A subsequent reboot makes the system become available.
+ NOT started. A subsequent reboot makes the network become available.
A few things and thoughts:
- - I tried making bringup=True by force but cloud-init-local is too early in
the boot process and netctl barfs when trying to do a restart on an interface
here.
- - Debian and RHEL based seem to have their own ways of managing network
that involve putting files in a certain place that an *already existing*
service then comes along and processes later.
- - Tried from "master" and from 0.7.9.tar.gz
+ - I tried making bringup=True by force but cloud-init-local is too early in
the boot process and netctl barfs when trying to do a restart on an interface
here.
+ - Debian and RHEL based seem to have their own ways of managing network
that involve putting files in a certain place that an *already existing*
service then comes along and processes later.
+ - Tried from "master" and from 0.7.9.tar.gz
I can't think of a way netctl could ever work with cloud-init. Possibly
using systemd-networkd instead would be wise but then things like
Vagrant and no doubt other "cloud" providers expect Arch to be using
netctl.
Thoughts? Ideas? Even a .patch so I can bodge something to work would be
a big help right now but everything I have tried fails for one reason or
another.
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1714495
Title:
Archlinux Netctl Bringup
Status in cloud-init:
New
Bug description:
I have been banging my head a bit with this one, especially as I am
sure it *used* to work although in theory it should never have done! I
would imagine a systemd update would have broken things.
I can't get cloud-init to configure the network when using `distro:
arch`. What seems to happen is this:
- systemd looks at current units/services to start and begins boot.
- cloud-init-local.service runs, mode in cmd/main.py is 'local'.
- init.apply_network_config happens with bringup=False.
- arch.py writes out a netctl config and enables it using netctl reenable
enp0s3.
- netctl creates a new systemd unit (netctl@enp0s3) and enables it
- systemd list of services already resolved, so does not start
netctl@enp0s3 as it was created after the boot process started
So after the system is fully brought up, the interface is configured
but NOT started. A subsequent reboot makes the network become
available.
A few things and thoughts:
- I tried making bringup=True by force but cloud-init-local is too early in
the boot process and netctl barfs when trying to do a restart on an interface
here.
- Debian and RHEL based seem to have their own ways of managing network
that involve putting files in a certain place that an *already existing*
service then comes along and processes later.
- Tried from "master" and from 0.7.9.tar.gz
I can't think of a way netctl could ever work with cloud-init.
Possibly using systemd-networkd instead would be wise but then things
like Vagrant and no doubt other "cloud" providers expect Arch to be
using netctl.
Thoughts? Ideas? Even a .patch so I can bodge something to work would
be a big help right now but everything I have tried fails for one
reason or another.
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1714495/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
