Hi!

I created a Devuan image for my Linux trainings.

On Devuan Ascii with ancient cloud-init '0.7.9-2' I have an issue with
initial network configuration after cloning VMs. I use Proxmox VE.

On the first boot cloud-init is supposed to configure the network. However
it does so *after* '/etc/init.d/networking' initialized the network
already and thus I see the old IP address of the template on 'eth0'.

Now changing '/etc/init.d/networking' to require 'cloud-init' would
introduce a loop as cloud-init can require networking to be present in
case the configuration source comes from the network (here it is a cloud-
init cidata iso provived by Proxmox VE).

I bet eventually this is just a bug in cloud-init. Or well I'd need the
clean up the template. I believe the '/e/n/i' network configuration
output of 'cloud-init' should nuke the file in '/e/n/interfaces.d' before
'/etc/init.d/networking' is run. I would not report an issue before
switching to next Devuan release tough, as the 'cloud-init' version is
just very old.

As a work-around I have

/etc/init.d/networking stop
ip addr flush eth0
/etc/init.d/networking start

in '/etc/rc.local'.

This is not optimal cause on initial boot there is a chance of duplicate
IP address. The template with the original IP address is stopped before
the cloning process. But depending on the speed of the hypervisor, it
may be that two cloned VMs boot at almost the same time. As this conflict
should be short and only on initial boot I bet I can live with that. Of
course I could introduce a delay in my cloning script, but that is
adding work-around upon work-around.

Any other ideas for a work-around that does not have a chance to create
a short time period with duplicate IP addresses?

I am not yet sure why this works okayish with Systemd cause cloud-init
service in run after 'After=networking.service' as well.

Thanks,
--
Martin