ip= static ip configuration doesn't persist

[Dimitri John Ledkov]

I specified static ip configuration, on a vlan device using ip= & vlan= kernel command-lines.

Unfortunately, that didn't quite persist into the running system and instead dhcp was performed on the underlying (non-vlan) device.

Whilst that was successful, it was unexpected, and that one is internal firewalled network that doesn't actually grant any useful internets.

ip= vlan= network config should be honored, and should persist on the networking page.

[Michael Hudson-Doyle (mwhudson)]

Hmm, there are two things here. One is that it's not really surprising on reflection that DHCP is attempted on the underlying interface -- there is netplan in filesystem.squashfs that says it should be, after all. This is between the initramfs and netplan I think, subiquity isn't involved. Maybe the initramfs should mask any netplan in filesystem.squashfs when it is explicitly doing network config?

The other part is the vlan interface not being present in the installer. There is this code:

        for typ, key in ('vlan', 'vlans'), ('bond', 'bonds'):
            network = self.config.config.get('network', {})
            for name, config in network.get(key, {}).items():
                dev = self.devices_by_name.get(name)
                if dev is None:
                    dev = self.devices_by_name[name] = NetworkDev(
                        self, name, typ)
                # XXX What to do if types don't match??
                dev.config = config

but by my reading self.config.config is only the last yaml file that was read, which is bogus and probably where this is going wrong.

[Dimitri John Ledkov (xnox)]

So if i remove the stock installer yaml from initramfs, everything appears to work correctly.

[Michael Hudson-Doyle (mwhudson)]

Is there a chance we can just switch to cloud-init's default behaviour for networking and everything will work out ok?

We still need to fix that thing about self.config.config only being the most recently read config though.

[Dimitri John Ledkov (xnox)]

I'm not sure cloud-init's default behavior for networking will help here at all.

At the moment I need networking up in the initrd, and for it to persist. Or do you mean I should look into cloud-utils-initramfs to make a baby again with casper?!

To me, it seemed like if there are two interfaces, and both manage to dhcp, there is no way in subiquity to pick which one should own the default route. Cause obviously one interface is DMZ and doesn't give internets, and the other one is the one that gives you internets.

[Dimitri John Ledkov (xnox)]

(in my case vlan is internet, and dhcp on the underlying inteface is a tiny dmz network without any access to anything useful and that one ends up owning default route)

[Dimitri John Ledkov (xnox)]

Should I provide things to simulate this scenario as an example machine config with matching netplan files?

[Michael Hudson-Doyle (mwhudson)]

On Tue, 8 Oct 2019 at 11:30, Dimitri John Ledkov <email address hidden>
wrote:

> I'm not sure cloud-init's default behavior for networking will help here
> at all.
>

All I know is that cloud-init does have code for inspecting the
/run/net-*.conf files and has some kind of default behaviour for doing
dhcp. I don't know if all the pieces interact together nicely (e.g. if
there is a net-*.conf file that indicates networking, does it not do the
dhcp by default?).

To be clear, when I say "use cloud-init's default behavior" I mean removing
the netplan we currently have in the filesystem.squashfs (and having
cloud-init run in the live environment).

> At the moment I need networking up in the initrd, and for it to persist.
> Or do you mean I should look into cloud-utils-initramfs to make a baby
> again with casper?!
>

No, that's not what I meant.

> To me, it seemed like if there are two interfaces, and both manage to
> dhcp, there is no way in subiquity to pick which one should own the
> default route. Cause obviously one interface is DMZ and doesn't give
> internets, and the other one is the one that gives you internets.
>

 It seems to me that if the tiny DMZ does not give access to anything
useful, it's DHCP server should not be handing out a default route. In any
case, there is no "the default route", there can be a bunch of entries in
the routing table that take any address and the one that gets picked comes
down to route metrics. I have no idea which thing makes the call of which
of these two routes has the higher metric -- but I'm sure it's not
subiquity :)