Unfortunately, the old configuration is re-applied. This is because the initial value of user.network-config was written to /var/lib/cloud/seed/nocloud-net/network-config inside the container, and it has not been updated with the new value of the user.network-config property.
If I do cloud-init clean --seed then the whole /var/lib/cloud/seed/ subtree is deleted, but it’s not recreated when the container restarts.
Is there a way to get lxd to refresh the contents of /var/lib/cloud/seed/nocloud-net/ on an existing container from the user.* properties?
Doing cloud-init clean --seed in the container followed by:
lxc stop NAME
lxc config set NAME volatile.apply_template create
lxc start NAME
Should do the trick. This will cause both cloud-init to wipe its state and instruct LXD to re-run the templates that would normally only be run on the container’s first boot after creation.
Where trixie is an alias to debian/13/cloud.
I can’t get it to let go of that address. It picks it up regardless of what is in /etc/network/interfaces or the containers configuration.
I can make an entirely new image but I would rather update the existing configured system to on the new ip address. It seems to want to hold onto the ip it was initiated with.
I would also be fine with being able to remove the cloud init all together and use a static interfaces style configuration.
Since most of my systems are statically defined on a /27 cloud init does just fine (until it doesn’t and we wind up here). I had been using netplan on ubuntu for years before canonical managed to make that less reliable and I just went old school /etc/network/interfaces. Debian out of the box these days favors nmcli (network manager ) which is a convoluted pile if I ever saw one. So I would prefer to just use the cloud image out of the box. But thank you.
The –configs flag was what I was missing Thank you!
root@tk2022:~# incus config edit ezra
root@tk2022:~# incus exec ezra -- cloud-init clean --seed --logs --configs network
root@tk2022:~# incus stop ezra
root@tk2022:~# incus config set ezra volatile.apply_template=create
root@tk2022:~# incus start ezra
root@tk2022:~# incus exec ezra -- cloud-init status --wait
.........................................................................................................................................................................................................................status: error
(....not really an error profile has a reboot in it....)
root@tk2022:~# incus exec ezra -- cloud-init status --wait
Error: Instance is not running
root@tk2022:~# incus exec ezra -- cloud-init status --wait
...........................................................................................................................................................................................................................................................................................................................................................................................................................................status: done
root@tk2022:~# incus list
+-----------+---------+------------------------------+------+-----------+-----------+
| NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |
+-----------+---------+------------------------------+------+-----------+-----------+
.... other stuff ....
-----+
| ezra | RUNNING | 69.41.138.102 (eth0) | | CONTAINER | 2 |
+-----------+---------+------------------------------+------+-----------+-----------+
It doesn’t configure the internal interface. Which I am curious about but the public facing is fixed and I can receive email again. As always this group of people are spot on and helpful. Thank you again.
So…. Since the above only seems to have configured the installed interface and ifupdown was required to configure both interfaces I believe that the right thing to do would be to delete cloud-init.network-config from the container and do the steps above. As described here. Again thank you for the help.
What do you mean by “the installed interface”? If I create a container with two interfaces (eth0/eth1), and I provide network-config with both eth0 and eth1, it works for me. (*)
I don’t know what you mean by “delete cloud-init.network-config from the container”. Do you mean to unset this incus setting? In that case cloud-init gets no network config information when it next runs. Or do you mean removing something from inside the container, in which case, what?
(Aside: cloud-init runs certain parts on first boot only, and certain parts on every boot. I think the network configuration is on every boot. If you don’t provide any network config, I think it will do some default like configure eth0 with DHCP, but I’ve not tested this)
I also see no need to install ifupdown2. Without it, Debian uses systemd-networkd, and cloud-init writes configs under /etc/systemd/network, and this all just works.
This is what I meant by “please provide an actual reproducer”: a series of steps that anyone else can follow, which demonstrates the issue you are talking about. Using the above steps, I cannot find any problem with debian 13 + cloud-init + multiple network interfaces.
If you do have a problem, it probably means you’re doing something slightly different.
When I tried both interfaces as above it didn’t work. So I must have missed something.
I was working on a functioning server as part of a larger process so I didn’t do a lot of POCing.
You pointed me in the right direction and I was able to get it working. I will lab this more later.
Again, thank you.
) which is a convoluted pile if I ever saw one. So I would prefer to just use the cloud image out of the box. But thank you.