Public bug reported:
static ip= address configuration does not end up in netplan file
klibc ipconfig process ip=...:$proto and dumps the state into a file,
which is then parsed to generate runtime netplan configs.
For static ip configuration ipconfig parses $proto values "off" "none"
"static" as the same PROTO_NONE and encodes it as PROTO="none" in the
serialized state file.
The function that dumps ip data (_declare_ip_info()) has keys only
values for dhcp dhcp4 dhcp6 static. But not "none" (used by ipconfig) or
"off" (as valid by the kernel).
This means that netplan files generated in /run for static ip
configuration are incomplete.
Imho we should accept "off" "none" "static" as all valid PROTO settings
for static ip configuration.
[Impact]
* `netplan apply` will not reapply static ip configuration as declared
in ip= kernel cmdline.
[Test Case]
* boot with static ip configuration in the kernel cmdline, e.g.
ip=10.245.232.12::10.245.232.1:255.255.255.255:clound01:enc603:none
Check that /run/netplan/*.yaml contains addresses stanzas.
[Regression Potential]
* Runtime netplan configuration will now be more complete. Meaning that
static ip addresses will now persist across `netplan apply` / downing,
and reupping an interface. Whilst it was intended for static ip
addresses to be there, it might be unexpected that they actually work
properly now.
** Affects: initramfs-tools (Ubuntu)
Importance: Undecided
Status: New
** Affects: initramfs-tools (Ubuntu Xenial)
Importance: Undecided
Status: New
** Affects: initramfs-tools (Ubuntu Bionic)
Importance: Undecided
Status: New
** Affects: initramfs-tools (Ubuntu Cosmic)
Importance: Undecided
Status: New
** Affects: initramfs-tools (Ubuntu Disco)
Importance: Undecided
Status: New
** Affects: initramfs-tools (Ubuntu Eoan)
Importance: Undecided
Status: New
** Also affects: initramfs-tools (Ubuntu Eoan)
Importance: Undecided
Status: New
** Also affects: initramfs-tools (Ubuntu Xenial)
Importance: Undecided
Status: New
** Also affects: initramfs-tools (Ubuntu Bionic)
Importance: Undecided
Status: New
** Also affects: initramfs-tools (Ubuntu Disco)
Importance: Undecided
Status: New
** Also affects: initramfs-tools (Ubuntu Cosmic)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1832042
Title:
static ip= address configuration does not end up in netplan file
Status in initramfs-tools package in Ubuntu:
New
Status in initramfs-tools source package in Xenial:
New
Status in initramfs-tools source package in Bionic:
New
Status in initramfs-tools source package in Cosmic:
New
Status in initramfs-tools source package in Disco:
New
Status in initramfs-tools source package in Eoan:
New
Bug description:
static ip= address configuration does not end up in netplan file
klibc ipconfig process ip=...:$proto and dumps the state into a file,
which is then parsed to generate runtime netplan configs.
For static ip configuration ipconfig parses $proto values "off" "none"
"static" as the same PROTO_NONE and encodes it as PROTO="none" in the
serialized state file.
The function that dumps ip data (_declare_ip_info()) has keys only
values for dhcp dhcp4 dhcp6 static. But not "none" (used by ipconfig)
or "off" (as valid by the kernel).
This means that netplan files generated in /run for static ip
configuration are incomplete.
Imho we should accept "off" "none" "static" as all valid PROTO
settings for static ip configuration.
[Impact]
* `netplan apply` will not reapply static ip configuration as
declared in ip= kernel cmdline.
[Test Case]
* boot with static ip configuration in the kernel cmdline, e.g.
ip=10.245.232.12::10.245.232.1:255.255.255.255:clound01:enc603:none
Check that /run/netplan/*.yaml contains addresses stanzas.
[Regression Potential]
* Runtime netplan configuration will now be more complete. Meaning
that static ip addresses will now persist across `netplan apply` /
downing, and reupping an interface. Whilst it was intended for static
ip addresses to be there, it might be unexpected that they actually
work properly now.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1832042/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
