We discussed this on IRC in #ubuntu-release and agreed on the following
plan of action:
0. cyphermox has uploaded open-iscsi to xenial and yakkety
1. rbasak will review open-iscsi (only) for acceptance into
{xenial,yakkety}-proposed. Go back to step 0 for diff changes as needed, but
there are no other blockers on the bug or on initramfs-tools or isc-dhcp
2. Nobody will upload isc-dhcp or initramfs-tools to the SRU queues in relation
to this issue until open-iscsi finishes the SRU process in the usual way. Other
unrelated SRUs to isc-dhcp and initramfs-tools are unaffected.
3. cyphermox will get consensus on the diffs for isc-dhcp and initramfs-tools
4. smoser will review and +1 the diffs (else go back to 3)
5. cypermox will upload isc-dhcp and initramfs-tools together to the xenial and
yakkety queues for SRU processing in the usual way
This assumes that:
* Nobody has an objection to the current open-iscsi diff
* Nobody expects the open-iscsi diff to need to change based on the conclusion
of the changes to be made to isc-dhcp and initramfs-tools
[rbasak] IMHO, the open-iscsi change seems straightforward enough to not
be as concerned about regressions as I am with the previous initramfs-
tools regression. So I think it's OK that open-iscsi dep8 is currently
failing in Zesty. We can check to see that it passes in Xenial and
Yakkety before releasing to -updates. I would still expect future
initramfs-tools and isc-dhcp SRUs to be well tested in the development
release, however.
There is a whitespace indetation inconsistency in the diff, but this
went into zesty-proposed as well, and would create diff noise when
comparing that. The mistake's been made, so I'll leave it as is.
Similarly, the whitespace change dropping an extra space in an if
statement shouldn't really be part of the SRU, but I'll leave it as-is
in order to make progress.
** Changed in: open-iscsi (Ubuntu Yakkety)
Status: In Progress => Fix Committed
** Tags removed: verification-failed
** Tags added: verification-needed
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu.
https://bugs.launchpad.net/bugs/1621507
Title:
initramfs-tools configure_networking() fails to dhcp ipv6 addresses
Status in MAAS:
Fix Committed
Status in initramfs-tools package in Ubuntu:
In Progress
Status in isc-dhcp package in Ubuntu:
In Progress
Status in klibc package in Ubuntu:
Won't Fix
Status in open-iscsi package in Ubuntu:
In Progress
Status in initramfs-tools source package in Xenial:
Triaged
Status in isc-dhcp source package in Xenial:
In Progress
Status in klibc source package in Xenial:
Won't Fix
Status in open-iscsi source package in Xenial:
Fix Committed
Status in initramfs-tools source package in Yakkety:
In Progress
Status in isc-dhcp source package in Yakkety:
In Progress
Status in klibc source package in Yakkety:
Won't Fix
Status in open-iscsi source package in Yakkety:
Fix Committed
Status in klibc package in Debian:
New
Bug description:
initramfs' configure_networking function uses ipconfig to configure the
network.
ipconfig does not support dhcpv6. See:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=627164
Related bugs:
* bug 1229458: grub2 needed changes
* bug 1621615: network not configured when ipv6 netbooted into cloud-init
* bug 1635716: Can't bring up a machine on a dual network (ipv4 and ipv6)
[Impact]
It is not possible to netboot Ubuntu with a network-based root
filesystem in an ipv6-only environment. Anyone wanting to netboot in
an ipv6-only environment is affected.
These uploads address this by replacing the one-off klibc dhcp client
(IPv4-only) with the defacto standard isc-dhcp-client, and thereby
provide both ipv6 and ipv4 DHCP configuration.
[Test Case]
See Bug 1229458. Configure radvd, dhcpd, and tftpd for your ipv6-only
netbooting world. Pass the boot process an ipv6 address to talk to,
and see it fail to configure the network.
[Regression Potential]
1) This increases the uncompressed initramfs size by approximately 500KB,
since isc-dhcp-client is added, but klibc is still needed for some other
things, and is therefore present. On systems with a very small /boot
partition, this could result in failure to upgrade the initramfs.
2) In at least some cases, DHCP network configuration shifts from klibc's
ipconfig to isc-dhcp-client's dhclient. This should be of minimal risk, as
isc-dhcp-client is in very very widespread use. In the event of a regression,
network boot would fail, but the prior kernel should still be bootable.
To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1621507/+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
