[Touch-packages] [Bug 1683911] [NEW] ifup places illegally named variables into the environment

[LaMont Jones]

Public bug reported:

When dhclient brings up interface eth0.55, the environment passed to scripts 
includes:
IFUPDOWN_eth0=parent-lock
IFUPDOWN_eth0.55=post-up
IFACE=eth0.55
LOGICAL=eth0.55
ADDRFAM=inet
METHOD=dhcp
MODE=start
PHASE=post-up
VERBOSITY=0
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

IFUPDOWN_eth0.55 is not a valid name for an environment variable.

** Affects: ifupdown (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ifupdown in Ubuntu.
https://bugs.launchpad.net/bugs/1683911

Title:
  ifup places illegally named variables into the environment

Status in ifupdown package in Ubuntu:
  New

Bug description:
  When dhclient brings up interface eth0.55, the environment passed to scripts 
includes:
  IFUPDOWN_eth0=parent-lock
  IFUPDOWN_eth0.55=post-up
  IFACE=eth0.55
  LOGICAL=eth0.55
  ADDRFAM=inet
  METHOD=dhcp
  MODE=start
  PHASE=post-up
  VERBOSITY=0
  PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

  IFUPDOWN_eth0.55 is not a valid name for an environment variable.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1683911/+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

[Touch-packages] [Bug 1408106] Re: attach_disconnected not sufficient for overlayfs

[LaMont Jones]

This bug causes maas testing to fail (at least the ntp test, because of
overlayfs and apparmor and ntp having a profile.) See
https://bugs.launchpad.net/maas/+bug/1677336

Hardware testing is a requirement for MAAS 2.2.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1408106

Title:
  attach_disconnected not sufficient for overlayfs

Status in AppArmor:
  In Progress
Status in MAAS:
  New
Status in apparmor package in Ubuntu:
  Confirmed
Status in linux package in Ubuntu:
  Triaged

Bug description:
  With the following use of overlayfs, we get a disconnected path:

  $ cat ./profile
  #include 
  profile foo {
    #include 

    capability sys_admin,
    capability sys_chroot,
    mount,
    pivot_root,
  }

  $ cat ./overlay.c
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 

  int main(int argc, char* argv[]) {
  int i = 0;
  int len = 0;
  int ret = 0;
  char* options;

  if (geteuid())
  unshare(CLONE_NEWUSER);
  unshare(CLONE_NEWNS);

  for (i = 1; i < argc; i++) {
  if (i == 1) {
  len = strlen(argv[i]) + strlen("upperdir=,lowerdir=/") + 2;
  options = alloca(len);
  ret = snprintf(options, len, "upperdir=%s,lowerdir=/", argv[i]);
  }
  else {
  len = strlen(argv[i]) + strlen("upperdir=,lowerdir=/mnt") + 2;
  options = alloca(len);
  ret = snprintf(options, len, "upperdir=%s,lowerdir=/mnt", 
argv[i]);
  }

  mount("overlayfs", "/mnt", "overlayfs", MS_MGC_VAL, options);
  }

  chdir("/mnt");
  pivot_root(".", ".");
  chroot(".");

  chdir("/");
  execl("/bin/bash", "/bin/bash", NULL);
  }

  $ sudo apparmor_parser -r ./profile && aa-exec -p foo -- ./a.out /tmp
  [255]
  ...
  Dec 12 14:31:38 localhost kernel: [57278.040216] audit: type=1400 
audit(1418387498.613:712): apparmor="DENIED" operation="exec" info="Failed name 
lookup - disconnected path" error=-13 profile="foo" name="/bin/bash" pid=18255 
comm="a.out" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0

  With the above, the expectation was for the denial to be /mnt/bin/bash. There 
are three ways forward:
  1. the correct solution is to patch overlayfs to properly track the loopback, 
but this will take a while, may ultimately be unachievable. UPDATE: upstream is 
currently working on this and Ubuntu will engage with them
  2. we could rely on the fact that overlayfs creates a private unshared 
submount, and provide a way to not mediate the path when that is present, and 
tagged. This would take a bit of time, and might be the preferred method over 1 
longer term
  3. we could extend attach_disconnected so that we can define the attach root. 
Eg, we can use profile foo (attach_disconnected=/mnt) {} such that '/bin/bash' 
maps to '/mnt/bin/bash'. UPDATE: THIS IS NOT VIABLE

To manage notifications about this bug go to:
https://bugs.launchpad.net/apparmor/+bug/1408106/+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

[Touch-packages] [Bug 1408106] Re: attach_disconnected not sufficient for overlayfs

[LaMont Jones]

** Also affects: maas
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1408106

Title:
  attach_disconnected not sufficient for overlayfs

Status in AppArmor:
  In Progress
Status in MAAS:
  New
Status in apparmor package in Ubuntu:
  Confirmed
Status in linux package in Ubuntu:
  Triaged

Bug description:
  With the following use of overlayfs, we get a disconnected path:

  $ cat ./profile
  #include 
  profile foo {
    #include 

    capability sys_admin,
    capability sys_chroot,
    mount,
    pivot_root,
  }

  $ cat ./overlay.c
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 

  int main(int argc, char* argv[]) {
  int i = 0;
  int len = 0;
  int ret = 0;
  char* options;

  if (geteuid())
  unshare(CLONE_NEWUSER);
  unshare(CLONE_NEWNS);

  for (i = 1; i < argc; i++) {
  if (i == 1) {
  len = strlen(argv[i]) + strlen("upperdir=,lowerdir=/") + 2;
  options = alloca(len);
  ret = snprintf(options, len, "upperdir=%s,lowerdir=/", argv[i]);
  }
  else {
  len = strlen(argv[i]) + strlen("upperdir=,lowerdir=/mnt") + 2;
  options = alloca(len);
  ret = snprintf(options, len, "upperdir=%s,lowerdir=/mnt", 
argv[i]);
  }

  mount("overlayfs", "/mnt", "overlayfs", MS_MGC_VAL, options);
  }

  chdir("/mnt");
  pivot_root(".", ".");
  chroot(".");

  chdir("/");
  execl("/bin/bash", "/bin/bash", NULL);
  }

  $ sudo apparmor_parser -r ./profile && aa-exec -p foo -- ./a.out /tmp
  [255]
  ...
  Dec 12 14:31:38 localhost kernel: [57278.040216] audit: type=1400 
audit(1418387498.613:712): apparmor="DENIED" operation="exec" info="Failed name 
lookup - disconnected path" error=-13 profile="foo" name="/bin/bash" pid=18255 
comm="a.out" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0

  With the above, the expectation was for the denial to be /mnt/bin/bash. There 
are three ways forward:
  1. the correct solution is to patch overlayfs to properly track the loopback, 
but this will take a while, may ultimately be unachievable. UPDATE: upstream is 
currently working on this and Ubuntu will engage with them
  2. we could rely on the fact that overlayfs creates a private unshared 
submount, and provide a way to not mediate the path when that is present, and 
tagged. This would take a bit of time, and might be the preferred method over 1 
longer term
  3. we could extend attach_disconnected so that we can define the attach root. 
Eg, we can use profile foo (attach_disconnected=/mnt) {} such that '/bin/bash' 
maps to '/mnt/bin/bash'. UPDATE: THIS IS NOT VIABLE

To manage notifications about this bug go to:
https://bugs.launchpad.net/apparmor/+bug/1408106/+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

[Touch-packages] [Bug 1661691] Re: TERM=xterm enables mouse mode in vi, breaks pasting with middle mouse

[LaMont Jones]

Also true when TERM=screen -- I suspect it doesn't care what terminal
you're using, if it can grab mouse events, it does.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to vim in Ubuntu.
https://bugs.launchpad.net/bugs/1661691

Title:
  TERM=xterm enables mouse mode in vi, breaks pasting with middle mouse

Status in vim package in Ubuntu:
  Confirmed

Bug description:
  I quite often have the following work flow:

  a.) lxc launch ubuntu-daily:zesty z1
  b.) lxc exec z1 /bin/bash
  c.) % vi foo.txt
  d.) paste some thing from my X buffer (hit middle mouse button).

  Somewhere between yakkety (2:7.4.1829-1ubuntu2.1) and zesty
  (2:8.0.0095-1ubuntu2) this behavior changed.

  Previously this all worked fine.

  Now, in zesty, however an attempt to paste results in a vi error message:
   E353: Nothing in register "

  to fix this, you can first disable the mouse 'a' [1]

   : set mouse-=a

  
  I'm not sure what is enabling this, because /usr/share/vim/vimrc has the line
  set mouse=a commented out.

  --
  [1] 
http://www.varesano.net/blog/fabio/disable%20vim%20automatic%20visual%20mode%20using%20mouse

  ProblemType: Bug
  DistroRelease: Ubuntu 17.04
  Package: vim-nox 2:8.0.0095-1ubuntu2
  ProcVersionSignature: Ubuntu 4.9.0-12.13-generic 4.9.2
  Uname: Linux 4.9.0-12-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl zcommon znvpair
  ApportVersion: 2.20.4-0ubuntu1
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Fri Feb  3 12:14:20 2017
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2015-07-23 (561 days ago)
  InstallationMedia: Ubuntu 15.10 "Wily Werewolf" - Alpha amd64 (20150722.1)
  SourcePackage: vim
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/vim/+bug/1661691/+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

[Touch-packages] [Bug 1661691] Re: TERM=xterm enables mouse mode in vi, breaks pasting with middle mouse

[LaMont Jones]

A very unexpected, and totally unwelcome change to vim.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to vim in Ubuntu.
https://bugs.launchpad.net/bugs/1661691

Title:
  TERM=xterm enables mouse mode in vi, breaks pasting with middle mouse

Status in vim package in Ubuntu:
  Confirmed

Bug description:
  I quite often have the following work flow:

  a.) lxc launch ubuntu-daily:zesty z1
  b.) lxc exec z1 /bin/bash
  c.) % vi foo.txt
  d.) paste some thing from my X buffer (hit middle mouse button).

  Somewhere between yakkety (2:7.4.1829-1ubuntu2.1) and zesty
  (2:8.0.0095-1ubuntu2) this behavior changed.

  Previously this all worked fine.

  Now, in zesty, however an attempt to paste results in a vi error message:
   E353: Nothing in register "

  to fix this, you can first disable the mouse 'a' [1]

   : set mouse-=a

  
  I'm not sure what is enabling this, because /usr/share/vim/vimrc has the line
  set mouse=a commented out.

  --
  [1] 
http://www.varesano.net/blog/fabio/disable%20vim%20automatic%20visual%20mode%20using%20mouse

  ProblemType: Bug
  DistroRelease: Ubuntu 17.04
  Package: vim-nox 2:8.0.0095-1ubuntu2
  ProcVersionSignature: Ubuntu 4.9.0-12.13-generic 4.9.2
  Uname: Linux 4.9.0-12-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl zcommon znvpair
  ApportVersion: 2.20.4-0ubuntu1
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Fri Feb  3 12:14:20 2017
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2015-07-23 (561 days ago)
  InstallationMedia: Ubuntu 15.10 "Wily Werewolf" - Alpha amd64 (20150722.1)
  SourcePackage: vim
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/vim/+bug/1661691/+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

[Touch-packages] [Bug 1640147] Re: [2.1] rsyslog is flooded with "no link-local IPv6 address for $IFACE" on commissioning

[LaMont Jones]

** Changed in: maas/2.1
   Status: New => In Progress

-- 
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/1640147

Title:
  [2.1] rsyslog is flooded with "no link-local IPv6 address for $IFACE"
  on commissioning

Status in MAAS:
  Fix Committed
Status in MAAS 2.1 series:
  In Progress
Status in isc-dhcp package in Ubuntu:
  Invalid

Bug description:
  When commissioning, /var/log/maas/rsyslog/ is flooded with the
  repeated messages below with over 30,000 lines.

  
  Nov  8 11:57:54 bunyip dhclient[4734]: no link-local IPv6 address for enp4s0f0
  Nov  8 11:57:54 bunyip dhclient[4734]: 
  Nov  8 11:57:54 bunyip dhclient[4734]: If you think you have received this 
message due to a bug rather
  Nov  8 11:57:54 bunyip dhclient[4734]: than a configuration issue please read 
the section on submitting
  Nov  8 11:57:54 bunyip dhclient[4734]: bugs on either our web page at 
www.isc.org or in the README file
  Nov  8 11:57:54 bunyip dhclient[4734]: before submitting a bug.  These pages 
explain the proper
  Nov  8 11:57:54 bunyip dhclient[4734]: process and the information we find 
helpful for debugging..
  Nov  8 11:57:54 bunyip dhclient[4734]: 
  Nov  8 11:57:54 bunyip dhclient[4734]: exiting.
  

  $ wc -l /var/log/maas/rsyslog/bunyip/2016-11-08/messages
  39278 /var/log/maas/rsyslog/bunyip/2016-11-08/messages

  It would be nice to suppress those lines if those could be safely
  ignored. It would make troubleshooting easier when something wrong
  happened on commissioning.

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1640147/+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

[Touch-packages] [Bug 1640147] Re: [2.1] rsyslog is flooded with "no link-local IPv6 address for $IFACE" on commissioning

[LaMont Jones]

** Also affects: maas/2.1
   Importance: Undecided
   Status: New

** Changed in: maas/2.1
Milestone: None => 2.1.4

** Changed in: maas/2.1
 Assignee: (unassigned) => LaMont Jones (lamont)

** Changed in: maas
 Assignee: (unassigned) => LaMont Jones (lamont)

** Changed in: maas
   Status: Triaged => In Progress

-- 
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/1640147

Title:
  [2.1] rsyslog is flooded with "no link-local IPv6 address for $IFACE"
  on commissioning

Status in MAAS:
  Fix Committed
Status in MAAS 2.1 series:
  New
Status in isc-dhcp package in Ubuntu:
  Invalid

Bug description:
  When commissioning, /var/log/maas/rsyslog/ is flooded with the
  repeated messages below with over 30,000 lines.

  
  Nov  8 11:57:54 bunyip dhclient[4734]: no link-local IPv6 address for enp4s0f0
  Nov  8 11:57:54 bunyip dhclient[4734]: 
  Nov  8 11:57:54 bunyip dhclient[4734]: If you think you have received this 
message due to a bug rather
  Nov  8 11:57:54 bunyip dhclient[4734]: than a configuration issue please read 
the section on submitting
  Nov  8 11:57:54 bunyip dhclient[4734]: bugs on either our web page at 
www.isc.org or in the README file
  Nov  8 11:57:54 bunyip dhclient[4734]: before submitting a bug.  These pages 
explain the proper
  Nov  8 11:57:54 bunyip dhclient[4734]: process and the information we find 
helpful for debugging..
  Nov  8 11:57:54 bunyip dhclient[4734]: 
  Nov  8 11:57:54 bunyip dhclient[4734]: exiting.
  

  $ wc -l /var/log/maas/rsyslog/bunyip/2016-11-08/messages
  39278 /var/log/maas/rsyslog/bunyip/2016-11-08/messages

  It would be nice to suppress those lines if those could be safely
  ignored. It would make troubleshooting easier when something wrong
  happened on commissioning.

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1640147/+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

[Touch-packages] [Bug 1640147] Re: [2.1] rsyslog is flooded with "no link-local IPv6 address for $IFACE" on commissioning

[LaMont Jones]

The loop of output is caused by maas trying to get an ipv6 address in a
loop, even though the interface clearly does not support ipv6. (If it
did, there would be a link-local address.)

** Changed in: isc-dhcp (Ubuntu)
   Status: New => Invalid

-- 
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/1640147

Title:
  [2.1] rsyslog is flooded with "no link-local IPv6 address for $IFACE"
  on commissioning

Status in MAAS:
  Triaged
Status in isc-dhcp package in Ubuntu:
  Invalid

Bug description:
  When commissioning, /var/log/maas/rsyslog/ is flooded with the
  repeated messages below with over 30,000 lines.

  
  Nov  8 11:57:54 bunyip dhclient[4734]: no link-local IPv6 address for enp4s0f0
  Nov  8 11:57:54 bunyip dhclient[4734]: 
  Nov  8 11:57:54 bunyip dhclient[4734]: If you think you have received this 
message due to a bug rather
  Nov  8 11:57:54 bunyip dhclient[4734]: than a configuration issue please read 
the section on submitting
  Nov  8 11:57:54 bunyip dhclient[4734]: bugs on either our web page at 
www.isc.org or in the README file
  Nov  8 11:57:54 bunyip dhclient[4734]: before submitting a bug.  These pages 
explain the proper
  Nov  8 11:57:54 bunyip dhclient[4734]: process and the information we find 
helpful for debugging..
  Nov  8 11:57:54 bunyip dhclient[4734]: 
  Nov  8 11:57:54 bunyip dhclient[4734]: exiting.
  

  $ wc -l /var/log/maas/rsyslog/bunyip/2016-11-08/messages
  39278 /var/log/maas/rsyslog/bunyip/2016-11-08/messages

  It would be nice to suppress those lines if those could be safely
  ignored. It would make troubleshooting easier when something wrong
  happened on commissioning.

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1640147/+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

[Touch-packages] [Bug 1640147] Re: [2.1] rsyslog is flooded with "no link-local IPv6 address for $IFACE" on commissioning

[LaMont Jones]

tl;dr: dhclient -6 should be less spam-chatty in the presence of no ipv6
support.

If dhclient logged that as one message, instead of 9 messages, then
syslog would compress the output.

The easiest way that I've seen to reproduce this is to boot with
ipv6.disable=true on the kernel command line.

Nobuto: do you have ipv6 disabled via the kernel command line?  (This is
known to cause various issues for a number of daemons.)

** Also affects: isc-dhcp (Ubuntu)
   Importance: Undecided
   Status: New

-- 
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/1640147

Title:
  [2.1] rsyslog is flooded with "no link-local IPv6 address for $IFACE"
  on commissioning

Status in MAAS:
  Triaged
Status in isc-dhcp package in Ubuntu:
  New

Bug description:
  When commissioning, /var/log/maas/rsyslog/ is flooded with the
  repeated messages below with over 30,000 lines.

  
  Nov  8 11:57:54 bunyip dhclient[4734]: no link-local IPv6 address for enp4s0f0
  Nov  8 11:57:54 bunyip dhclient[4734]: 
  Nov  8 11:57:54 bunyip dhclient[4734]: If you think you have received this 
message due to a bug rather
  Nov  8 11:57:54 bunyip dhclient[4734]: than a configuration issue please read 
the section on submitting
  Nov  8 11:57:54 bunyip dhclient[4734]: bugs on either our web page at 
www.isc.org or in the README file
  Nov  8 11:57:54 bunyip dhclient[4734]: before submitting a bug.  These pages 
explain the proper
  Nov  8 11:57:54 bunyip dhclient[4734]: process and the information we find 
helpful for debugging..
  Nov  8 11:57:54 bunyip dhclient[4734]: 
  Nov  8 11:57:54 bunyip dhclient[4734]: exiting.
  

  $ wc -l /var/log/maas/rsyslog/bunyip/2016-11-08/messages
  39278 /var/log/maas/rsyslog/bunyip/2016-11-08/messages

  It would be nice to suppress those lines if those could be safely
  ignored. It would make troubleshooting easier when something wrong
  happened on commissioning.

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1640147/+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

[Touch-packages] [Bug 1632808] Re: Consider supporting IPv6 autoconf in configure_networking

[LaMont Jones]

I am also not aware of anyone in the MAAS space who _wants_ autoconf for
ipv6 networks.  I am aware of at least one who wants it OFF for their
networks.

-- 
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/1632808

Title:
  Consider supporting IPv6 autoconf in configure_networking

Status in MAAS:
  Triaged
Status in initramfs-tools package in Ubuntu:
  Triaged

Bug description:
  Because DHCPv6 only does addresses, and not routes,
  configure_networking needs to wait for the kernel to process a router-
  advertisement before returning claiming an IPv6 config (since all it
  will have is a /128 and no routes, making for a pretty useless network
  stack.)  See Bug #1609898 for context.

  (The syntax for ip= should probably also be extended to allow SLAAC
  configuration.  If the user said "dhcp", then we should insist on
  getting our answer from DHCP.)

  On the bright side, iscsi retries, so after 1 or more failures to
  connect, the router-advertisement comes in and the connect succeeds.

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1632808/+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

[Touch-packages] [Bug 1632808] Re: Consider supporting IPv6 autoconf in configure_networking

[LaMont Jones]

And leaving it triaged for MAAS, since once initramfs-tools supports it,
MAAS will need to propagate that to the UI.

-- 
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/1632808

Title:
  Consider supporting IPv6 autoconf in configure_networking

Status in MAAS:
  Triaged
Status in initramfs-tools package in Ubuntu:
  Triaged

Bug description:
  Because DHCPv6 only does addresses, and not routes,
  configure_networking needs to wait for the kernel to process a router-
  advertisement before returning claiming an IPv6 config (since all it
  will have is a /128 and no routes, making for a pretty useless network
  stack.)  See Bug #1609898 for context.

  (The syntax for ip= should probably also be extended to allow SLAAC
  configuration.  If the user said "dhcp", then we should insist on
  getting our answer from DHCP.)

  On the bright side, iscsi retries, so after 1 or more failures to
  connect, the router-advertisement comes in and the connect succeeds.

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1632808/+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

[Touch-packages] [Bug 1632808] Re: configure_networking exits without any ipv6 routes

[LaMont Jones]

Converting this to be the bug for ip6=stateless (or ip6=autoconf?), as
the rest of it was solved with 1621507.

** Changed in: maas
   Status: New => Fix Released

** Summary changed:

- configure_networking exits without any ipv6 routes
+ Consider supporting IPv6 autoconf in configure_networking

** Changed in: maas
   Status: Fix Released => Triaged

-- 
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/1632808

Title:
  Consider supporting IPv6 autoconf in configure_networking

Status in MAAS:
  Triaged
Status in initramfs-tools package in Ubuntu:
  Triaged

Bug description:
  Because DHCPv6 only does addresses, and not routes,
  configure_networking needs to wait for the kernel to process a router-
  advertisement before returning claiming an IPv6 config (since all it
  will have is a /128 and no routes, making for a pretty useless network
  stack.)  See Bug #1609898 for context.

  (The syntax for ip= should probably also be extended to allow SLAAC
  configuration.  If the user said "dhcp", then we should insist on
  getting our answer from DHCP.)

  On the bright side, iscsi retries, so after 1 or more failures to
  connect, the router-advertisement comes in and the connect succeeds.

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1632808/+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

[Touch-packages] [Bug 1629972] Re: networking stop incorrectly disconnects from (network) root filesystem

[LaMont Jones]

Verification was done by using MAAS to enlist, commission, and deploy
xenial (with the fix) on a machine.  Previously, it failed to shut down,
because the root disk got unmounted.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ifupdown in Ubuntu.
https://bugs.launchpad.net/bugs/1629972

Title:
  networking stop incorrectly disconnects from (network) root filesystem

Status in MAAS:
  Triaged
Status in ifupdown package in Ubuntu:
  Fix Released
Status in ifupdown source package in Xenial:
  Fix Committed
Status in ifupdown source package in Yakkety:
  Fix Released
Status in ifupdown package in Debian:
  New

Bug description:
  === Begin SRU Template ===
  [Impact]
  The systemd networking.service unit will bring down the loopback device (lo)
  when it is stopped.  This behavior differs from the behavior in other
  Ubuntu releases (upstart's networking.conf), where 'lo' is not taken down.

  The problem that was seen was that iscsi root over ipv6 would hang on
  shutdown.  

  [Test Case]
  Test is fairly simple and can be demonstrated in lxc container.
  The key is really that the lo device should not have its link set down
  after stopping networking.service.  So, below:
out=$(ip address show dev lo up); [ -n "$out" ] && echo "$out" || echo empty

  should not show 'empty', but should have LOOPBACK,UP,LOWER in its
  output.

  $ release=yakkety; name=y1
  $ lxc launch ubuntu-daily:$release $name
  $ sleep 10
  $ lxc exec $name /bin/bash

  ## show only things that are up (note output has LOOPBACK,UP,LOWER_UP)
  % ip link show dev lo
  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN mode 
DEFAULT group default qlen 1
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

  % ip address show dev lo up
  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  inet 127.0.0.1/8 scope host lo
 valid_lft forever preferred_lft forever
  inet6 ::1/128 scope host
 valid_lft forever preferred_lft forever

  ## Stop the service and show lo link is down (no 'UP' or 'LOWER_UP').
  % systemctl stop networking.service
  % ip link show dev lo
  1: lo:  mtu 65536 qdisc noqueue state DOWN mode DEFAULT group 
default qlen 1
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  % out=$(ip address show dev lo up); [ -n "$out" ] && echo "$out" || echo empty
  empty

  ## Now enable proposed, install update, reboot and show.
  % rel=$(lsb_release -sc)
  % echo "deb http://archive.ubuntu.com/ubuntu $rel-proposed main" |
  sudo tee /etc/apt/sources.list.d/proposed.list
  % sudo apt update -qy && sudo apt install -qy ifupdown  mtu 65536 qdisc noqueue state UNKNOWN mode 
DEFAULT group default qlen 1
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  % ip address show dev lo up
  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  inet 127.0.0.1/8 scope host lo
 valid_lft forever preferred_lft forever
  inet6 ::1/128 scope host
 valid_lft forever preferred_lft forever
  % systemctl stop networking.service
  % ip link show dev lo
  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN mode 
DEFAULT group default qlen 1
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  % out=$(ip address show dev lo up); [ -n "$out" ] && echo "$out" || echo empty
  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  inet 127.0.0.1/8 scope host lo
 valid_lft forever preferred_lft forever
  inet6 ::1/128 scope host
 valid_lft forever preferred_lft forever

  
  [Regression Potential]
  Should be pretty low.  zesty and  yakkety-proposed have this.
  Taking down 'lo' is often cause of problems, and never the solution to
  problems as far as I'm aware.

  [Other Info]

  === End SRU Template ===

  With the switch to systemd, all support for iscsi root (and other)
  filesystems disappeared, since shutdown yanks the rug out from under
  us.

  Rather than just relying on /etc/iscsi/iscsi.initramfs (which d-i
  creates..), the DEV check should be expanded to include iscsi devices,
  and networking.service ExecStop should honor those checks.

  Related bugs:
    * bug 1229458: grub2 needed changes
    * bug 1621615: network not configured when ipv6 netbooted into cloud-init
    * bug 1621507: ipv6 network boot does not work

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1629972/+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

[Touch-packages] [Bug 1631474] Re: No networking with initramfs-tools 0.122ubuntu8.3 and ip=dhcp boot option

[LaMont Jones]

** Tags removed: verification-needed
** Tags added: verification-done

-- 
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/1631474

Title:
  No networking with initramfs-tools 0.122ubuntu8.3 and ip=dhcp boot
  option

Status in initramfs-tools package in Ubuntu:
  In Progress
Status in initramfs-tools source package in Xenial:
  Fix Released
Status in initramfs-tools source package in Yakkety:
  Fix Committed
Status in initramfs-tools source package in Zesty:
  In Progress

Bug description:
  [Impact]
   * initramfs-tools SRUs introduced regressions in ip= syntax, which cause 
unexpected behavior

  [Test Case]
   * Create a machine that boots using an nfsroot.
   * Use ip=:eth0:dhcp on the kernel command line.  To set up
     networking.
   * Discover that the device never comes up because, networking is not 
configured correctly.

  [Regression Potential]
  Should be back to original behavior before ipv6 support was introduced in the 
past 2 or 3 SRUs.

  [Other Info]

   * There are a number of other issues in this code base that are not solved 
by this fix.
     - The ?*:?*:?*:?*: use case falls through to the default case, and likely 
breaks there.  As such static assignment via ip= appears broken
     -
   * The networking configuration does not strictly follow the kernel 
documentation as described 
https://www.kernel.org/doc/Documentation/filesystems/nfs/nfsroot.txt . This 
should be fixed.

  This bug is a regression of changes made under bug 1628306.

  Original Bug Description Follows==

  initramfs-tools 0.122ubuntu8.3 introduced a serious regression where
  networking is not initialized when the boot option "ip=dhcp" is
  provided. We are seeing this problem in AWS, but cannot confirm if
  this issue is specific to AWS or will occur with different hardware or
  in different environments.

  Removing "ip=dhcp" from the boot options with 0.122ubuntu8.3 results
  in networking being configured.

  The issue does not occur with 0.122ubuntu8.2 or previous versions when
  "ip=dhcp" is set.

  AWS has no console so debugging is not a trivial task. I do have a
  console log with some output, and will update this bug shortly with
  it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1631474/+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

[Touch-packages] [Bug 1629972] Re: networking stop incorrectly disconnects from (network) root filesystem

[LaMont Jones]

** Tags removed: verification-needed
** Tags added: verification-done

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ifupdown in Ubuntu.
https://bugs.launchpad.net/bugs/1629972

Title:
  networking stop incorrectly disconnects from (network) root filesystem

Status in MAAS:
  Triaged
Status in ifupdown package in Ubuntu:
  Fix Released
Status in ifupdown source package in Xenial:
  Fix Committed
Status in ifupdown source package in Yakkety:
  Fix Released
Status in ifupdown package in Debian:
  New

Bug description:
  === Begin SRU Template ===
  [Impact]
  The systemd networking.service unit will bring down the loopback device (lo)
  when it is stopped.  This behavior differs from the behavior in other
  Ubuntu releases (upstart's networking.conf), where 'lo' is not taken down.

  The problem that was seen was that iscsi root over ipv6 would hang on
  shutdown.  

  [Test Case]
  Test is fairly simple and can be demonstrated in lxc container.
  The key is really that the lo device should not have its link set down
  after stopping networking.service.  So, below:
out=$(ip address show dev lo up); [ -n "$out" ] && echo "$out" || echo empty

  should not show 'empty', but should have LOOPBACK,UP,LOWER in its
  output.

  $ release=yakkety; name=y1
  $ lxc launch ubuntu-daily:$release $name
  $ sleep 10
  $ lxc exec $name /bin/bash

  ## show only things that are up (note output has LOOPBACK,UP,LOWER_UP)
  % ip link show dev lo
  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN mode 
DEFAULT group default qlen 1
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

  % ip address show dev lo up
  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  inet 127.0.0.1/8 scope host lo
 valid_lft forever preferred_lft forever
  inet6 ::1/128 scope host
 valid_lft forever preferred_lft forever

  ## Stop the service and show lo link is down (no 'UP' or 'LOWER_UP').
  % systemctl stop networking.service
  % ip link show dev lo
  1: lo:  mtu 65536 qdisc noqueue state DOWN mode DEFAULT group 
default qlen 1
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  % out=$(ip address show dev lo up); [ -n "$out" ] && echo "$out" || echo empty
  empty

  ## Now enable proposed, install update, reboot and show.
  % rel=$(lsb_release -sc)
  % echo "deb http://archive.ubuntu.com/ubuntu $rel-proposed main" |
  sudo tee /etc/apt/sources.list.d/proposed.list
  % sudo apt update -qy && sudo apt install -qy ifupdown  mtu 65536 qdisc noqueue state UNKNOWN mode 
DEFAULT group default qlen 1
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  % ip address show dev lo up
  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  inet 127.0.0.1/8 scope host lo
 valid_lft forever preferred_lft forever
  inet6 ::1/128 scope host
 valid_lft forever preferred_lft forever
  % systemctl stop networking.service
  % ip link show dev lo
  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN mode 
DEFAULT group default qlen 1
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  % out=$(ip address show dev lo up); [ -n "$out" ] && echo "$out" || echo empty
  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  inet 127.0.0.1/8 scope host lo
 valid_lft forever preferred_lft forever
  inet6 ::1/128 scope host
 valid_lft forever preferred_lft forever

  
  [Regression Potential]
  Should be pretty low.  zesty and  yakkety-proposed have this.
  Taking down 'lo' is often cause of problems, and never the solution to
  problems as far as I'm aware.

  [Other Info]

  === End SRU Template ===

  With the switch to systemd, all support for iscsi root (and other)
  filesystems disappeared, since shutdown yanks the rug out from under
  us.

  Rather than just relying on /etc/iscsi/iscsi.initramfs (which d-i
  creates..), the DEV check should be expanded to include iscsi devices,
  and networking.service ExecStop should honor those checks.

  Related bugs:
    * bug 1229458: grub2 needed changes
    * bug 1621615: network not configured when ipv6 netbooted into cloud-init
    * bug 1621507: ipv6 network boot does not work

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1629972/+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

[Touch-packages] [Bug 1621507] Re: initramfs-tools configure_networking() fails to dhcp ipv6 addresses

[LaMont Jones]

Reconfirmed yakkety today.

Also tested "ip6= without ip=": which yakkety currently hates, but we've
decided to handle separately after this SRU lands, partially because
it's a trivial workaround ("for ipv6-only, specify "ip6=dhcp ip=off")
and also not a case that anything needing the SRU actually does.  (MAAS
always specifies both, with one of them set to "off".)

Marking this verification-done.

** Description changed:

  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)
  
  Bugs related to uploads for this specific SRU:
  
  cloud-init:
  bug 1460715: different fix unrelated to this SRU
  bug 1639930: ip6= on kernel command line
  bug 1642679: different fix unrelated to this SRU
  bug 1644043: different fix unrelated to this SRU
  
  ifupdown:
  bug 1629972: networking.service takes down lo on stop
  
  initramfs-tools:
  bug 1621507: no IPv6 DHCP support in early boot
  bug 1628306: regression-update (failure when ip="")
  bug 1631474: regression-update (failure when ip=:eth0:dhcp)
  
  isc-dhcp:
  bug 1621507: no IPv6 DHCP support in early boot
  bug 1633479: dhclient does not wait for IPv6 DAD
  
  open-iscsi:
  bug 1621507: no IPv6 DHCP support in early boot
  
  [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.
  
  [Stable Fix]
  
  These uploads add "ip6=" to the command line syntax to configure ipv6
  using the defacto isc-dhcp-client.  IPv4 configuration (and "ip="
  syntax) remain unchanged.
  
  Valid format for the ip6= command line option is:
     ip6=none (or ip6=off or ip6=) -- do not configure ipv6
     ip6=DEVICE  -- run IPv6 dhclient on device DEVICE.
  
  [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.
  
  [Tests for verification]
  
  Whoever checks the last one off, please mark verification done.
  
  MAAS test cases:
   X / Y
- [+]/[ ] MAAS on IPv6-only network
- [+]/[ ] MAAS on IPv4-only network
- [+]/[ ] MAAS booting IPv4 on dual-stack network (with and without dhcp6)
- [+]/[ ] MAAS booting IPv6 on dual-stack network (with and without dhcp4)
+ [+]/[+] MAAS on IPv6-only network
+ [+]/[+] MAAS on IPv4-only network
+ [+]/[+] MAAS booting IPv4 on dual-stack network (with and without dhcp6)
+ [+]/[+] MAAS booting IPv6 on dual-stack network (with and without dhcp4)
  
  Non-MAAS test cases:
   X / Y
  [+]/[+] ip="" and ip6 not present
  [+]/[+] ip=:eth0:dhcp and ip6 not present
  [+]/[+] d-i install with iSCSI remote root should complete normally
  [+]/[+] Validate normal boot without remote root
  [+]/[+] Booting an iSCSI remote root via IPv4 (using ip=)
  [+]/[+] Booting an iSCSI remote root via IPv6 (using ip6=)
  [+]/[+] Booting an iSCSI remote root via IPv4 (no ip=, d-i use case)
  [+]/[+] Booting an iSCSI remote root with BOOTIF specified (BOOTIF=mac of 
booting device)52-54-00-53-5d-24
  [+]/[+] Booting an iSCSI remote root on mixed network with no options (IPv4 
should be used only)

** Tags removed: verification-needed
** Tags added: verification-done

-- 
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:
  Fix Released
Status in isc-dhcp package in Ubuntu:
  Fix Released
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:
  Fix Committed
Status in isc-dhcp source package in Xenial:
  Fix Committed
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 

[Touch-packages] [Bug 1650631] Re: ip6=dhcp turns on ip=dhcp

[LaMont Jones]

Based on a conversation with Scott, we are both of the opinion that this
bug should not delay the landing of the fixes for bug 1621507 and bug
1621615 into xenial and yakkety.

-- 
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/1650631

Title:
  ip6=dhcp turns on ip=dhcp

Status in initramfs-tools package in Ubuntu:
  New

Bug description:
  When testing bug 1639930 I found that booting a system with:
   ip6=dhcp 
  will enable ip=dhcp.  ip= does not enable ip6=dhcp, so this is odd behavior.

  Thus, if you had an ip6 only network, in order to do this you have to do:
   ip6=dhcp ip=off

  This is really just a matter of a very strange behavior, but behavior that 
can be fixed by just explicitly passing ip=off.


  Related bugs:
   * bug 1639930: initramfs network configuration ignored if only ip6= on 
kernel command line 
   * bug 1621507: initramfs-tools configure_networking() fails to dhcp IPv6 
addresses

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: initramfs-tools 0.122ubuntu8.7
  ProcVersionSignature: User Name 4.4.0-53.74-generic 4.4.30
  Uname: Linux 4.4.0-53-generic x86_64
  ApportVersion: 2.20.1-0ubuntu2.4
  Architecture: amd64
  Date: Fri Dec 16 17:06:23 2016
  PackageArchitecture: all
  ProcEnviron:
   TERM=vt220
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: initramfs-tools
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1650631/+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

[Touch-packages] [Bug 1621507] Re: initramfs-tools configure_networking() fails to dhcp ipv6 addresses

[LaMont Jones]

** Description changed:

  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)
  
  Bugs related to uploads for this specific SRU:
  
  cloud-init:
  bug 1460715: different fix unrelated to this SRU
  bug 1639930: ip6= on kernel command line
  bug 1642679: different fix unrelated to this SRU
  bug 1644043: different fix unrelated to this SRU
  
  ifupdown:
  bug 1629972: networking.service takes down lo on stop
  
  initramfs-tools:
  bug 1621507: no IPv6 DHCP support in early boot
  bug 1628306: regression-update (failure when ip="")
  bug 1631474: regression-update (failure when ip=:eth0:dhcp)
  
  isc-dhcp:
  bug 1621507: no IPv6 DHCP support in early boot
  bug 1633479: dhclient does not wait for IPv6 DAD
  
  open-iscsi:
  bug 1621507: no IPv6 DHCP support in early boot
  
  [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.
  
  [Stable Fix]
  
  These uploads add "ip6=" to the command line syntax to configure ipv6
  using the defacto isc-dhcp-client.  IPv4 configuration (and "ip="
  syntax) remain unchanged.
  
  Valid format for the ip6= command line option is:
     ip6=none (or ip6=off or ip6=) -- do not configure ipv6
     ip6=DEVICE  -- run IPv6 dhclient on device DEVICE.
  
  [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.
  
  [Tests for verification]
  
  Whoever checks the last one off, please mark verification done.
  
  MAAS test cases:
   X / Y
- [+]/[+] MAAS on IPv6-only network
- [+]/[+] MAAS on IPv4-only network
- [+]/[+] MAAS booting IPv4 on dual-stack network (with and without dhcp6)
- [+]/[+] MAAS booting IPv6 on dual-stack network (with and without dhcp4)
+ [+]/[ ] MAAS on IPv6-only network
+ [+]/[ ] MAAS on IPv4-only network
+ [+]/[ ] MAAS booting IPv4 on dual-stack network (with and without dhcp6)
+ [+]/[ ] MAAS booting IPv6 on dual-stack network (with and without dhcp4)
  
  Non-MAAS test cases:
   X / Y
  [+]/[+] ip="" and ip6 not present
  [+]/[+] ip=:eth0:dhcp and ip6 not present
  [+]/[+] d-i install with iSCSI remote root should complete normally
  [+]/[+] Validate normal boot without remote root
  [+]/[+] Booting an iSCSI remote root via IPv4 (using ip=)
  [+]/[+] Booting an iSCSI remote root via IPv6 (using ip6=)
  [+]/[+] Booting an iSCSI remote root via IPv4 (no ip=, d-i use case)
  [+]/[+] Booting an iSCSI remote root with BOOTIF specified (BOOTIF=mac of 
booting device)52-54-00-53-5d-24
  [+]/[+] Booting an iSCSI remote root on mixed network with no options (IPv4 
should be used only)

-- 
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:
  Fix Released
Status in isc-dhcp package in Ubuntu:
  Fix Released
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:
  Fix Committed
Status in isc-dhcp source package in Xenial:
  Fix Committed
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:
  Fix Committed
Status in isc-dhcp source package in Yakkety:
  Fix Committed
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 

[Touch-packages] [Bug 1621507] Re: initramfs-tools configure_networking() fails to dhcp ipv6 addresses

[LaMont Jones]

Final review feedback has been incorporated into initramfs-tools, isc-
dhcp, and open-iscsi, and uploaded to zesty.

** Description changed:

  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)
  
  Bugs related to uploads for this specific SRU:
  
  cloud-init:
  bug 1460715: different fix unrelated to this SRU
  bug 1639930: ip6= on kernel command line
  bug 1642679: different fix unrelated to this SRU
  bug 1644043: different fix unrelated to this SRU
  
  ifupdown:
  bug 1629972: networking.service takes down lo on stop
  
  initramfs-tools:
  bug 1621507: no IPv6 DHCP support in early boot
  bug 1628306: regression-update (failure when ip="")
  bug 1631474: regression-update (failure when ip=:eth0:dhcp)
  
  isc-dhcp:
  bug 1621507: no IPv6 DHCP support in early boot
  bug 1633479: dhclient does not wait for IPv6 DAD
  
  open-iscsi:
  bug 1621507: no IPv6 DHCP support in early boot
  
  [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.
  
  [Stable Fix]
  
  These uploads add "ip6=" to the command line syntax to configure ipv6
  using the defacto isc-dhcp-client.  IPv4 configuration (and "ip="
  syntax) remain unchanged.
  
  Valid format for the ip6= command line option is:
     ip6=none (or ip6=off or ip6=) -- do not configure ipv6
     ip6=DEVICE  -- run IPv6 dhclient on device DEVICE.
  
  [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.
  
  [Tests for verification]
  
  Whoever checks the last one off, please mark verification done.
  
  MAAS test cases:
- [+] MAAS on IPv6-only network
- [+] MAAS on IPv4-only network
- [+] MAAS booting IPv4 on dual-stack network (with and without dhcp6)
- [+] MAAS booting IPv6 on dual-stack network (with and without dhcp4)
+  X / Y
+ [+]/[+] MAAS on IPv6-only network
+ [+]/[+] MAAS on IPv4-only network
+ [+]/[+] MAAS booting IPv4 on dual-stack network (with and without dhcp6)
+ [+]/[+] MAAS booting IPv6 on dual-stack network (with and without dhcp4)
  
  Non-MAAS test cases:
- X/Y
+  X / Y
  [+]/[ ] ip="" and ip6 not present
  [+]/[ ] ip=:eth0:dhcp and ip6 not present
  [+]/[ ] d-i install with iSCSI remote root should complete normally
  [+]/[ ] Validate normal boot without remote root
  [+]/[ ] Booting an iSCSI remote root via IPv4 (using ip=)
  [+]/[ ] Booting an iSCSI remote root via IPv6 (using ip6=)
  [+]/[ ] Booting an iSCSI remote root via IPv4 (no ip=, d-i use case)
  [+]/[ ] Booting an iSCSI remote root with BOOTIF specified (BOOTIF=mac of 
booting device)
  [+]/[ ] Booting an iSCSI remote root on mixed network with no options (IPv4 
should be used only)

-- 
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:
  Fix Released
Status in isc-dhcp package in Ubuntu:
  Fix Released
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:
  Fix Committed
Status in isc-dhcp source package in Xenial:
  Fix Committed
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:
  Fix Committed
Status in isc-dhcp source package in Yakkety:
  Fix Committed
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 

[Touch-packages] [Bug 1621507] Re: initramfs-tools configure_networking() fails to dhcp ipv6 addresses

[LaMont Jones]

** Description changed:

  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)
  
  Bugs related to uploads for this specific SRU:
  
  cloud-init:
  bug 1460715: different fix unrelated to this SRU
  bug 1639930: ip6= on kernel command line
  bug 1642679: different fix unrelated to this SRU
  bug 1644043: different fix unrelated to this SRU
  
  ifupdown:
  bug 1629972: networking.service takes down lo on stop
  
  initramfs-tools:
  bug 1621507: no IPv6 DHCP support in early boot
  bug 1628306: regression-update (failure when ip="")
  bug 1631474: regression-update (failure when ip=:eth0:dhcp)
  
  isc-dhcp:
  bug 1621507: no IPv6 DHCP support in early boot
  bug 1633479: dhclient does not wait for IPv6 DAD
  
  open-iscsi:
  bug 1621507: no IPv6 DHCP support in early boot
  
  [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.
  
  [Stable Fix]
  
  These uploads add "ip6=" to the command line syntax to configure ipv6
  using the defacto isc-dhcp-client.  IPv4 configuration (and "ip="
  syntax) remain unchanged.
  
  Valid format for the ip6= command line option is:
     ip6=none (or ip6=off or ip6=) -- do not configure ipv6
     ip6=DEVICE  -- run IPv6 dhclient on device DEVICE.
  
  [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.
  
  [Tests for verification]
  
  Whoever checks the last one off, please mark verification done.
  
  MAAS test cases:
  [+] MAAS on IPv6-only network
  [+] MAAS on IPv4-only network
- [+] MAAS booting IPv4 on dual-stack network
- [+] MAAS booting IPv6 on dual-stack network
+ [+] MAAS booting IPv4 on dual-stack network (with and without dhcp6)
+ [+] MAAS booting IPv6 on dual-stack network (with and without dhcp4)
  
  Non-MAAS test cases:
+ [ ] ip="" and ip6 not present
+ [ ] ip=:eth0:dhcp and ip6 not present
  [ ] d-i install with iSCSI remote root should complete normally
  [+] Validate normal boot without remote root
  [ ] Booting an iSCSI remote root via IPv4 (using ip=)
  [ ] Booting an iSCSI remote root via IPv6 (using ip6=)
  [ ] Booting an iSCSI remote root via IPv4 (no ip=, d-i use case)
  [ ] Booting an iSCSI remote root via IPv6 (no ip6=, d-i use case)
  [ ] Booting an iSCSI remote root with BOOTIF specified (BOOTIF=mac of booting 
device)
  [ ] Booting an iSCSI remote root on mixed network with no options (IPv4 
should be used only)

-- 
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:
  Fix Released
Status in isc-dhcp package in Ubuntu:
  Fix Released
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:
  Fix Committed
Status in isc-dhcp source package in Xenial:
  Fix Committed
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:
  Fix Committed
Status in isc-dhcp source package in Yakkety:
  Fix Committed
Status in klibc source package in Yakkety:
  Won't Fix
Status in open-iscsi source package in Yakkety:
  Fix Released
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 

[Touch-packages] [Bug 1621507] Re: initramfs-tools configure_networking() fails to dhcp ipv6 addresses

[LaMont Jones]

Marking the "normal boot, no remote root" as verified, since I did that
about a dozen times today.

-- 
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:
  Fix Released
Status in isc-dhcp package in Ubuntu:
  Fix Released
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:
  Fix Committed
Status in isc-dhcp source package in Xenial:
  Fix Committed
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:
  Fix Committed
Status in isc-dhcp source package in Yakkety:
  Fix Committed
Status in klibc source package in Yakkety:
  Won't Fix
Status in open-iscsi source package in Yakkety:
  Fix Released
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)

  Bugs related to uploads for this specific SRU:

  cloud-init:
  bug 1460715: different fix unrelated to this SRU
  bug 1639930: ip6= on kernel command line
  bug 1642679: different fix unrelated to this SRU
  bug 1644043: different fix unrelated to this SRU

  ifupdown:
  bug 1629972: networking.service takes down lo on stop

  initramfs-tools:
  bug 1621507: no IPv6 DHCP support in early boot
  bug 1628306: regression-update (failure when ip="")
  bug 1631474: regression-update (failure when ip=:eth0:dhcp)

  isc-dhcp:
  bug 1621507: no IPv6 DHCP support in early boot
  bug 1633479: dhclient does not wait for IPv6 DAD

  open-iscsi:
  bug 1621507: no IPv6 DHCP support in early boot

  [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.

  [Stable Fix]

  These uploads add "ip6=" to the command line syntax to configure ipv6
  using the defacto isc-dhcp-client.  IPv4 configuration (and "ip="
  syntax) remain unchanged.

  Valid format for the ip6= command line option is:
     ip6=none (or ip6=off or ip6=) -- do not configure ipv6
     ip6=DEVICE  -- run IPv6 dhclient on device DEVICE.

  [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.

  [Tests for verification]

  Whoever checks the last one off, please mark verification done.

  MAAS test cases:
  [+] MAAS on IPv6-only network
  [+] MAAS on IPv4-only network
  [+] MAAS booting IPv4 on dual-stack network
  [+] MAAS booting IPv6 on dual-stack network

  Non-MAAS test cases:
  [ ] d-i install with iSCSI remote root should complete normally
  [+] Validate normal boot without remote root
  [ ] Booting an iSCSI remote root via IPv4 (using ip=)
  [ ] Booting an iSCSI remote root via IPv6 (using ip6=)
  [ ] Booting an iSCSI remote root via IPv4 (no ip=, d-i use case)
  [ ] Booting an iSCSI remote root via IPv6 (no ip6=, d-i use case)
  [ ] Booting an iSCSI remote root with BOOTIF specified (BOOTIF=mac of booting 
device)
  [ ] Booting an iSCSI remote root on mixed network with no options (IPv4 
should be used only)
  [ ] jderose's use cases

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

[Touch-packages] [Bug 1621507] Re: initramfs-tools configure_networking() fails to dhcp ipv6 addresses

[LaMont Jones]

Today, I tested all of the MAAS cases with current -proposed from both
xenial and yakkety.  Behaves as expected.

** Description changed:

  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)
  
  Bugs related to uploads for this specific SRU:
  
  cloud-init:
  bug 1460715: different fix unrelated to this SRU
  bug 1639930: ip6= on kernel command line
  bug 1642679: different fix unrelated to this SRU
  bug 1644043: different fix unrelated to this SRU
  
  ifupdown:
  bug 1629972: networking.service takes down lo on stop
  
  initramfs-tools:
  bug 1621507: no IPv6 DHCP support in early boot
  bug 1628306: regression-update (failure when ip="")
  bug 1631474: regression-update (failure when ip=:eth0:dhcp)
  
  isc-dhcp:
  bug 1621507: no IPv6 DHCP support in early boot
  bug 1633479: dhclient does not wait for IPv6 DAD
  
  open-iscsi:
  bug 1621507: no IPv6 DHCP support in early boot
  
  [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.
  
  [Stable Fix]
  
  These uploads add "ip6=" to the command line syntax to configure ipv6
  using the defacto isc-dhcp-client.  IPv4 configuration (and "ip="
  syntax) remain unchanged.
  
  Valid format for the ip6= command line option is:
     ip6=none (or ip6=off or ip6=) -- do not configure ipv6
     ip6=DEVICE  -- run IPv6 dhclient on device DEVICE.
  
  [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.
  
  [Tests for verification]
  
  Whoever checks the last one off, please mark verification done.
  
  MAAS test cases:
  [+] MAAS on IPv6-only network
  [+] MAAS on IPv4-only network
- [ ] MAAS booting IPv4 on dual-stack network
- [ ] MAAS booting IPv6 on dual-stack network
+ [+] MAAS booting IPv4 on dual-stack network
+ [+] MAAS booting IPv6 on dual-stack network
  
  Non-MAAS test cases:
  [ ] d-i install with iSCSI remote root should complete normally
  [ ] Validate normal boot without remote root
  [ ] Booting an iSCSI remote root via IPv4 (using ip=)
  [ ] Booting an iSCSI remote root via IPv6 (using ip6=)
  [ ] Booting an iSCSI remote root via IPv4 (no ip=, d-i use case)
  [ ] Booting an iSCSI remote root via IPv6 (no ip6=, d-i use case)
  [ ] Booting an iSCSI remote root with BOOTIF specified (BOOTIF=mac of booting 
device)
  [ ] Booting an iSCSI remote root on mixed network with no options (IPv4 
should be used only)
  [ ] jderose's use cases

** Description changed:

  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)
  
  Bugs related to uploads for this specific SRU:
  
  cloud-init:
  bug 1460715: different fix unrelated to this SRU
  bug 1639930: ip6= on kernel command line
  bug 1642679: different fix unrelated to this SRU
  bug 1644043: different fix unrelated to this SRU
  
  ifupdown:
  bug 1629972: networking.service takes down lo on stop
  
  initramfs-tools:
  bug 1621507: no IPv6 DHCP support in early boot
  bug 1628306: regression-update (failure when ip="")
  bug 1631474: regression-update (failure when ip=:eth0:dhcp)
  
  isc-dhcp:
  bug 1621507: no IPv6 DHCP support in early boot
  bug 1633479: dhclient does not wait for IPv6 DAD
  
  open-iscsi:
  bug 1621507: no IPv6 DHCP support in early boot
  
  [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.
  
  [Stable Fix]
  
  These uploads add "ip6=" to the command 

[Touch-packages] [Bug 1621507] Re: initramfs-tools configure_networking() fails to dhcp ipv6 addresses

[LaMont Jones]

** Description changed:

  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)
  
  Bugs related to uploads for this specific SRU:
  
  cloud-init:
  bug 1460715: different fix unrelated to this SRU
  bug 1639930: ip6= on kernel command line
  bug 1642679: different fix unrelated to this SRU
  bug 1644043: different fix unrelated to this SRU
  
  ifupdown:
  bug 1629972: networking.service takes down lo on stop
  
  initramfs-tools:
  bug 1621507: no IPv6 DHCP support in early boot
  bug 1628306: regression-update (failure when ip="")
  bug 1631474: regression-update (failure when ip=:eth0:dhcp)
  
  isc-dhcp:
  bug 1621507: no IPv6 DHCP support in early boot
  bug 1633479: dhclient does not wait for IPv6 DAD
  
  open-iscsi:
  bug 1621507: no IPv6 DHCP support in early boot
  
  [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.
  
  [Stable Fix]
  
  These uploads add "ip6=" to the command line syntax to configure ipv6
  using the defacto isc-dhcp-client.  IPv4 configuration (and "ip="
  syntax) remain unchanged.
  
  Valid format for the ip6= command line option is:
     ip6=none (or ip6=off or ip6=) -- do not configure ipv6
     ip6=DEVICE  -- run IPv6 dhclient on device DEVICE.
  
  [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.
  
  [Tests for verification]
  
  Whoever checks the last one off, please mark verification done.
  
  MAAS test cases:
- [ ] MAAS on IPv6-only network
- [ ] MAAS on IPv4-only network
+ [+] MAAS on IPv6-only network
+ [+] MAAS on IPv4-only network
  [ ] MAAS booting IPv4 on dual-stack network
  [ ] MAAS booting IPv6 on dual-stack network
  
  Non-MAAS test cases:
  [ ] d-i install with iSCSI remote root should complete normally
  [ ] Validate normal boot without remote root
  [ ] Booting an iSCSI remote root via IPv4 (using ip=)
  [ ] Booting an iSCSI remote root via IPv6 (using ip6=)
  [ ] Booting an iSCSI remote root via IPv4 (no ip=, d-i use case)
  [ ] Booting an iSCSI remote root via IPv6 (no ip6=, d-i use case)
  [ ] Booting an iSCSI remote root with BOOTIF specified (BOOTIF=mac of booting 
device)
  [ ] Booting an iSCSI remote root on mixed network with no options (IPv4 
should be used only)
  [ ] jderose's use cases

-- 
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:
  Fix Released
Status in isc-dhcp package in Ubuntu:
  Fix Released
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:
  Fix Committed
Status in isc-dhcp source package in Xenial:
  Fix Committed
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:
  Fix Committed
Status in isc-dhcp source package in Yakkety:
  Fix Committed
Status in klibc source package in Yakkety:
  Won't Fix
Status in open-iscsi source package in Yakkety:
  Fix Released
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)

  Bugs related to uploads for this specific SRU:

  cloud-init:
  bug 1460715: 

[Touch-packages] [Bug 1621507] Re: initramfs-tools configure_networking() fails to dhcp ipv6 addresses

[LaMont Jones]

** Description changed:

  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)
  
  Bugs related to uploads for this specific SRU:
  
  cloud-init:
  bug 1460715: different fix unrelated to this SRU
  bug 1639930: ip6= on kernel command line
  bug 1642679: different fix unrelated to this SRU
  bug 1644043: different fix unrelated to this SRU
  
  ifupdown:
  bug 1629972: networking.service takes down lo on stop
  
  initramfs-tools:
  bug 1621507: no IPv6 DHCP support in early boot
  bug 1628306: regression-update (failure when ip="")
  bug 1631474: regression-update (failure when ip=:eth0:dhcp)
  
  isc-dhcp:
  bug 1621507: no IPv6 DHCP support in early boot
  bug 1633479: dhclient does not wait for IPv6 DAD
  
  open-iscsi:
  bug 1621507: no IPv6 DHCP support in early boot
  
- 
  [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.
  
  [Stable Fix]
  
  These uploads add "ip6=" to the command line syntax to configure ipv6
  using the defacto isc-dhcp-client.  IPv4 configuration (and "ip="
  syntax) remain unchanged.
  
  Valid format for the ip6= command line option is:
     ip6=none (or ip6=off or ip6=) -- do not configure ipv6
     ip6=DEVICE  -- run IPv6 dhclient on device DEVICE.
  
  [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.
+ 
+ [Tests for verification]
+ 
+ Whoever checks the last one off, please mark verification done.
+ 
+ MAAS test cases:
+ [ ] MAAS on IPv6-only network
+ [ ] MAAS on IPv4-only network
+ [ ] MAAS booting IPv4 on dual-stack network
+ [ ] MAAS booting IPv6 on dual-stack network
+ 
+ Non-MAAS test cases:
+ [ ] 

-- 
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:
  Fix Released
Status in isc-dhcp package in Ubuntu:
  Fix Released
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:
  Fix Committed
Status in isc-dhcp source package in Xenial:
  Fix Committed
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:
  Fix Committed
Status in isc-dhcp source package in Yakkety:
  Fix Committed
Status in klibc source package in Yakkety:
  Won't Fix
Status in open-iscsi source package in Yakkety:
  Fix Released
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)

  Bugs related to uploads for this specific SRU:

  cloud-init:
  bug 1460715: different fix unrelated to this SRU
  bug 1639930: ip6= on kernel command line
  bug 1642679: different fix unrelated to this SRU
  bug 1644043: different fix unrelated to this SRU

  ifupdown:
  bug 1629972: networking.service takes down lo on stop

  initramfs-tools:
  bug 1621507: no IPv6 DHCP support in early boot
  bug 1628306: regression-update (failure when ip="")
  bug 1631474: regression-update (failure when ip=:eth0:dhcp)

  isc-dhcp:
  bug 1621507: no IPv6 DHCP support in early boot
  bug 1633479: dhclient does not wait for IPv6 DAD

  open-iscsi:
  bug 1621507: no IPv6 DHCP support in early boot

  

[Touch-packages] [Bug 1621507] Re: initramfs-tools configure_networking() fails to dhcp ipv6 addresses

[LaMont Jones]

** Merge proposal linked:
   
https://code.launchpad.net/~lamont/ubuntu/+source/open-iscsi/+git/open-iscsi/+merge/312899

-- 
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:
  Fix Released
Status in isc-dhcp package in Ubuntu:
  Fix Released
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:
  Fix Committed
Status in isc-dhcp source package in Xenial:
  Fix Committed
Status in klibc source package in Xenial:
  Won't Fix
Status in open-iscsi source package in Xenial:
  Fix Released
Status in initramfs-tools source package in Yakkety:
  Fix Committed
Status in isc-dhcp source package in Yakkety:
  Fix Committed
Status in klibc source package in Yakkety:
  Won't Fix
Status in open-iscsi source package in Yakkety:
  Fix Released
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.

  [Stable Fix]

  These uploads add "ip6=" to the command line syntax to configure ipv6
  using the defacto isc-dhcp-client.  IPv4 configuration (and "ip="
  syntax) remain unchanged.

  Valid format for the ip6= command line option is:
     ip6=none (or ip6=off or ip6=) -- do not configure ipv6
     ip6=DEVICE  -- run IPv6 dhclient on device DEVICE.

  [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

[Touch-packages] [Bug 1621507] Re: initramfs-tools configure_networking() fails to dhcp ipv6 addresses

[LaMont Jones]

** Description changed:

  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) 
- 
+   * 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.
+ These uploads add "ip6=" to the command line syntax to configure ipv6
+ using the defacto isc-dhcp-client.  IPv4 configuration (and "ip="
+ syntax) remain unchanged.
+ 
+ Valid format for the ip6= command line option is:
+ip6=none (or ip6=off or ip6=) -- do not configure ipv6
+ip6=DEVICE  -- run IPv6 dhclient on device DEVICE.
  
  [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.

-- 
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:
  Fix Released
Status in isc-dhcp package in Ubuntu:
  Fix Released
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:
  Fix Committed
Status in isc-dhcp source package in Xenial:
  Fix Committed
Status in klibc source package in Xenial:
  Won't Fix
Status in open-iscsi source package in Xenial:
  Fix Released
Status in initramfs-tools source package in Yakkety:
  Fix Committed
Status in isc-dhcp source package in Yakkety:
  Fix Committed
Status in klibc source package in Yakkety:
  Won't Fix
Status in open-iscsi source package in Yakkety:
  Fix Released
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 add "ip6=" to the command line syntax to configure ipv6
  using the defacto isc-dhcp-client.  IPv4 configuration (and "ip="
  syntax) remain unchanged.

  Valid format for the ip6= command line option is:
 ip6=none (or ip6=off or ip6=) -- do not configure ipv6
 ip6=DEVICE  -- run IPv6 dhclient on device DEVICE.

  [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 

[Touch-packages] [Bug 1647586] [NEW] apparmor errors with current ntp

[LaMont Jones]

Public bug reported:

On ntpd restart, this gets logged. (1:4.2.8p8+dfsg-1ubuntu2)

Dec  6 01:14:05 rover3 kernel: [16526.813113] audit: type=1400
audit(1481012045.534:136): apparmor="DENIED" operation="connect"
profile="/usr/sbin/ntpd" name="/run/dbus/system_bus_socket" pid=29435
comm="ntpd" requested_mask="wr" denied_mask="wr" fsuid=123 ouid=0

** Affects: ntp (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ntp in Ubuntu.
https://bugs.launchpad.net/bugs/1647586

Title:
  apparmor errors with current ntp

Status in ntp package in Ubuntu:
  New

Bug description:
  On ntpd restart, this gets logged. (1:4.2.8p8+dfsg-1ubuntu2)

  Dec  6 01:14:05 rover3 kernel: [16526.813113] audit: type=1400
  audit(1481012045.534:136): apparmor="DENIED" operation="connect"
  profile="/usr/sbin/ntpd" name="/run/dbus/system_bus_socket" pid=29435
  comm="ntpd" requested_mask="wr" denied_mask="wr" fsuid=123 ouid=0

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1647586/+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

[Touch-packages] [Bug 1621507] Re: initramfs-tools configure_networking() fails to dhcp ipv6 addresses

[LaMont Jones]

open-iscsi is verified for xenial and yakkety

** Tags removed: verification-needed
** Tags added: verification-done

-- 
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:
  Fix Released
Status in isc-dhcp package in Ubuntu:
  Fix Released
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

[Touch-packages] [Bug 1632804] Re: ROUNDTTT in configure_networking is effectively ignored

[LaMont Jones]

*** This bug is a duplicate of bug 1621507 ***
https://bugs.launchpad.net/bugs/1621507

** This bug has been marked a duplicate of bug 1621507
   initramfs-tools configure_networking() fails to dhcp ipv6 addresses

-- 
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/1632804

Title:
  ROUNDTTT in configure_networking is effectively ignored

Status in MAAS:
  New
Status in initramfs-tools package in Ubuntu:
  New

Bug description:
  With the changes from Bug #1621507, ROUNDTTT is effectively ignored.

  The loop checks only for the existence of /run/net-${DEVICE}.conf, and
  the dhclient scripts ALWAYS (even on failure) create it, it will try
  to get a lease exactly once before bailing out. Ideally, if both ipv4
  and ipv6 are present on the vlan, then both would be configured and
  (as is done) present in the net-$DEV.conf file.  Generally speaking
  (and why we didn't notice this in testing..), dhclient gets a lease on
  the first pass.

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1632804/+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

[Touch-packages] [Bug 1621507] Re: initramfs-tools configure_networking() fails to dhcp ipv6 addresses

[LaMont Jones]

** Patch added: "isc-dhcp debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1621507/+attachment/4770861/+files/isc-dhcp.debdiff

-- 
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:
  In Progress
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:
  In Progress
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:
  In Progress
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

[Touch-packages] [Bug 1621507] Re: initramfs-tools configure_networking() fails to dhcp ipv6 addresses

[LaMont Jones]

I'm attaching debdiffs for initramfs-tools, isc-dhcp, and open-iscsi.
The combination (along with cloud-initramfs-tools and cloud-init -- see
bug 1621615) seem to work with maas in IPv4, IPv6, and dual stack
(booting IPv4 and IPv6), when added to yakkety-proposed.

** Patch added: "debdiff for initramfs-tools"
   
https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1621507/+attachment/4770859/+files/initramfs-tools.debdiff

-- 
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:
  In Progress
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:
  In Progress
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:
  In Progress
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

[Touch-packages] [Bug 1621507] Re: initramfs-tools configure_networking() fails to dhcp ipv6 addresses

[LaMont Jones]

** Patch added: "open-iscsi debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1621507/+attachment/4770860/+files/open-iscsi.debdiff

-- 
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:
  In Progress
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:
  In Progress
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:
  In Progress
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

[Touch-packages] [Bug 1621507] Re: initramfs-tools configure_networking() fails to dhcp ipv6 addresses

[LaMont Jones]

All of the debdiffs need to be rolled into zesty, and backported to
yakkety, xenial.

** Changed in: isc-dhcp (Ubuntu)
   Status: Fix Released => In Progress

** Changed in: isc-dhcp (Ubuntu Xenial)
   Status: Fix Released => In Progress

** Changed in: isc-dhcp (Ubuntu Yakkety)
   Status: Fix Released => In Progress

** Changed in: open-iscsi (Ubuntu)
   Status: Fix Released => In Progress

** Changed in: open-iscsi (Ubuntu Xenial)
   Status: Fix Released => In Progress

** Changed in: open-iscsi (Ubuntu Yakkety)
   Status: Fix Released => In Progress

-- 
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:
  In Progress
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:
  In Progress
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:
  In Progress
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

[Touch-packages] [Bug 1621507] Re: initramfs-tools configure_networking() fails to dhcp ipv6 addresses

[LaMont Jones]

all 3 debdiffs need to land in zesty, and be backported to yakkety and
xenial for SRU.

-- 
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:
  In Progress
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:
  In Progress
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:
  In Progress
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

[Touch-packages] [Bug 1621507] Re: initramfs-tools configure_networking() fails to dhcp ipv6 addresses

[LaMont Jones]

attached debdiff needs to roll forward into zesty.

** Changed in: initramfs-tools (Ubuntu)
   Status: Fix Released => In Progress

-- 
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:
  In Progress
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:
  In Progress
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:
  In Progress
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

[Touch-packages] [Bug 1621507] Re: initramfs-tools configure_networking() fails to dhcp ipv6 addresses

[LaMont Jones]

** Changed in: maas
   Status: Fix Released => In Progress

** Changed in: maas
 Assignee: (unassigned) => LaMont Jones (lamont)

-- 
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:
  In Progress
Status in initramfs-tools package in Ubuntu:
  In Progress
Status in isc-dhcp package in Ubuntu:
  Fix Released
Status in klibc package in Ubuntu:
  Won't Fix
Status in open-iscsi package in Ubuntu:
  Fix Released
Status in initramfs-tools source package in Xenial:
  Triaged
Status in isc-dhcp source package in Xenial:
  Fix Released
Status in klibc source package in Xenial:
  Won't Fix
Status in open-iscsi source package in Xenial:
  Fix Released
Status in initramfs-tools source package in Yakkety:
  In Progress
Status in isc-dhcp source package in Yakkety:
  Fix Released
Status in klibc source package in Yakkety:
  Won't Fix
Status in open-iscsi source package in Yakkety:
  Fix Released
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

[Touch-packages] [Bug 1635654] Re: Machine fails to stop, or start interfaces. hangs in systemd waiting for completion

[LaMont Jones]

The reboot of the system prior to this morning was after a dist-upgrade
on "2016-10-14 08:30:10" according to  /var/log/apt/history.log -- the
upgrade to zesty occurred on 2016-10-18, and the reboot was after a
fresh dist-upgrade this morning, on zesty.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ifupdown in Ubuntu.
https://bugs.launchpad.net/bugs/1635654

Title:
  Machine fails to stop, or start interfaces.  hangs in systemd waiting
  for completion

Status in ifupdown package in Ubuntu:
  New

Bug description:
  The attached /etc/network/interfaces file is fatal to
  /lib/systemd/system/networking.service, resulting in a loop that never
  finishes.

  ProblemType: Bug
  DistroRelease: Ubuntu 17.04
  Package: ifupdown 0.8.13ubuntu4
  ProcVersionSignature: Ubuntu 
4.4.0-14.30~lp1543683LatestXenialWithRevert-generic 4.4.5
  Uname: Linux 4.4.0-14-generic x86_64
  ApportVersion: 2.20.3-0ubuntu8
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Fri Oct 21 09:14:33 2016
  InstallationDate: Installed on 2014-09-22 (759 days ago)
  InstallationMedia: Ubuntu-Server 14.04 LTS "Trusty Tahr" - Release amd64 
(20140416.2)
  SourcePackage: ifupdown
  UpgradeStatus: Upgraded to zesty on 2014-11-14 (706 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1635654/+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

[Touch-packages] [Bug 1635654] Re: Machine fails to stop, or start interfaces. hangs in systemd waiting for completion

[LaMont Jones]

After you change your /e/n/i to that, and reproduce the issue,
break=init, and then mount -oremount,rw /root; chroot /root; vi
/etc/network/interfaces and comment out everything from "auto br1" to
end of file, exit; mount -oremount,ro /root; exit

and you're back to a bootable system...  Which is why the apport files
are pretty much useless on this report.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ifupdown in Ubuntu.
https://bugs.launchpad.net/bugs/1635654

Title:
  Machine fails to stop, or start interfaces.  hangs in systemd waiting
  for completion

Status in ifupdown package in Ubuntu:
  New

Bug description:
  The attached /etc/network/interfaces file is fatal to
  /lib/systemd/system/networking.service, resulting in a loop that never
  finishes.

  ProblemType: Bug
  DistroRelease: Ubuntu 17.04
  Package: ifupdown 0.8.13ubuntu4
  ProcVersionSignature: Ubuntu 
4.4.0-14.30~lp1543683LatestXenialWithRevert-generic 4.4.5
  Uname: Linux 4.4.0-14-generic x86_64
  ApportVersion: 2.20.3-0ubuntu8
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Fri Oct 21 09:14:33 2016
  InstallationDate: Installed on 2014-09-22 (759 days ago)
  InstallationMedia: Ubuntu-Server 14.04 LTS "Trusty Tahr" - Release amd64 
(20140416.2)
  SourcePackage: ifupdown
  UpgradeStatus: Upgraded to zesty on 2014-11-14 (706 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1635654/+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

[Touch-packages] [Bug 1635654] Re: Machine fails to stop, or start interfaces. hangs in systemd waiting for completion

[LaMont Jones]

** Attachment added: "/e/n/i that results in a loop"
   
https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1635654/+attachment/4764881/+files/interfaces

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ifupdown in Ubuntu.
https://bugs.launchpad.net/bugs/1635654

Title:
  Machine fails to stop, or start interfaces.  hangs in systemd waiting
  for completion

Status in ifupdown package in Ubuntu:
  New

Bug description:
  The attached /etc/network/interfaces file is fatal to
  /lib/systemd/system/networking.service, resulting in a loop that never
  finishes.

  ProblemType: Bug
  DistroRelease: Ubuntu 17.04
  Package: ifupdown 0.8.13ubuntu4
  ProcVersionSignature: Ubuntu 
4.4.0-14.30~lp1543683LatestXenialWithRevert-generic 4.4.5
  Uname: Linux 4.4.0-14-generic x86_64
  ApportVersion: 2.20.3-0ubuntu8
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Fri Oct 21 09:14:33 2016
  InstallationDate: Installed on 2014-09-22 (759 days ago)
  InstallationMedia: Ubuntu-Server 14.04 LTS "Trusty Tahr" - Release amd64 
(20140416.2)
  SourcePackage: ifupdown
  UpgradeStatus: Upgraded to zesty on 2014-11-14 (706 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1635654/+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

[Touch-packages] [Bug 1635654] [NEW] Machine fails to stop, or start interfaces. hangs in systemd waiting for completion

[LaMont Jones]

Public bug reported:

The attached /etc/network/interfaces file is fatal to
/lib/systemd/system/networking.service, resulting in a loop that never
finishes.

ProblemType: Bug
DistroRelease: Ubuntu 17.04
Package: ifupdown 0.8.13ubuntu4
ProcVersionSignature: Ubuntu 
4.4.0-14.30~lp1543683LatestXenialWithRevert-generic 4.4.5
Uname: Linux 4.4.0-14-generic x86_64
ApportVersion: 2.20.3-0ubuntu8
Architecture: amd64
CurrentDesktop: Unity
Date: Fri Oct 21 09:14:33 2016
InstallationDate: Installed on 2014-09-22 (759 days ago)
InstallationMedia: Ubuntu-Server 14.04 LTS "Trusty Tahr" - Release amd64 
(20140416.2)
SourcePackage: ifupdown
UpgradeStatus: Upgraded to zesty on 2014-11-14 (706 days ago)

** Affects: ifupdown (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug zesty

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ifupdown in Ubuntu.
https://bugs.launchpad.net/bugs/1635654

Title:
  Machine fails to stop, or start interfaces.  hangs in systemd waiting
  for completion

Status in ifupdown package in Ubuntu:
  New

Bug description:
  The attached /etc/network/interfaces file is fatal to
  /lib/systemd/system/networking.service, resulting in a loop that never
  finishes.

  ProblemType: Bug
  DistroRelease: Ubuntu 17.04
  Package: ifupdown 0.8.13ubuntu4
  ProcVersionSignature: Ubuntu 
4.4.0-14.30~lp1543683LatestXenialWithRevert-generic 4.4.5
  Uname: Linux 4.4.0-14-generic x86_64
  ApportVersion: 2.20.3-0ubuntu8
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Fri Oct 21 09:14:33 2016
  InstallationDate: Installed on 2014-09-22 (759 days ago)
  InstallationMedia: Ubuntu-Server 14.04 LTS "Trusty Tahr" - Release amd64 
(20140416.2)
  SourcePackage: ifupdown
  UpgradeStatus: Upgraded to zesty on 2014-11-14 (706 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1635654/+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

[Touch-packages] [Bug 1631474] Re: No networking with initramfs-tools 0.122ubuntu8.3 and ip=dhcp boot option

[LaMont Jones]

After more discussion, marking this verification-done.

** Tags removed: verification-needed
** Tags added: verification-done

-- 
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/1631474

Title:
  No networking with initramfs-tools 0.122ubuntu8.3 and ip=dhcp boot
  option

Status in initramfs-tools package in Ubuntu:
  Fix Committed
Status in initramfs-tools source package in Xenial:
  Fix Committed
Status in initramfs-tools source package in Yakkety:
  Fix Committed
Status in initramfs-tools source package in z-series:
  Fix Committed

Bug description:
  [Impact]

   * 0.122ubuntu8.3 of initramfs-tools no longer correctly processed
  ip=dhcp or ip=:eth0:dhcp

   * Regression-updates

   * The fix better parses the ip= command line argument.

  [Test Case]

   * Create a machine that boots using an nfsroot.

   * Use ip=:eth0:dhcp on the kernel command line.  To set up
     networking.

   * Discover that the device never comes up because, networking is not
  configured correctly.

  [Regression Potential]

   * Regressions potential is limited to machines using
  ip={""|*|on|any|dhcp} on the kernel command line.  As this is
  already broken regression potential is minimal.  This is common on
  machines that use nfsroot or otherwise pxe boot.

  [Other Info]

   * There are a number of other issues in this code base that are not solved 
by this fix.
     - The ?*:?*:?*:?*: use case falls through to the default case, and likely 
breaks there.  As such static assignment via ip= appears broken
     -
   * The networking configuration does not strictly follow the kernel 
documentation as described 
https://www.kernel.org/doc/Documentation/filesystems/nfs/nfsroot.txt . This 
should be fixed.

  This bug is a regression of changes made under bug 1628306.

  Original Bug Description Follows==

  initramfs-tools 0.122ubuntu8.3 introduced a serious regression where
  networking is not initialized when the boot option "ip=dhcp" is
  provided. We are seeing this problem in AWS, but cannot confirm if
  this issue is specific to AWS or will occur with different hardware or
  in different environments.

  Removing "ip=dhcp" from the boot options with 0.122ubuntu8.3 results
  in networking being configured.

  The issue does not occur with 0.122ubuntu8.2 or previous versions when
  "ip=dhcp" is set.

  AWS has no console so debugging is not a trivial task. I do have a
  console log with some output, and will update this bug shortly with
  it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1631474/+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

[Touch-packages] [Bug 1631474] Re: No networking with initramfs-tools 0.122ubuntu8.3 and ip=dhcp boot option

[LaMont Jones]

I have confirmed that this functions as expected for MAAS (behaves
exactly like 0.122ubuntu8.1 did.)  Not marking verification-done, but +1
from me/MAAS.

-- 
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/1631474

Title:
  No networking with initramfs-tools 0.122ubuntu8.3 and ip=dhcp boot
  option

Status in initramfs-tools package in Ubuntu:
  Fix Committed
Status in initramfs-tools source package in Xenial:
  Fix Committed
Status in initramfs-tools source package in Yakkety:
  Fix Committed
Status in initramfs-tools source package in z-series:
  Fix Committed

Bug description:
  [Impact]

   * 0.122ubuntu8.3 of initramfs-tools no longer correctly processed
  ip=dhcp or ip=:eth0:dhcp

   * Regression-updates

   * The fix better parses the ip= command line argument.

  [Test Case]

   * Create a machine that boots using an nfsroot.

   * Use ip=:eth0:dhcp on the kernel command line.  To set up
     networking.

   * Discover that the device never comes up because, networking is not
  configured correctly.

  [Regression Potential]

   * Regressions potential is limited to machines using
  ip={""|*|on|any|dhcp} on the kernel command line.  As this is
  already broken regression potential is minimal.  This is common on
  machines that use nfsroot or otherwise pxe boot.

  [Other Info]

   * There are a number of other issues in this code base that are not solved 
by this fix.
     - The ?*:?*:?*:?*: use case falls through to the default case, and likely 
breaks there.  As such static assignment via ip= appears broken
     -
   * The networking configuration does not strictly follow the kernel 
documentation as described 
https://www.kernel.org/doc/Documentation/filesystems/nfs/nfsroot.txt . This 
should be fixed.

  This bug is a regression of changes made under bug 1628306.

  Original Bug Description Follows==

  initramfs-tools 0.122ubuntu8.3 introduced a serious regression where
  networking is not initialized when the boot option "ip=dhcp" is
  provided. We are seeing this problem in AWS, but cannot confirm if
  this issue is specific to AWS or will occur with different hardware or
  in different environments.

  Removing "ip=dhcp" from the boot options with 0.122ubuntu8.3 results
  in networking being configured.

  The issue does not occur with 0.122ubuntu8.2 or previous versions when
  "ip=dhcp" is set.

  AWS has no console so debugging is not a trivial task. I do have a
  console log with some output, and will update this bug shortly with
  it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1631474/+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

[Touch-packages] [Bug 1631474] Re: No networking with initramfs-tools 0.122ubuntu8.3 and ip=dhcp boot option

[LaMont Jones]

0.122ubuntu8.4 still fails to get an IP when the switchport is not
'portfast' (and the switch therefore passes no traffic for 60 seconds
after link-up.)

-- 
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/1631474

Title:
  No networking with initramfs-tools 0.122ubuntu8.3 and ip=dhcp boot
  option

Status in initramfs-tools package in Ubuntu:
  Fix Committed
Status in initramfs-tools source package in Xenial:
  Fix Committed
Status in initramfs-tools source package in Yakkety:
  Fix Committed
Status in initramfs-tools source package in z-series:
  Fix Committed

Bug description:
  [Impact]

   * 0.122ubuntu8.3 of initramfs-tools no longer correctly processed
  ip=dhcp or ip=:eth0:dhcp

   * Regression-updates

   * The fix better parses the ip= command line argument.

  [Test Case]

   * Create a machine that boots using an nfsroot.

   * Use ip=:eth0:dhcp on the kernel command line.  To set up
     networking.

   * Discover that the device never comes up because, networking is not
  configured correctly.

  [Regression Potential]

   * Regressions potential is limited to machines using
  ip={""|*|on|any|dhcp} on the kernel command line.  As this is
  already broken regression potential is minimal.  This is common on
  machines that use nfsroot or otherwise pxe boot.

  [Other Info]

   * There are a number of other issues in this code base that are not solved 
by this fix.
     - The ?*:?*:?*:?*: use case falls through to the default case, and likely 
breaks there.  As such static assignment via ip= appears broken
     -
   * The networking configuration does not strictly follow the kernel 
documentation as described 
https://www.kernel.org/doc/Documentation/filesystems/nfs/nfsroot.txt . This 
should be fixed.

  This bug is a regression of changes made under bug 1628306.

  Original Bug Description Follows==

  initramfs-tools 0.122ubuntu8.3 introduced a serious regression where
  networking is not initialized when the boot option "ip=dhcp" is
  provided. We are seeing this problem in AWS, but cannot confirm if
  this issue is specific to AWS or will occur with different hardware or
  in different environments.

  Removing "ip=dhcp" from the boot options with 0.122ubuntu8.3 results
  in networking being configured.

  The issue does not occur with 0.122ubuntu8.2 or previous versions when
  "ip=dhcp" is set.

  AWS has no console so debugging is not a trivial task. I do have a
  console log with some output, and will update this bug shortly with
  it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1631474/+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

[Touch-packages] [Bug 1621507] Re: initramfs-tools configure_networking() fails to dhcp ipv6 addresses

[LaMont Jones]

Filed the above 2 issues as (1) Bug #1632804 and (2) Bug #1632808 for
yakkety.  noting that here because those should be fixed as part of the
xenial SRU of this bug.

-- 
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 Released
Status in initramfs-tools package in Ubuntu:
  Fix Released
Status in isc-dhcp package in Ubuntu:
  Fix Released
Status in klibc package in Ubuntu:
  Won't Fix
Status in open-iscsi package in Ubuntu:
  Fix Released
Status in initramfs-tools source package in Xenial:
  Fix Released
Status in isc-dhcp source package in Xenial:
  Fix Released
Status in klibc source package in Xenial:
  Won't Fix
Status in open-iscsi source package in Xenial:
  Fix Released
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

  [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

[Touch-packages] [Bug 1632804] Re: ROUNDTTT in configure_networking is effectively ignored

[LaMont Jones]

** Also affects: maas
   Importance: Undecided
   Status: New

** Tags added: maas-ipv6

-- 
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/1632804

Title:
  ROUNDTTT in configure_networking is effectively ignored

Status in MAAS:
  New
Status in initramfs-tools package in Ubuntu:
  New

Bug description:
  With the changes from Bug #1621507, ROUNDTTT is effectively ignored.

  The loop checks only for the existence of /run/net-${DEVICE}.conf, and
  the dhclient scripts ALWAYS (even on failure) create it, it will try
  to get a lease exactly once before bailing out. Ideally, if both ipv4
  and ipv6 are present on the vlan, then both would be configured and
  (as is done) present in the net-$DEV.conf file.  Generally speaking
  (and why we didn't notice this in testing..), dhclient gets a lease on
  the first pass.

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1632804/+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

[Touch-packages] [Bug 1632808] [NEW] configure_networking exits without any ipv6 routes

[LaMont Jones]

Public bug reported:

Because DHCPv6 only does addresses, and not routes, configure_networking
needs to wait for the kernel to process a router-advertisement before
returning claiming an IPv6 config (since all it will have is a /128 and
no routes, making for a pretty useless network stack.)  See Bug #1609898
for context.

(The syntax for ip= should probably also be extended to allow SLAAC
configuration.  If the user said "dhcp", then we should insist on
getting our answer from DHCP.)

On the bright side, iscsi retries, so after 1 or more failures to
connect, the router-advertisement comes in and the connect succeeds.

** Affects: maas
 Importance: Undecided
 Status: New

** Affects: initramfs-tools (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: maas-ipv6

** Tags added: maas-ipv6

** Also affects: maas
   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/1632808

Title:
  configure_networking exits without any ipv6 routes

Status in MAAS:
  New
Status in initramfs-tools package in Ubuntu:
  New

Bug description:
  Because DHCPv6 only does addresses, and not routes,
  configure_networking needs to wait for the kernel to process a router-
  advertisement before returning claiming an IPv6 config (since all it
  will have is a /128 and no routes, making for a pretty useless network
  stack.)  See Bug #1609898 for context.

  (The syntax for ip= should probably also be extended to allow SLAAC
  configuration.  If the user said "dhcp", then we should insist on
  getting our answer from DHCP.)

  On the bright side, iscsi retries, so after 1 or more failures to
  connect, the router-advertisement comes in and the connect succeeds.

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1632808/+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

[Touch-packages] [Bug 1632804] [NEW] ROUNDTTT in configure_networking is effectively ignored

[LaMont Jones]

Public bug reported:

With the changes from Bug #1621507, ROUNDTTT is effectively ignored.

The loop checks only for the existence of /run/net-${DEVICE}.conf, and
the dhclient scripts ALWAYS (even on failure) create it, it will try to
get a lease exactly once before bailing out. Ideally, if both ipv4 and
ipv6 are present on the vlan, then both would be configured and (as is
done) present in the net-$DEV.conf file.  Generally speaking (and why we
didn't notice this in testing..), dhclient gets a lease on the first
pass.

** Affects: maas
 Importance: Undecided
 Status: New

** Affects: initramfs-tools (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: maas-ipv6

** Package changed: klibc (Ubuntu) => initramfs-tools (Ubuntu)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to klibc in Ubuntu.
https://bugs.launchpad.net/bugs/1632804

Title:
  ROUNDTTT in configure_networking is effectively ignored

Status in MAAS:
  New
Status in initramfs-tools package in Ubuntu:
  New

Bug description:
  With the changes from Bug #1621507, ROUNDTTT is effectively ignored.

  The loop checks only for the existence of /run/net-${DEVICE}.conf, and
  the dhclient scripts ALWAYS (even on failure) create it, it will try
  to get a lease exactly once before bailing out. Ideally, if both ipv4
  and ipv6 are present on the vlan, then both would be configured and
  (as is done) present in the net-$DEV.conf file.  Generally speaking
  (and why we didn't notice this in testing..), dhclient gets a lease on
  the first pass.

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1632804/+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

[Touch-packages] [Bug 1621507] Re: initramfs-tools configure_networking() fails to dhcp ipv6 addresses

[LaMont Jones]

After looking into this more (and working on Bug #1629972 some), there
are couple of issues with the new configure_networking:

1. since it checks only for the existence of /run/net-${DEVICE}.conf,
and the dhclient scripts ALWAYS (even on failure) create it, it will try
to get a lease exactly once before bailing out.  Ideally, if both ipv4
and ipv6 are present on the vlan, then both would be configured and (as
is done) present in the net-$DEV.conf file.

2. Since router-advertisements are needed for the on-link indication
(and routes), ipv6 configuration via dhcp should wait until such time as
there is at least a (non-fe80) route for some ipv6 cidr on $DEVICE
(which RA should create).  This will eliminate the iscsi-timeout errors
that we see when configure_networking() returns before RA configures
routing.  Note that a default route is not necessary.  Note also that it
should timeout on the RA if it doesn't show up in a reasonable time,
complain that it got no RA, and then _not_ bring up ipv6 on the
interface (RA is required, as per Bug #1609898)

** Tags removed: verification-pending
** Tags added: verification-failed

-- 
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 Released
Status in initramfs-tools package in Ubuntu:
  Fix Released
Status in isc-dhcp package in Ubuntu:
  Fix Released
Status in klibc package in Ubuntu:
  Won't Fix
Status in open-iscsi package in Ubuntu:
  Fix Released
Status in initramfs-tools source package in Xenial:
  Fix Released
Status in isc-dhcp source package in Xenial:
  Fix Released
Status in klibc source package in Xenial:
  Won't Fix
Status in open-iscsi source package in Xenial:
  Fix Released
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

  [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

[Touch-packages] [Bug 1629972] Re: networking stop incorrectly disconnects from (network) root filesystem

[LaMont Jones]

ifupdown is actually behaving correctly in this case.  It's likely that
cloud-initramfs-tools should be marking the interface "iface foo inet[6]
manual" in every case, since that's the indicator that seems to prevent
ifdown from downing the interface.

When I had it do that, what I then found was that we had gotten to
"reached shutdown target", and the system was then having timeouts in
systemd watchdogs.  Looking at it with systemd's debug shell, /media
/root-ro (the iscsi volume) has been unmounted, and /media/root-rw (the
overlayfs) is still mounted.

Interestingly, the last few things are:

[  OK  ] Unmounted /media/root-rw.
[  OK  ] Reached target Unmount All Filesystems.
[  OK  ] Stopped target Local File Systems (Pre).
 Stopped Monitoring of LVM2 mirrors, snapshots etc.  using dmeventd or 
progress polling...
[  OK  ] Stopped Remount Root and Kernel File Systems
[  OK  ] Stopped Create Static Device Nodes in /dev.
[  OK  ] Reached target Shutdown

5 seconds later is the "connection 1:0: ping timeout of 5 secs expired, 
and / is still (or is that "again") mounted on overlayfs 
rw,relatime,lowerdir=/media/root-ro,upperdir=/media/root-rw//overlay,workdir=/media/root-rw//overlay-workdir

And then there is the collection of "INFO: task systemd:1 blocked for
more than 120 seconds." log entries on the console.

** Changed in: ifupdown (Ubuntu)
 Assignee: LaMont Jones (lamont) => (unassigned)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ifupdown in Ubuntu.
https://bugs.launchpad.net/bugs/1629972

Title:
  networking stop incorrectly disconnects from (network) root filesystem

Status in MAAS:
  Triaged
Status in ifupdown package in Ubuntu:
  New
Status in ifupdown source package in Xenial:
  New

Bug description:
  With the switch to systemd, all support for iscsi root (and other)
  filesystems disappeared, since shutdown yanks the rug out from under
  us.

  Rather than just relying on /etc/iscsi/iscsi.initramfs (which d-i
  creates..), the DEV check should be expanded to include iscsi devices,
  and networking.service ExecStop should honor those checks.

  Related bugs:
* bug 1229458: grub2 needed changes
* bug 1621615: network not configured when ipv6 netbooted into cloud-init
* bug 1621507: ipv6 network boot does not work

  [Impact]

  With the changes from the above, the iscsi root (at least in the ipv6
  case) gets disconneceted prior to clean shutdown (ifdown downs the
  interface), resulting in a failure to enlist, commission, or deploy
  cleanly under MAAS. (and a failure to cleanly unmount the root
  filesystem when it is over iscsi.)

  [Test Case]

  Given a MAAS 2.0 installation, and the packages in the other bugs,
  attempt to enlist, commission, or deploy a host with xenial.

  [Regression potential]

  This restores the pre-xenial behavior of not shutting down the
  interface if there are network drives at the time that neworking is
  stopped (making it a no-op.)  The additional change is to detect
  "/dev/disk/by-path/*-iscsi-*" as a network disk, replacing the check
  for the existence of /etc/iscsi/iscsi.initramfs, which was only
  created by debian-installer (and maas until recently).

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1629972/+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

[Touch-packages] [Bug 1621507] Re: initramfs-tools configure_networking() fails to dhcp ipv6 addresses

[LaMont Jones]

** Tags removed: verification-done
** Tags added: verification-pending

-- 
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 Released
Status in initramfs-tools package in Ubuntu:
  Fix Released
Status in isc-dhcp package in Ubuntu:
  Fix Released
Status in klibc package in Ubuntu:
  Won't Fix
Status in open-iscsi package in Ubuntu:
  Fix Released
Status in initramfs-tools source package in Xenial:
  Fix Released
Status in isc-dhcp source package in Xenial:
  Fix Released
Status in klibc source package in Xenial:
  Won't Fix
Status in open-iscsi source package in Xenial:
  Fix Released
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

  [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

[Touch-packages] [Bug 1632096] Re: dhclient-script does not respect ip6_prefixlen

[LaMont Jones]

*** This bug is a duplicate of bug 1609898 ***
https://bugs.launchpad.net/bugs/1609898

The DHCP v6 protocol does not include prefixlen: On-link indication
comes from router-advertisements, only.

So it's not so much that the script is ignoring it, as it is that
dhclient is making up answers.

** This bug has been marked a duplicate of bug 1609898
   dhclient incorrectly assumes a /64 ipv6 prefix

-- 
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/1632096

Title:
  dhclient-script does not respect ip6_prefixlen

Status in isc-dhcp package in Ubuntu:
  New

Bug description:
  /sbin/dhclient-script does not seem to pay any attention to the prefixlen 
that is provided.
  The result is that:
  $ dhclient -6 -1 -v eth0
  results in network configuration like this:

  
  2: eth0:  mtu 1500 qdisc pfifo_fast qlen 1000
  link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
  inet6 fd42:83bb:a360:8010:2527:abdf:95cb:5e55/128 scope global 
 valid_lft forever preferred_lft forever
  inet6 fe80::5054:ff:fe12:3456/64 scope link 
 valid_lft forever preferred_lft forever

  when it should have a /64 on the fd42 address, and subsequently no
  ability to reach other hosts on that network.

  The fix seems simple enough:
ip -6 addr add ${new_ip6_address}${new_ip6_prefixlen:+/${new_ip6_prefixlen}}
   dev ${interface} scope global

  Ie, we just have to add '/${new_ip6_prefixlen}' if it is set.

  
  This link seems relevant:

  https://kb.isc.org/article/AA-01141/0/How-to-workaround-IPv6-prefix-
  length-issues-with-ISC-DHCP-clients.html

  ProblemType: Bug
  DistroRelease: Ubuntu 16.10
  Package: isc-dhcp-client 4.3.3-5ubuntu15
  ProcVersionSignature: Ubuntu 4.8.0-17.19-generic 4.8.0-rc7
  Uname: Linux 4.8.0-17-generic x86_64
  NonfreeKernelModules: zfs zunicode zcommon znvpair zavl
  ApportVersion: 2.20.3-0ubuntu7
  Architecture: amd64
  Date: Mon Oct 10 20:23:42 2016
  DhclientLeases:
   
  JournalErrors:
   Error: command ['journalctl', '-b', '--priority=warning', '--lines=1000'] 
failed with exit code 1: Hint: You are currently not seeing messages from other 
users and the system.
 Users in the 'systemd-journal' group can see all messages. Pass -q to
 turn off this notice.
   No journal files were opened due to insufficient permissions.
  ProcEnviron:
   TERM=screen-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: isc-dhcp
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1632096/+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

[Touch-packages] [Bug 1621507] Re: initramfs-tools configure_networking() fails to dhcp ipv6 addresses

[LaMont Jones]

This was resolved by switching away from klibc's ipconfig

** Changed in: klibc (Ubuntu)
   Status: Confirmed => Won't Fix

-- 
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 Released
Status in initramfs-tools package in Ubuntu:
  Fix Released
Status in isc-dhcp package in Ubuntu:
  Fix Released
Status in klibc package in Ubuntu:
  Won't Fix
Status in open-iscsi package in Ubuntu:
  Fix Released
Status in initramfs-tools source package in Xenial:
  Fix Released
Status in isc-dhcp source package in Xenial:
  Fix Released
Status in klibc source package in Xenial:
  Won't Fix
Status in open-iscsi source package in Xenial:
  Fix Released
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

  [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

[Touch-packages] [Bug 1621507] Re: initramfs-tools configure_networking() fails to dhcp ipv6 addresses

[LaMont Jones]

This was resolved by switching away from klibc's ipconfig

** Changed in: klibc (Ubuntu Xenial)
   Status: Confirmed => Won't Fix

-- 
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 Released
Status in initramfs-tools package in Ubuntu:
  Fix Released
Status in isc-dhcp package in Ubuntu:
  Fix Released
Status in klibc package in Ubuntu:
  Won't Fix
Status in open-iscsi package in Ubuntu:
  Fix Released
Status in initramfs-tools source package in Xenial:
  Fix Released
Status in isc-dhcp source package in Xenial:
  Fix Released
Status in klibc source package in Xenial:
  Won't Fix
Status in open-iscsi source package in Xenial:
  Fix Released
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

  [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

[Touch-packages] [Bug 1631010] [NEW] please add a cmdline option to chose between ipv4, ipv6, or dual-stack network boot

[LaMont Jones]

Public bug reported:

Right now, I can boot with "ip=hostname:BOOTIF" in the kernel
commandline, and (after bug 1621507), I get whatever it came up with for
ipv4 and ipv6.  If for nothing more than testing on a dual-stack
environment, it would be nice to be able to force that to try both
(current behavior, and an excellent default), only try IPv4, or only
IPv6.

NOT something that needs to be fixed before yakkety, but would be nice
to eventually get back to xenial.

** Affects: initramfs-tools (Ubuntu)
 Importance: Wishlist
 Status: New

** Changed in: initramfs-tools (Ubuntu)
   Importance: Undecided => Wishlist

-- 
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/1631010

Title:
  please add a cmdline option to chose between ipv4, ipv6, or dual-stack
  network boot

Status in initramfs-tools package in Ubuntu:
  New

Bug description:
  Right now, I can boot with "ip=hostname:BOOTIF" in the kernel
  commandline, and (after bug 1621507), I get whatever it came up with
  for ipv4 and ipv6.  If for nothing more than testing on a dual-stack
  environment, it would be nice to be able to force that to try both
  (current behavior, and an excellent default), only try IPv4, or only
  IPv6.

  NOT something that needs to be fixed before yakkety, but would be nice
  to eventually get back to xenial.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1631010/+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

[Touch-packages] [Bug 1629972] Re: networking stop incorrectly disconnects from (network) root filesystem

[LaMont Jones]

** Description changed:

  With the switch to systemd, all support for iscsi root (and other)
  filesystems disappeared, since shutdown yanks the rug out from under us.
  
  Rather than just relying on /etc/iscsi/iscsi.initramfs (which d-i
  creates..), the DEV check should be expanded to include iscsi devices,
  and networking.service ExecStop should honor those checks.
+ 
+ Related bugs:
+   * bug 1229458: grub2 needed changes
+   * bug 1621615: network not configured when ipv6 netbooted into cloud-init
+   * bug 1621507: ipv6 network boot does not work
+ 
+ [Impact]
+ 
+ With the changes from the above, the iscsi root (at least in the ipv6
+ case) gets disconneceted prior to clean shutdown (ifdown downs the
+ interface), resulting in a failure to enlist, commission, or deploy
+ cleanly under MAAS. (and a failure to cleanly unmount the root
+ filesystem when it is over iscsi.)
+ 
+ [Test Case]
+ 
+ Given a MAAS 2.0 installation, and the packages in the other bugs,
+ attempt to enlist, commission, or deploy a host with xenial.
+ 
+ [Regression potential]
+ 
+ This restores the pre-xenial behavior of not shutting down the interface
+ if there are network drives at the time that neworking is stopped
+ (making it a no-op.)  The additional change is to detect "/dev/disk/by-
+ path/*-iscsi-*" as a network disk, replacing the check for the existence
+ of /etc/iscsi/iscsi.initramfs, which was only created by debian-
+ installer (and maas until recently).

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ifupdown in Ubuntu.
https://bugs.launchpad.net/bugs/1629972

Title:
  networking stop incorrectly disconnects from (network) root filesystem

Status in MAAS:
  New
Status in ifupdown package in Ubuntu:
  New
Status in ifupdown source package in Xenial:
  New

Bug description:
  With the switch to systemd, all support for iscsi root (and other)
  filesystems disappeared, since shutdown yanks the rug out from under
  us.

  Rather than just relying on /etc/iscsi/iscsi.initramfs (which d-i
  creates..), the DEV check should be expanded to include iscsi devices,
  and networking.service ExecStop should honor those checks.

  Related bugs:
* bug 1229458: grub2 needed changes
* bug 1621615: network not configured when ipv6 netbooted into cloud-init
* bug 1621507: ipv6 network boot does not work

  [Impact]

  With the changes from the above, the iscsi root (at least in the ipv6
  case) gets disconneceted prior to clean shutdown (ifdown downs the
  interface), resulting in a failure to enlist, commission, or deploy
  cleanly under MAAS. (and a failure to cleanly unmount the root
  filesystem when it is over iscsi.)

  [Test Case]

  Given a MAAS 2.0 installation, and the packages in the other bugs,
  attempt to enlist, commission, or deploy a host with xenial.

  [Regression potential]

  This restores the pre-xenial behavior of not shutting down the
  interface if there are network drives at the time that neworking is
  stopped (making it a no-op.)  The additional change is to detect
  "/dev/disk/by-path/*-iscsi-*" as a network disk, replacing the check
  for the existence of /etc/iscsi/iscsi.initramfs, which was only
  created by debian-installer (and maas until recently).

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1629972/+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

[Touch-packages] [Bug 1621507] Re: initramfs-tools configure_networking() fails to dhcp ipv6 addresses

[LaMont Jones]

** No longer affects: ifupdown (Ubuntu)

** No longer affects: ifupdown (Ubuntu Xenial)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ifupdown in Ubuntu.
https://bugs.launchpad.net/bugs/1621507

Title:
  initramfs-tools configure_networking() fails to dhcp ipv6 addresses

Status in MAAS:
  Triaged
Status in initramfs-tools package in Ubuntu:
  Fix Released
Status in isc-dhcp package in Ubuntu:
  Fix Released
Status in klibc package in Ubuntu:
  Confirmed
Status in open-iscsi package in Ubuntu:
  Fix Committed
Status in initramfs-tools source package in Xenial:
  Fix Committed
Status in isc-dhcp source package in Xenial:
  Fix Released
Status in klibc source package in Xenial:
  Confirmed
Status in open-iscsi source package in Xenial:
  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

  [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

[Touch-packages] [Bug 1629972] [NEW] networking stop incorrectly disconnects from (network) root filesystem

[LaMont Jones]

Public bug reported:

With the switch to systemd, all support for iscsi root (and other)
filesystems disappeared, since shutdown yanks the rug out from under us.

Rather than just relying on /etc/iscsi/iscsi.initramfs (which d-i
creates..), the DEV check should be expanded to include iscsi devices,
and networking.service ExecStop should honor those checks.

** Affects: maas
 Importance: Undecided
 Status: New

** Affects: ifupdown (Ubuntu)
 Importance: Undecided
 Assignee: LaMont Jones (lamont)
 Status: New

** Affects: ifupdown (Ubuntu Xenial)
 Importance: Undecided
 Status: New


** Tags: maas-ipv6

** Also affects: maas
   Importance: Undecided
   Status: New

** Also affects: ifupdown (Ubuntu Xenial)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ifupdown in Ubuntu.
https://bugs.launchpad.net/bugs/1629972

Title:
  networking stop incorrectly disconnects from (network) root filesystem

Status in MAAS:
  New
Status in ifupdown package in Ubuntu:
  New
Status in ifupdown source package in Xenial:
  New

Bug description:
  With the switch to systemd, all support for iscsi root (and other)
  filesystems disappeared, since shutdown yanks the rug out from under
  us.

  Rather than just relying on /etc/iscsi/iscsi.initramfs (which d-i
  creates..), the DEV check should be expanded to include iscsi devices,
  and networking.service ExecStop should honor those checks.

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1629972/+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

[Touch-packages] [Bug 1621507] Re: initramfs-tools configure_networking() fails to dhcp ipv6 addresses

[LaMont Jones]

** Changed in: open-iscsi (Ubuntu)
 Assignee: LaMont Jones (lamont) => (unassigned)

-- 
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:
  Triaged
Status in ifupdown package in Ubuntu:
  New
Status in initramfs-tools package in Ubuntu:
  Fix Released
Status in isc-dhcp package in Ubuntu:
  Fix Released
Status in klibc package in Ubuntu:
  Confirmed
Status in open-iscsi package in Ubuntu:
  Fix Committed
Status in ifupdown source package in Xenial:
  New
Status in initramfs-tools source package in Xenial:
  Fix Committed
Status in isc-dhcp source package in Xenial:
  Fix Released
Status in klibc source package in Xenial:
  Confirmed
Status in open-iscsi source package in Xenial:
  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

  [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

[Touch-packages] [Bug 1621507] Re: initramfs-tools configure_networking() fails to dhcp ipv6 addresses

[LaMont Jones]

** Also affects: ifupdown (Ubuntu)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ifupdown in Ubuntu.
https://bugs.launchpad.net/bugs/1621507

Title:
  initramfs-tools configure_networking() fails to dhcp ipv6 addresses

Status in MAAS:
  Triaged
Status in ifupdown package in Ubuntu:
  New
Status in initramfs-tools package in Ubuntu:
  Fix Released
Status in isc-dhcp package in Ubuntu:
  Fix Released
Status in klibc package in Ubuntu:
  Confirmed
Status in open-iscsi package in Ubuntu:
  Fix Committed
Status in initramfs-tools source package in Xenial:
  Fix Committed
Status in isc-dhcp source package in Xenial:
  Fix Released
Status in klibc source package in Xenial:
  Confirmed
Status in open-iscsi source package in Xenial:
  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

  [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

[Touch-packages] [Bug 1609898] Re: dhclient incorrectly assumes a /64 ipv6 prefix

[LaMont Jones]

After further checking, comcast is sending them, my machine is just not
seeing them...  Will file a separate bug.

-- 
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/1609898

Title:
  dhclient incorrectly assumes a /64 ipv6 prefix

Status in isc-dhcp package in Ubuntu:
  Fix Released
Status in network-manager package in Ubuntu:
  Fix Released
Status in isc-dhcp source package in Precise:
  Fix Released
Status in network-manager source package in Precise:
  Invalid
Status in isc-dhcp source package in Trusty:
  Fix Released
Status in network-manager source package in Trusty:
  Triaged
Status in isc-dhcp source package in Xenial:
  Fix Released
Status in network-manager source package in Xenial:
  Fix Committed
Status in isc-dhcp source package in Yakkety:
  Fix Released
Status in network-manager source package in Yakkety:
  Fix Released
Status in isc-dhcp package in Debian:
  Fix Released

Bug description:
  [Impact]

  clients who get an ipv6 address from a dhcpv6 server assume the
  address has a /64 prefix, but that is not necessarily true, and if the
  subnet is different than /64 those clients will not be able to reach
  other addresses in that /64 prefix because the other systems are not
  on-link.  This /64 assumption of dhclient effectively breaks the
  client networking for certain addresses.

  [Test Case]

  Set up a server with two interface nics, and one client connected to
  each of those interfaces.  On the server, set up a ipv6 subnet on each
  interface, with a larger prefix than /64, e.g.:

  2001:db8:0:0:1::/96
  2001:db8:0:0:2::/96

  configure dhcpv6 on the server, to provide ipv6 addresses on each
  interface.  Set the server as the default ipv6 route for the clients.

  Allow the clients to get dhcpv6 ipv6 addresses from the server.  The
  clients will each get a ipv6 address with a /64 prefix, due to the bug
  in dhclient.

  Try to ping (or otherwise communicate) between the clients.  Since
  they have /64 prefixes, they think they are on-link with each other,
  but they are not, so they can't communicate.

  After the dhclient bug is fixed, repeat the above setup, and the
  clients will get /128 prefixes instead, and then will be able to
  communicate with each other, because they will route the traffic to
  each other through the server.

  [Regression Potential]

  Non-standard (i.e. not /64) subnets served by dhcpv6 currently are
  broken, this fixes that.

  However, any ipv6 network configurations that rely on the previous
  incorrect assumed /64 behavior (as described here:
  https://tools.ietf.org/html/rfc5942#section-5) in order to allow
  dhcpv6 clients to communicate with other systems inside the subnet,
  but do not use RA to also provide clients with the actual prefix len,
  will break.

  To clarify: a server that provides clients with dhcpv6 addresses, but
  does not also provide the prefix len via RA, will change behavior;
  previously, all clients on the subnet could talk directly to each
  other, with this update the clients cannot talk to each other
  directly; all traffic between clients will be routed through the
  default gateway.

  Further, if the network does not provide a default gateway - for
  example a local network that is intended only for traffic between
  local servers - the clients will not be able to talk to each other at
  all.

  Note that such configurations *are* broken configurations, that just
  happened to work before because of incorrect dhcp client behavior;
  such configurations must be updated to perform RA to provide the
  prefix len to clients.

  See comment 30 for details on how to configure radvd to restore
  network functionality.

  [Other Info]

  This is fixed in debian:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684009

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1609898/+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

[Touch-packages] [Bug 1609898] Re: dhclient incorrectly assumes a /64 ipv6 prefix

[LaMont Jones]

I have confirmed that the machine is accepting router advertisements,
and that comcast is not sending them.

-- 
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/1609898

Title:
  dhclient incorrectly assumes a /64 ipv6 prefix

Status in isc-dhcp package in Ubuntu:
  Fix Released
Status in network-manager package in Ubuntu:
  Fix Released
Status in isc-dhcp source package in Precise:
  Fix Released
Status in network-manager source package in Precise:
  Invalid
Status in isc-dhcp source package in Trusty:
  Fix Released
Status in network-manager source package in Trusty:
  Triaged
Status in isc-dhcp source package in Xenial:
  Fix Released
Status in network-manager source package in Xenial:
  Fix Committed
Status in isc-dhcp source package in Yakkety:
  Fix Released
Status in network-manager source package in Yakkety:
  Fix Released
Status in isc-dhcp package in Debian:
  Fix Released

Bug description:
  [Impact]

  clients who get an ipv6 address from a dhcpv6 server assume the
  address has a /64 prefix, but that is not necessarily true, and if the
  subnet is different than /64 those clients will not be able to reach
  other addresses in that /64 prefix because the other systems are not
  on-link.  This /64 assumption of dhclient effectively breaks the
  client networking for certain addresses.

  [Test Case]

  Set up a server with two interface nics, and one client connected to
  each of those interfaces.  On the server, set up a ipv6 subnet on each
  interface, with a larger prefix than /64, e.g.:

  2001:db8:0:0:1::/96
  2001:db8:0:0:2::/96

  configure dhcpv6 on the server, to provide ipv6 addresses on each
  interface.  Set the server as the default ipv6 route for the clients.

  Allow the clients to get dhcpv6 ipv6 addresses from the server.  The
  clients will each get a ipv6 address with a /64 prefix, due to the bug
  in dhclient.

  Try to ping (or otherwise communicate) between the clients.  Since
  they have /64 prefixes, they think they are on-link with each other,
  but they are not, so they can't communicate.

  After the dhclient bug is fixed, repeat the above setup, and the
  clients will get /128 prefixes instead, and then will be able to
  communicate with each other, because they will route the traffic to
  each other through the server.

  [Regression Potential]

  Non-standard (i.e. not /64) subnets served by dhcpv6 currently are
  broken, this fixes that.

  However, any ipv6 network configurations that rely on the previous
  incorrect assumed /64 behavior (as described here:
  https://tools.ietf.org/html/rfc5942#section-5) in order to allow
  dhcpv6 clients to communicate with other systems inside the subnet,
  but do not use RA to also provide clients with the actual prefix len,
  will break.

  To clarify: a server that provides clients with dhcpv6 addresses, but
  does not also provide the prefix len via RA, will change behavior;
  previously, all clients on the subnet could talk directly to each
  other, with this update the clients cannot talk to each other
  directly; all traffic between clients will be routed through the
  default gateway.

  Further, if the network does not provide a default gateway - for
  example a local network that is intended only for traffic between
  local servers - the clients will not be able to talk to each other at
  all.

  Note that such configurations *are* broken configurations, that just
  happened to work before because of incorrect dhcp client behavior;
  such configurations must be updated to perform RA to provide the
  prefix len to clients.

  See comment 30 for details on how to configure radvd to restore
  network functionality.

  [Other Info]

  This is fixed in debian:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684009

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1609898/+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

[Touch-packages] [Bug 1609898] Re: dhclient incorrectly assumes a /64 ipv6 prefix

[LaMont Jones]

With this fix, my IPv6 service from Comcast broke.

Specifically, they hand out an IP on the /64 via dhcpv6, with the
default gateway being an IP on the same /64, along with an IA /56 for
the customer to use locally.

Adding the default route fails because there is no route to said gateway
(since we have decided that we have a /128).

-- 
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/1609898

Title:
  dhclient incorrectly assumes a /64 ipv6 prefix

Status in isc-dhcp package in Ubuntu:
  Fix Released
Status in network-manager package in Ubuntu:
  Fix Released
Status in isc-dhcp source package in Precise:
  Fix Released
Status in network-manager source package in Precise:
  Invalid
Status in isc-dhcp source package in Trusty:
  Fix Released
Status in network-manager source package in Trusty:
  Triaged
Status in isc-dhcp source package in Xenial:
  Fix Released
Status in network-manager source package in Xenial:
  Fix Committed
Status in isc-dhcp source package in Yakkety:
  Fix Released
Status in network-manager source package in Yakkety:
  Fix Released
Status in isc-dhcp package in Debian:
  Fix Released

Bug description:
  [Impact]

  clients who get an ipv6 address from a dhcpv6 server assume the
  address has a /64 prefix, but that is not necessarily true, and if the
  subnet is different than /64 those clients will not be able to reach
  other addresses in that /64 prefix because the other systems are not
  on-link.  This /64 assumption of dhclient effectively breaks the
  client networking for certain addresses.

  [Test Case]

  Set up a server with two interface nics, and one client connected to
  each of those interfaces.  On the server, set up a ipv6 subnet on each
  interface, with a larger prefix than /64, e.g.:

  2001:db8:0:0:1::/96
  2001:db8:0:0:2::/96

  configure dhcpv6 on the server, to provide ipv6 addresses on each
  interface.  Set the server as the default ipv6 route for the clients.

  Allow the clients to get dhcpv6 ipv6 addresses from the server.  The
  clients will each get a ipv6 address with a /64 prefix, due to the bug
  in dhclient.

  Try to ping (or otherwise communicate) between the clients.  Since
  they have /64 prefixes, they think they are on-link with each other,
  but they are not, so they can't communicate.

  After the dhclient bug is fixed, repeat the above setup, and the
  clients will get /128 prefixes instead, and then will be able to
  communicate with each other, because they will route the traffic to
  each other through the server.

  [Regression Potential]

  Non-standard (i.e. not /64) subnets served by dhcpv6 currently are
  broken, this fixes that.

  However, any ipv6 network configurations that rely on the previous
  incorrect assumed /64 behavior (as described here:
  https://tools.ietf.org/html/rfc5942#section-5) in order to allow
  dhcpv6 clients to communicate with other systems inside the subnet,
  but do not use RA to also provide clients with the actual prefix len,
  will break.

  To clarify: a server that provides clients with dhcpv6 addresses, but
  does not also provide the prefix len via RA, will change behavior;
  previously, all clients on the subnet could talk directly to each
  other, with this update the clients cannot talk to each other
  directly; all traffic between clients will be routed through the
  default gateway.

  Further, if the network does not provide a default gateway - for
  example a local network that is intended only for traffic between
  local servers - the clients will not be able to talk to each other at
  all.

  Note that such configurations *are* broken configurations, that just
  happened to work before because of incorrect dhcp client behavior;
  such configurations must be updated to perform RA to provide the
  prefix len to clients.

  See comment 30 for details on how to configure radvd to restore
  network functionality.

  [Other Info]

  This is fixed in debian:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684009

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1609898/+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

[Touch-packages] [Bug 1621507] Re: initramfs-tools configure_networking() fails to dhcp ipv6 addresses

[LaMont Jones]

** Description changed:

- 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
- 
- Anyone wanting to netboot in an ipv6-only environment is affected.
+ 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 1621615: network not configured when ipv6 netbooted into cloud-init
+   * bug 1229458: grub2 needed changes
+   * bug 1621615: network not configured when ipv6 netbooted into cloud-init
+ 
+ [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.

-- 
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:
  Confirmed
Status in initramfs-tools package in Ubuntu:
  In Progress
Status in isc-dhcp package in Ubuntu:
  In Progress
Status in klibc package in Ubuntu:
  New
Status in open-iscsi package in Ubuntu:
  Fix Committed
Status in initramfs-tools source package in Xenial:
  New
Status in isc-dhcp source package in Xenial:
  Fix Committed
Status in klibc source package in Xenial:
  New
Status in open-iscsi source package in Xenial:
  New
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

  [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

[Touch-packages] [Bug 1621507] Re: initramfs-tools configure_networking() fails to dhcp ipv6 addresses

[LaMont Jones]

iproute2 turns out to be not needed for this.

** No longer affects: iproute2 (Ubuntu)

** No longer affects: iproute2 (Ubuntu Xenial)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to iproute2 in Ubuntu.
https://bugs.launchpad.net/bugs/1621507

Title:
  initramfs-tools configure_networking() fails to dhcp ipv6 addresses

Status in MAAS:
  Confirmed
Status in initramfs-tools package in Ubuntu:
  In Progress
Status in isc-dhcp package in Ubuntu:
  In Progress
Status in klibc package in Ubuntu:
  New
Status in open-iscsi package in Ubuntu:
  Fix Committed
Status in initramfs-tools source package in Xenial:
  New
Status in isc-dhcp source package in Xenial:
  New
Status in klibc source package in Xenial:
  New
Status in open-iscsi source package in Xenial:
  New
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

  Anyone wanting to netboot in an ipv6-only environment is affected.

  Related bugs:
* bug 1621615: network not configured when ipv6 netbooted into cloud-init

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

[Touch-packages] [Bug 1621507] Re: initramfs-tools configure_networking() fails to dhcp ipv6 addresses

[LaMont Jones]

open-iscsi's part of this is fixed in open-
iscsi_2.0.873+git0.3b4b4500-14ubuntu4

** Changed in: open-iscsi (Ubuntu)
   Status: New => Fix Committed

** Also affects: initramfs-tools (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: klibc (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: open-iscsi (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: isc-dhcp (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: iproute2 (Ubuntu Xenial)
   Importance: Undecided
   Status: New

-- 
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:
  Confirmed
Status in initramfs-tools package in Ubuntu:
  In Progress
Status in iproute2 package in Ubuntu:
  New
Status in isc-dhcp package in Ubuntu:
  In Progress
Status in klibc package in Ubuntu:
  New
Status in open-iscsi package in Ubuntu:
  Fix Committed
Status in initramfs-tools source package in Xenial:
  New
Status in iproute2 source package in Xenial:
  New
Status in isc-dhcp source package in Xenial:
  New
Status in klibc source package in Xenial:
  New
Status in open-iscsi source package in Xenial:
  New
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

  Anyone wanting to netboot in an ipv6-only environment is affected.

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

[Touch-packages] [Bug 1621507] Re: initramfs-tools configure_networking() fails to dhcp ipv6 addresses

[LaMont Jones]

** Also affects: iproute2 (Ubuntu)
   Importance: Undecided
   Status: New

** Also affects: open-iscsi (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: open-iscsi (Ubuntu)
 Assignee: (unassigned) => LaMont Jones (lamont)

** Changed in: iproute2 (Ubuntu)
 Assignee: (unassigned) => Mathieu Trudel-Lapierre (cyphermox)

-- 
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:
  Confirmed
Status in initramfs-tools package in Ubuntu:
  In Progress
Status in iproute2 package in Ubuntu:
  New
Status in isc-dhcp package in Ubuntu:
  In Progress
Status in klibc package in Ubuntu:
  New
Status in open-iscsi package in Ubuntu:
  New
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

  Anyone wanting to netboot in an ipv6-only environment is affected.

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

[Touch-packages] [Bug 1621507] Re: ipconfig lacks ipv6 support

[LaMont Jones]

** Summary changed:

- ipconfig lacks ipv6 support
+ initramfs-tools configure_networking() fails to dhcp ipv6 addresses

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to klibc in Ubuntu.
https://bugs.launchpad.net/bugs/1621507

Title:
  initramfs-tools configure_networking() fails to dhcp ipv6 addresses

Status in MAAS:
  Confirmed
Status in initramfs-tools package in Ubuntu:
  New
Status in klibc package in Ubuntu:
  New
Status in klibc package in Debian:
  Unknown

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

  Anyone wanting to netboot in an ipv6-only environment is affected.

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

[Touch-packages] [Bug 1621507] Re: ipconfig lacks ipv6 support

[LaMont Jones]

** Also affects: initramfs-tools (Ubuntu)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to klibc in Ubuntu.
https://bugs.launchpad.net/bugs/1621507

Title:
  ipconfig lacks ipv6 support

Status in MAAS:
  Confirmed
Status in initramfs-tools package in Ubuntu:
  New
Status in klibc package in Ubuntu:
  New
Status in klibc package in Debian:
  Unknown

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

  Anyone wanting to netboot in an ipv6-only environment is affected.

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

[Touch-packages] [Bug 1621507] [NEW] ipconfig lacks ipv6 support

[LaMont Jones]

Public bug reported:

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

Anyone wanting to netboot in an ipv6-only environment is affected.

** Affects: klibc (Ubuntu)
 Importance: Undecided
 Status: New

** Affects: klibc (Debian)
 Importance: Unknown
 Status: Unknown

** Bug watch added: Debian Bug tracker #627164
   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=627164

** Also affects: klibc (Debian) via
   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=627164
   Importance: Unknown
   Status: Unknown

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to klibc in Ubuntu.
https://bugs.launchpad.net/bugs/1621507

Title:
  ipconfig lacks ipv6 support

Status in klibc package in Ubuntu:
  New
Status in klibc package in Debian:
  Unknown

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

  Anyone wanting to netboot in an ipv6-only environment is affected.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/klibc/+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

[Touch-packages] [Bug 1447715] Re: dhclient -6: Can't bind to dhcp address: Cannot assign requested address

[LaMont Jones]

Better yet, have dhclient retry that bind call itself, at least for a
short while, before throwing an error.

-- 
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/1447715

Title:
  dhclient -6: Can't bind to dhcp address: Cannot assign requested
  address

Status in DHCP:
  New
Status in isc-dhcp package in Ubuntu:
  Confirmed

Bug description:
  After upgrading to Ubuntu 15.04 my computer is unable to obtain an
  IPv6 address via DHCPv6. The root cause is that dhclient is exiting
  with the following message:

  -
  Can't bind to dhcp address: Cannot assign requested address
  Please make sure there is no other dhcp server
  running and that there's no entry for dhcp or
  bootp in /etc/inetd.conf.   Also make sure you
  are not running HP JetAdmin software, which
  includes a bootp server.

  If you think you have received this message due to a bug rather
  than a configuration issue please read the section on submitting
  bugs on either our web page at www.isc.org or in the README file
  before submitting a bug.  These pages explain the proper
  process and the information we find helpful for debugging..

  exiting.
  -

  The problem seems to exist in isc-dhcp-client 4.3.1-5ubuntu2 (15.04
  version) because downgrading to isc-dhcp-client 4.2.4-7ubuntu14 (14.10
  version) allows me to obtain an address.

  NetworkManager is the one launching dhclient. The two invocations (one
  for IPv4 and one for IPv6) are:

  dhclient_start(): running: /sbin/dhclient -d -q -sf
  /usr/lib/NetworkManager/nm-dhcp-helper -pf /run/sendsigs.omit.d
  /network-manager.dhclient-eth0.pid -lf /var/lib/NetworkManager
  /dhclient-c0a3dfde-5c0b-4cef-9c3b-563cfb1fb9d2-eth0.lease -cf
  /var/lib/NetworkManager/dhclient-eth0.conf eth0

  dhclient_start(): running: /sbin/dhclient -d -q -6 -N -sf
  /usr/lib/NetworkManager/nm-dhcp-helper -pf /run/sendsigs.omit.d
  /network-manager.dhclient6-eth0.pid -lf
  /var/lib/NetworkManager/dhclient6-c0a3dfde-5c0b-4cef-9c3b-
  563cfb1fb9d2-eth0.lease -cf
  /var/lib/NetworkManager/dhclient6-eth0.conf eth0

  I do not see anything suspicious with the way both dhclients are
  invoked.

  Given that a downgrade allows me to obtain an IPv6 address I think
  this might be a bug in the ISC DHCP client rather than in
  NetworkManager.

To manage notifications about this bug go to:
https://bugs.launchpad.net/dhcp/+bug/1447715/+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

[Touch-packages] [Bug 1240757] Re: Bridge not created if bind9 is on

[LaMont Jones]

** Changed in: bind9 (Ubuntu)
Milestone: None => xenial-updates

** Changed in: bind9 (Ubuntu)
 Assignee: (unassigned) => LaMont Jones (lamont)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1240757

Title:
  Bridge not created if bind9 is on

Status in bind9 package in Ubuntu:
  Confirmed
Status in lxc package in Ubuntu:
  Confirmed
Status in lxd package in Ubuntu:
  Confirmed

Bug description:
  LXC will not create the lxcbr0 bridge if bind9 is on, as it can not
  take the 10.0.3.1 address. If bind9 is stopped, then LXC successfully
  creates the bridge.

  Expected result: LXC will create the bridge, even if bind9 is on.
  --- 
  ApportVersion: 2.9.2-0ubuntu8.3
  Architecture: i386
  DistroRelease: Ubuntu 13.04
  InstallationDate: Installed on 2013-06-29 (110 days ago)
  InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Release i386 (20130424)
  MarkForUpload: True
  Package: lxc
  PackageArchitecture: i386
  ProcCmdline: BOOT_IMAGE=/boot/vmlinuz-3.8.0-31-generic 
root=UUID=4c07e19b-cf33-4cbd-ab6d-fe300398b22b ro quiet splash vt.handoff=7
  ProcVersionSignature: Ubuntu 3.8.0-31.46-generic 3.8.13.8
  RelatedPackageVersions:
   bind9utils 1:9.9.2.dfsg.P1-2ubuntu2.1
   apparmor   2.8.0-0ubuntu11
  Tags:  raring
  Uname: Linux 3.8.0-31-generic i686
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
  modified.conffile..etc.bind.named.conf.local: [modified]
  mtime.conffile..etc.bind.named.conf.local: 2013-08-01T12:03:20.742316

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1240757/+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

[Touch-packages] [Bug 1565567] Re: segv in sudo_getgrgid

[LaMont Jones]

this is with current xenial (1.8.16-0ubuntu1)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to sudo in Ubuntu.
https://bugs.launchpad.net/bugs/1565567

Title:
  segv in sudo_getgrgid

Status in sudo package in Ubuntu:
  New

Bug description:
  If the user is in a group with no name (because libnss-db got removed
  and the group was defined there, for example...) then:

  the call to sudo_debug_printf in sudo_getgrgid
  (plugins/sudoers/pwutil.c, line 462) causes a SEGV when trying to get
  item->d.gr->gr_name (since item->d.gr is NULL).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/1565567/+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

[Touch-packages] [Bug 1565567] [NEW] segv in sudo_getgrgid

[LaMont Jones]

Public bug reported:

If the user is in a group with no name (because libnss-db got removed
and the group was defined there, for example...) then:

the call to sudo_debug_printf in sudo_getgrgid
(plugins/sudoers/pwutil.c, line 462) causes a SEGV when trying to get
item->d.gr->gr_name (since item->d.gr is NULL).

** Affects: sudo (Ubuntu)
 Importance: Undecided
 Status: New

** Attachment added: "trace, etc from gdb."
   https://bugs.launchpad.net/bugs/1565567/+attachment/4622375/+files/sudo.bug

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to sudo in Ubuntu.
https://bugs.launchpad.net/bugs/1565567

Title:
  segv in sudo_getgrgid

Status in sudo package in Ubuntu:
  New

Bug description:
  If the user is in a group with no name (because libnss-db got removed
  and the group was defined there, for example...) then:

  the call to sudo_debug_printf in sudo_getgrgid
  (plugins/sudoers/pwutil.c, line 462) causes a SEGV when trying to get
  item->d.gr->gr_name (since item->d.gr is NULL).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/1565567/+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

[Touch-packages] [Bug 1562402] Re: segv in apt 1.2.7 with dist-upgrade

[LaMont Jones]

And here is the trace from 1.2.8:

Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Need to get 798 kB/35.8 MB of archives.
After this operation, 3,549 kB disk space will be freed.
Do you want to continue? [Y/n] 
Get:1 http://ubuntu-mirror.wfg-office/ubuntu xenial/main amd64 python3-gi amd64 
3.20.0-0ubuntu1 [153 kB]
Get:2 http://ubuntu-mirror.wfg-office/ubuntu xenial/universe amd64 
python-gi-cairo amd64 3.20.0-0ubuntu1 [6,246 B]
Get:3 http://ubuntu-mirror.wfg-office/ubuntu xenial/main amd64 python-gi amd64 
3.20.0-0ubuntu1 [194 kB]
Get:4 http://ubuntu-mirror.wfg-office/ubuntu xenial/main amd64 
python-setuptools all 20.3.1-1 [170 kB]
Get:5 http://ubuntu-mirror.wfg-office/ubuntu xenial/main amd64 
python-pkg-resources all 20.3.1-1 [108 kB]
Get:6 http://ubuntu-mirror.wfg-office/ubuntu xenial/main amd64 
python3-setuptools all 20.3.1-1 [88.1 kB]
Get:7 http://ubuntu-mirror.wfg-office/ubuntu xenial/main amd64 
python3-pkg-resources all 20.3.1-1 [78.8 kB]
Fetched 798 kB in 0s (17.4 MB/s) 

Program received signal SIGSEGV, Segmentation fault.
0x77b3e00d in debVersioningSystem::CheckDep(char const*, int, char 
const*) ()
   from /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0
(gdb) bt
#0  0x77b3e00d in debVersioningSystem::CheckDep(char const*, int, char 
const*) ()
   from /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0
#1  0x77b7161b in 
pkgPackageManager::CheckRConflicts(pkgCache::PkgIterator, 
pkgCache::DepIterator, char const*)
() from /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0
#2  0x77b71af8 in pkgPackageManager::SmartUnPack(pkgCache::PkgIterator, 
bool, int) ()
   from /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0
#3  0x77b74bdd in ?? () from /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0
#4  0x77b7224b in pkgPackageManager::SmartUnPack(pkgCache::PkgIterator, 
bool, int) ()
   from /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0
#5  0x77b7768a in pkgPackageManager::OrderInstall() () from 
/usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0
#6  0x77b76c11 in 
pkgPackageManager::DoInstall(APT::Progress::PackageManager*) ()
   from /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0
#7  0x778353e0 in InstallPackages(CacheFile&, bool, bool, bool) ()
   from /usr/lib/x86_64-linux-gnu/libapt-private.so.0.0
#8  0x77858ede in ?? () from 
/usr/lib/x86_64-linux-gnu/libapt-private.so.0.0
#9  0x77afbc66 in CommandLine::DispatchArg(CommandLine::Dispatch 
const*, bool) ()
   from /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0
#10 0x7782adf3 in DispatchCommandLine(CommandLine&, 
std::vector 
const&) () from /usr/lib/x86_64-linux-gnu/libapt-private.so.0.0
#11 0x7b39 in ?? ()
#12 0x76ed3841 in __libc_start_main (main=0x7aa0, argc=2, 
argv=0x7fffeb58, init=, 
fini=, rtld_fini=, stack_end=0x7fffeb48) 
at ../csu/libc-start.c:291
#13 0x7bf9 in ?? ()
(gdb)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apt in Ubuntu.
https://bugs.launchpad.net/bugs/1562402

Title:
  segv in apt 1.2.7 with dist-upgrade

Status in apt package in Ubuntu:
  New

Bug description:
  The following NEW packages will be installed:
maas-region-api
  The following packages will be upgraded:
console-setup console-setup-linux devscripts git git-man
keyboard-configuration language-pack-en language-pack-en-base
language-pack-gnome-en language-pack-gnome-en-base libboost-filesystem1.58.0
libboost-system1.58.0 libboost-thread1.58.0 libc-bin libcups2 libgusb2
liblxc1 libmirclient9 libmircommon5 libmirprotobuf3 libpam-systemd libpcre3
libpython2.7 libpython2.7-minimal libpython2.7-stdlib libpython3-stdlib
libsystemd0 libudev1 locales lxc lxc-common lxc-templates lxc1 maas maas-cli
maas-common maas-dhcp maas-dns maas-proxy maas-rack-controller
maas-region-controller mdadm multiarch-support python-simplestreams
python-twisted python-twisted-bin python-twisted-conch python-twisted-core
python-twisted-mail python-twisted-names python-twisted-news
python-twisted-runner python-twisted-web python-twisted-words python2.7
python2.7-minimal python3 python3-django-maas python3-lxc
python3-maas-client python3-maas-provisioningserver python3-minimal
python3-simplestreams python3-software-properties python3-twisted
software-properties-common systemd systemd-sysv ubuntu-minimal ubuntu-mono
ubuntu-standard ucf udev virt-manager virtinst
  75 upgraded, 1 newly installed, 1 to remove and 0 not upgraded.
  [Thread debugging using libthread_db enabled]
  Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
  Need to get 0 B/35.0 MB of archives.
  After this operation, 3,892 kB disk space will be freed.
  Do you want to continue? [Y/n]

  Program received signal SIGSEGV, Segmentation fault.
  0x77b79209 in 

[Touch-packages] [Bug 1562402] [NEW] segv in apt 1.2.7 with dist-upgrade

[LaMont Jones]

Public bug reported:

The following NEW packages will be installed:
  maas-region-api
The following packages will be upgraded:
  console-setup console-setup-linux devscripts git git-man
  keyboard-configuration language-pack-en language-pack-en-base
  language-pack-gnome-en language-pack-gnome-en-base libboost-filesystem1.58.0
  libboost-system1.58.0 libboost-thread1.58.0 libc-bin libcups2 libgusb2
  liblxc1 libmirclient9 libmircommon5 libmirprotobuf3 libpam-systemd libpcre3
  libpython2.7 libpython2.7-minimal libpython2.7-stdlib libpython3-stdlib
  libsystemd0 libudev1 locales lxc lxc-common lxc-templates lxc1 maas maas-cli
  maas-common maas-dhcp maas-dns maas-proxy maas-rack-controller
  maas-region-controller mdadm multiarch-support python-simplestreams
  python-twisted python-twisted-bin python-twisted-conch python-twisted-core
  python-twisted-mail python-twisted-names python-twisted-news
  python-twisted-runner python-twisted-web python-twisted-words python2.7
  python2.7-minimal python3 python3-django-maas python3-lxc
  python3-maas-client python3-maas-provisioningserver python3-minimal
  python3-simplestreams python3-software-properties python3-twisted
  software-properties-common systemd systemd-sysv ubuntu-minimal ubuntu-mono
  ubuntu-standard ucf udev virt-manager virtinst
75 upgraded, 1 newly installed, 1 to remove and 0 not upgraded.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Need to get 0 B/35.0 MB of archives.
After this operation, 3,892 kB disk space will be freed.
Do you want to continue? [Y/n]

Program received signal SIGSEGV, Segmentation fault.
0x77b79209 in pkgCache::DepIterator::GlobOr(pkgCache::DepIterator&, 
pkgCache::DepIterator&) () from /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0
(gdb) bt
#0  0x77b79209 in pkgCache::DepIterator::GlobOr(pkgCache::DepIterator&, 
pkgCache::DepIterator&) ()
   from /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0
#1  0x77b719ab in pkgPackageManager::SmartUnPack(pkgCache::PkgIterator, 
bool, int) ()
   from /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0
#2  0x77b74bdd in ?? () from /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0
#3  0x77b7224b in pkgPackageManager::SmartUnPack(pkgCache::PkgIterator, 
bool, int) ()
   from /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0
#4  0x77b7768a in pkgPackageManager::OrderInstall() () from 
/usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0
#5  0x77b76c11 in 
pkgPackageManager::DoInstall(APT::Progress::PackageManager*) ()
   from /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0
#6  0x778353e0 in InstallPackages(CacheFile&, bool, bool, bool) ()
   from /usr/lib/x86_64-linux-gnu/libapt-private.so.0.0
#7  0x77858ede in ?? () from 
/usr/lib/x86_64-linux-gnu/libapt-private.so.0.0
#8  0x77afbc66 in CommandLine::DispatchArg(CommandLine::Dispatch 
const*, bool) ()
   from /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0
#9  0x7782adf3 in DispatchCommandLine(CommandLine&, 
std::vector 
const&) () from /usr/lib/x86_64-linux-gnu/libapt-private.so.0.0
#10 0x7b39 in ?? ()
#11 0x76ed3841 in __libc_start_main (main=0x7aa0, argc=2, 
argv=0x7fffeb68, init=,
fini=, rtld_fini=, stack_end=0x7fffeb58) 
at ../csu/libc-start.c:291
#12 0x7bf9 in ?? ()
(gdb)

** Affects: apt (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apt in Ubuntu.
https://bugs.launchpad.net/bugs/1562402

Title:
  segv in apt 1.2.7 with dist-upgrade

Status in apt package in Ubuntu:
  New

Bug description:
  The following NEW packages will be installed:
maas-region-api
  The following packages will be upgraded:
console-setup console-setup-linux devscripts git git-man
keyboard-configuration language-pack-en language-pack-en-base
language-pack-gnome-en language-pack-gnome-en-base libboost-filesystem1.58.0
libboost-system1.58.0 libboost-thread1.58.0 libc-bin libcups2 libgusb2
liblxc1 libmirclient9 libmircommon5 libmirprotobuf3 libpam-systemd libpcre3
libpython2.7 libpython2.7-minimal libpython2.7-stdlib libpython3-stdlib
libsystemd0 libudev1 locales lxc lxc-common lxc-templates lxc1 maas maas-cli
maas-common maas-dhcp maas-dns maas-proxy maas-rack-controller
maas-region-controller mdadm multiarch-support python-simplestreams
python-twisted python-twisted-bin python-twisted-conch python-twisted-core
python-twisted-mail python-twisted-names python-twisted-news
python-twisted-runner python-twisted-web python-twisted-words python2.7
python2.7-minimal python3 python3-django-maas python3-lxc
python3-maas-client python3-maas-provisioningserver python3-minimal
python3-simplestreams python3-software-properties python3-twisted
software-properties-common systemd 

[Touch-packages] [Bug 1556175] Re: networking.service hangs on shutdown -- killing dhclient has no effect any more

[LaMont Jones]

** Changed in: bind9 (Ubuntu)
   Status: Triaged => Fix Committed

-- 
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/1556175

Title:
  networking.service hangs on shutdown -- killing dhclient has no effect
  any more

Status in bind9 package in Ubuntu:
  Fix Committed
Status in isc-dhcp package in Ubuntu:
  Triaged

Bug description:
  On current xenial, LXD containers take ages to reboot:

  lxc launch images:ubuntu/xenial/amd64 x1
  lxc exec x1 reboot

  "systemctl list-jobs" shows:

  117 networking.service stop  running

  root@x1:~# systemctl status networking
  ● networking.service - Raise network interfaces
 Loaded: loaded (/lib/systemd/system/networking.service; enabled; vendor 
preset: enabled)
Drop-In: /run/systemd/generator/networking.service.d
 └─50-insserv.conf-$network.conf
 Active: deactivating (stop-sigterm) since Fri 2016-03-11 16:03:51 UTC; 21s 
ago
   Docs: man:interfaces(5)
Process: 187 ExecStop=/sbin/ifdown -a --read-environment (code=exited, 
status=0/SUCCESS)
Process: 55 ExecStart=/sbin/ifup -a --read-environment (code=exited, 
status=0/SUCCESS)
Process: 49 ExecStartPre=/bin/sh -c [ "$CONFIGURE_INTERFACES" != "no" ] && 
[ -n "$(ifquery --r
   Main PID: 55 (code=exited, status=0/SUCCESS)
  Tasks: 1 (limit: 512)
 CGroup: /system.slice/networking.service
 └─146 /sbin/dhclient -1 -v -pf /run/dhclient.eth0.pid -lf 
/var/lib/dhcp/dhclient.eth0

  Mar 11 16:03:52 x1 dhclient[207]: For info, please visit 
https://www.isc.org/software/dhcp/
  Mar 11 16:03:52 x1 dhclient[207]: 
  Mar 11 16:03:52 x1 dhclient[207]: Listening on LPF/eth0/00:16:3e:5a:f5:97
  Mar 11 16:03:52 x1 ifdown[187]: Listening on LPF/eth0/00:16:3e:5a:f5:97
  Mar 11 16:03:52 x1 ifdown[187]: Sending on   LPF/eth0/00:16:3e:5a:f5:97
  Mar 11 16:03:52 x1 ifdown[187]: Sending on   Socket/fallback
  Mar 11 16:03:52 x1 dhclient[207]: Sending on   LPF/eth0/00:16:3e:5a:f5:97
  Mar 11 16:03:52 x1 dhclient[207]: Sending on   Socket/fallback
  Mar 11 16:03:52 x1 dhclient[207]: DHCPRELEASE on eth0 to 10.0.3.1 port 67 
(xid=0x6480ef2b)
  Mar 11 16:03:52 x1 ifdown[187]: DHCPRELEASE on eth0 to 10.0.3.1 port 67 
(xid=0x6480ef2b)

  The above is also the last journal line that I get for the usual 90s
  timeout, then the container finally reboots.

  Not many processes are actually running any more:

  root 1  0.0  0.0  37076  5304 ?Ss   16:03   0:00 /sbin/init
  root38  0.0  0.0  41572  3316 ?Ss   16:03   0:00 
/lib/systemd/systemd-udevd
  root41  0.0  0.0  35276  5668 ?Ss   16:03   0:00 
/lib/systemd/systemd-journald
  root   146  0.0  0.0 181376  2664 ?Ss   16:03   0:00 
/sbin/dhclient -1 -v -pf /run/dhclient.eth0.pid -lf 
/var/lib/dhcp/dhclient.eth0.leases -I -df /var/lib/dhcp/dhclient6.eth0.leases 
eth0

  but apparently the dhclient instance refuses to die (note that ifdown
  -a itself is not running any more).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1556175/+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

[Touch-packages] [Bug 1551351] Re: dhclient does not renew leases

[LaMont Jones]

The plan here is to restore the -export libraries for the time being,
until upstream finishes the dhcp changes that are needed to have the
common libs work.  This is in-progress.

-- 
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/1551351

Title:
  dhclient does not renew leases

Status in bind9 package in Ubuntu:
  Confirmed
Status in isc-dhcp package in Ubuntu:
  Confirmed
Status in bind9 source package in Xenial:
  Confirmed
Status in isc-dhcp source package in Xenial:
  Confirmed

Bug description:
  Release: Xenial

  I think this only recently started after some bind9 updates triggered a 
rebuild. When booting dhclient gets started and acquires an IP address, but it 
does seem to lock up somewhere as it does not renew the lease.
  In my environment I set the lease time to 5 minutes, so I notice such things 
rather soon. I looked on the dhcp server side but saw any further dhcp messages 
come in from the client side.

  Related bugs:
   * bug 1551415:  systemctl stop networking hang / timeout 

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: isc-dhcp-client 4.3.3-5ubuntu8
  ProcVersionSignature: Ubuntu 4.4.0-9.24-generic 4.4.3
  Uname: Linux 4.4.0-9-generic x86_64
  ApportVersion: 2.20-0ubuntu3
  Architecture: amd64
  Date: Mon Feb 29 12:32:52 2016
  DhclientLeases:

  SourcePackage: isc-dhcp
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1551351/+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

[Touch-packages] [Bug 1537789] Re: MAAS dhcp fails to start on up-to-date Xenial with MAAS built from source

[LaMont Jones]

And bug attributed in 4.3.3-5ubuntu4. :(

** Changed in: isc-dhcp (Ubuntu)
   Importance: Undecided => Critical

** Changed in: isc-dhcp (Ubuntu)
   Status: New => Fix Committed

-- 
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/1537789

Title:
  MAAS dhcp fails to start on  up-to-date Xenial with MAAS built from
  source

Status in MAAS:
  Triaged
Status in isc-dhcp package in Ubuntu:
  Fix Committed

Bug description:

  /var/log/kern.log

  Jan 25 03:54:41 autopkgtest kernel: [  598.488307] audit: type=1400
  audit(1453712081.200:20): apparmor="DENIED" operation="capable"
  profile="/usr/sbin/dhcpd" pid=13381 comm="dhcpd" capability=0
  capname="chown"

  /var/log/syslog

  Jan 25 05:21:37 autopkgtest systemd[1]: Starting MAAS instance of ISC DHCP 
server for IPv4...
  Jan 25 05:21:37 autopkgtest systemd[1]: Started MAAS instance of ISC DHCP 
server for IPv4.
  Jan 25 05:21:37 autopkgtest dhcpd[17722]: Can't chown new lease file: 
Operation not permitted
  Jan 25 05:21:37 autopkgtest dhcpd[17722]: 
  Jan 25 05:21:37 autopkgtest dhcpd[17722]: If you think you have received this 
message due to a bug rather
  Jan 25 05:21:37 autopkgtest dhcpd[17722]: than a configuration issue please 
read the section on submitting
  Jan 25 05:21:37 autopkgtest dhcpd[17722]: bugs on either our web page at 
www.isc.org or in the README file
  Jan 25 05:21:37 autopkgtest dhcpd[17722]: before submitting a bug.  These 
pages explain the proper
  Jan 25 05:21:37 autopkgtest dhcpd[17722]: process and the information we find 
helpful for debugging..
  Jan 25 05:21:37 autopkgtest dhcpd[17722]: 
  Jan 25 05:21:37 autopkgtest dhcpd[17722]: exiting.
  Jan 25 05:21:37 autopkgtest systemd[1]: maas-dhcpd.service: Main process 
exited, code=exited, status=1/FAILURE
  Jan 25 05:21:37 autopkgtest systemd[1]: maas-dhcpd.service: Unit entered 
failed state.
  Jan 25 05:21:37 autopkgtest systemd[1]: maas-dhcpd.service: Failed with 
result 'exit-code'.

  root@autopkgtest:~# ls -l /var/lib/maas/dhcp/dhcpd.leases
  -rw-r--r-- 1 maas maas 0 Jan 25 03:54 /var/lib/maas/dhcp/dhcpd.leases

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1537789/+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

[Touch-packages] [Bug 1537789] Re: MAAS dhcp fails to start on up-to-date Xenial with MAAS built from source

[LaMont Jones]

Fixed in 4.3.3-5ubuntu3

-- 
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/1537789

Title:
  MAAS dhcp fails to start on  up-to-date Xenial with MAAS built from
  source

Status in MAAS:
  Triaged
Status in isc-dhcp package in Ubuntu:
  Fix Committed

Bug description:

  /var/log/kern.log

  Jan 25 03:54:41 autopkgtest kernel: [  598.488307] audit: type=1400
  audit(1453712081.200:20): apparmor="DENIED" operation="capable"
  profile="/usr/sbin/dhcpd" pid=13381 comm="dhcpd" capability=0
  capname="chown"

  /var/log/syslog

  Jan 25 05:21:37 autopkgtest systemd[1]: Starting MAAS instance of ISC DHCP 
server for IPv4...
  Jan 25 05:21:37 autopkgtest systemd[1]: Started MAAS instance of ISC DHCP 
server for IPv4.
  Jan 25 05:21:37 autopkgtest dhcpd[17722]: Can't chown new lease file: 
Operation not permitted
  Jan 25 05:21:37 autopkgtest dhcpd[17722]: 
  Jan 25 05:21:37 autopkgtest dhcpd[17722]: If you think you have received this 
message due to a bug rather
  Jan 25 05:21:37 autopkgtest dhcpd[17722]: than a configuration issue please 
read the section on submitting
  Jan 25 05:21:37 autopkgtest dhcpd[17722]: bugs on either our web page at 
www.isc.org or in the README file
  Jan 25 05:21:37 autopkgtest dhcpd[17722]: before submitting a bug.  These 
pages explain the proper
  Jan 25 05:21:37 autopkgtest dhcpd[17722]: process and the information we find 
helpful for debugging..
  Jan 25 05:21:37 autopkgtest dhcpd[17722]: 
  Jan 25 05:21:37 autopkgtest dhcpd[17722]: exiting.
  Jan 25 05:21:37 autopkgtest systemd[1]: maas-dhcpd.service: Main process 
exited, code=exited, status=1/FAILURE
  Jan 25 05:21:37 autopkgtest systemd[1]: maas-dhcpd.service: Unit entered 
failed state.
  Jan 25 05:21:37 autopkgtest systemd[1]: maas-dhcpd.service: Failed with 
result 'exit-code'.

  root@autopkgtest:~# ls -l /var/lib/maas/dhcp/dhcpd.leases
  -rw-r--r-- 1 maas maas 0 Jan 25 03:54 /var/lib/maas/dhcp/dhcpd.leases

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1537789/+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

[Touch-packages] [Bug 1537789] Re: MAAS dhcp fails to start on up-to-date Xenial with MAAS built from source

[LaMont Jones]

encountered with (and fixed in-situ under) 4.3.3-5ubuntu2

** Also affects: isc-dhcp (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: isc-dhcp (Ubuntu)
 Assignee: (unassigned) => LaMont Jones (lamont)

-- 
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/1537789

Title:
  MAAS dhcp fails to start on  up-to-date Xenial with MAAS built from
  source

Status in MAAS:
  Triaged
Status in isc-dhcp package in Ubuntu:
  New

Bug description:

  /var/log/kern.log

  Jan 25 03:54:41 autopkgtest kernel: [  598.488307] audit: type=1400
  audit(1453712081.200:20): apparmor="DENIED" operation="capable"
  profile="/usr/sbin/dhcpd" pid=13381 comm="dhcpd" capability=0
  capname="chown"

  /var/log/syslog

  Jan 25 05:21:37 autopkgtest systemd[1]: Starting MAAS instance of ISC DHCP 
server for IPv4...
  Jan 25 05:21:37 autopkgtest systemd[1]: Started MAAS instance of ISC DHCP 
server for IPv4.
  Jan 25 05:21:37 autopkgtest dhcpd[17722]: Can't chown new lease file: 
Operation not permitted
  Jan 25 05:21:37 autopkgtest dhcpd[17722]: 
  Jan 25 05:21:37 autopkgtest dhcpd[17722]: If you think you have received this 
message due to a bug rather
  Jan 25 05:21:37 autopkgtest dhcpd[17722]: than a configuration issue please 
read the section on submitting
  Jan 25 05:21:37 autopkgtest dhcpd[17722]: bugs on either our web page at 
www.isc.org or in the README file
  Jan 25 05:21:37 autopkgtest dhcpd[17722]: before submitting a bug.  These 
pages explain the proper
  Jan 25 05:21:37 autopkgtest dhcpd[17722]: process and the information we find 
helpful for debugging..
  Jan 25 05:21:37 autopkgtest dhcpd[17722]: 
  Jan 25 05:21:37 autopkgtest dhcpd[17722]: exiting.
  Jan 25 05:21:37 autopkgtest systemd[1]: maas-dhcpd.service: Main process 
exited, code=exited, status=1/FAILURE
  Jan 25 05:21:37 autopkgtest systemd[1]: maas-dhcpd.service: Unit entered 
failed state.
  Jan 25 05:21:37 autopkgtest systemd[1]: maas-dhcpd.service: Failed with 
result 'exit-code'.

  root@autopkgtest:~# ls -l /var/lib/maas/dhcp/dhcpd.leases
  -rw-r--r-- 1 maas maas 0 Jan 25 03:54 /var/lib/maas/dhcp/dhcpd.leases

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1537789/+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

[Touch-packages] [Bug 1537789] Re: MAAS dhcp fails to start on up-to-date Xenial with MAAS built from source

[LaMont Jones]

** Changed in: isc-dhcp (Ubuntu)
Milestone: None => trusty-updates

** Changed in: isc-dhcp (Ubuntu)
Milestone: trusty-updates => ubuntu-16.04

** Changed in: isc-dhcp (Ubuntu)
Milestone: ubuntu-16.04 => trusty-updates

** Changed in: isc-dhcp (Ubuntu)
Milestone: trusty-updates => ubuntu-16.04

** Also affects: isc-dhcp (Ubuntu Trusty)
   Importance: Undecided
   Status: New

** Changed in: isc-dhcp (Ubuntu Trusty)
Milestone: None => trusty-updates

** No longer affects: isc-dhcp (Ubuntu Trusty)

-- 
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/1537789

Title:
  MAAS dhcp fails to start on  up-to-date Xenial with MAAS built from
  source

Status in MAAS:
  Triaged
Status in isc-dhcp package in Ubuntu:
  Fix Committed

Bug description:

  /var/log/kern.log

  Jan 25 03:54:41 autopkgtest kernel: [  598.488307] audit: type=1400
  audit(1453712081.200:20): apparmor="DENIED" operation="capable"
  profile="/usr/sbin/dhcpd" pid=13381 comm="dhcpd" capability=0
  capname="chown"

  /var/log/syslog

  Jan 25 05:21:37 autopkgtest systemd[1]: Starting MAAS instance of ISC DHCP 
server for IPv4...
  Jan 25 05:21:37 autopkgtest systemd[1]: Started MAAS instance of ISC DHCP 
server for IPv4.
  Jan 25 05:21:37 autopkgtest dhcpd[17722]: Can't chown new lease file: 
Operation not permitted
  Jan 25 05:21:37 autopkgtest dhcpd[17722]: 
  Jan 25 05:21:37 autopkgtest dhcpd[17722]: If you think you have received this 
message due to a bug rather
  Jan 25 05:21:37 autopkgtest dhcpd[17722]: than a configuration issue please 
read the section on submitting
  Jan 25 05:21:37 autopkgtest dhcpd[17722]: bugs on either our web page at 
www.isc.org or in the README file
  Jan 25 05:21:37 autopkgtest dhcpd[17722]: before submitting a bug.  These 
pages explain the proper
  Jan 25 05:21:37 autopkgtest dhcpd[17722]: process and the information we find 
helpful for debugging..
  Jan 25 05:21:37 autopkgtest dhcpd[17722]: 
  Jan 25 05:21:37 autopkgtest dhcpd[17722]: exiting.
  Jan 25 05:21:37 autopkgtest systemd[1]: maas-dhcpd.service: Main process 
exited, code=exited, status=1/FAILURE
  Jan 25 05:21:37 autopkgtest systemd[1]: maas-dhcpd.service: Unit entered 
failed state.
  Jan 25 05:21:37 autopkgtest systemd[1]: maas-dhcpd.service: Failed with 
result 'exit-code'.

  root@autopkgtest:~# ls -l /var/lib/maas/dhcp/dhcpd.leases
  -rw-r--r-- 1 maas maas 0 Jan 25 03:54 /var/lib/maas/dhcp/dhcpd.leases

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1537789/+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

[Touch-packages] [Bug 1528956] Re: netinst produces an unusable system

[LaMont Jones]

** Attachment added: "host definition for the vm used"
   
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1528956/+attachment/4539557/+files/xenial.xml

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1528956

Title:
  netinst produces an unusable system

Status in systemd package in Ubuntu:
  New

Bug description:
  for various reasons of history:
  /var/lib/tftpboot/pxelinux.0 (was precise?  md5sum is 
94fa5add303db869b79cba07449127c2)
  /var/lib/tftpboot/xenial is a directory into which 
xenial/main/installer-amd64/current/images/netboot/netboot.tar.gz was unpacked. 
 (md5sum of the tarball: 8d7b64c36776fe708210e8ef6deee852)
  /var/lib/tftpboot/xenial-amd64{,-initrd.gz} are copies of 
xenial/ubuntu-installer/amd64/{linux,initrd.gz}

  /var/lib/tftpboot/pxelinux.cfg/$HEX_IP contains:
  DISPLAY /boot-screens/boot.txt
  DEFAULT install

  LABEL install
  kernel xenial-amd64
  ipappend 2 
  append auto priority=critical netcfg/dhcp_timeout=120 
locale=en_US.UTF8 console-setup/ask_detect=false console-setup/layoutcode=us 
interface=auto netcfg/get_hostname=foo netcfg/get_domain=example.com 
mirror/http/proxy= DEBCONF_DEBUG=5 vga=normal initrd=xenial-amd64.initrd.gz 
ramdisk_size=16417 root=/dev/ram rw --

  PROMPT 1
  TIMEOUT 60

  After the install finishes, the reboot shows the root filesystem fsck,
  and then nothing.

  package install differences are attached (diff xenial.netinst
  xenial.server | grep -e '[<>]')

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1528956/+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

[Touch-packages] [Bug 1528956] [NEW] netinst produces an unusable system

[LaMont Jones]

Public bug reported:

for various reasons of history:
/var/lib/tftpboot/pxelinux.0 (was precise?  md5sum is 
94fa5add303db869b79cba07449127c2)
/var/lib/tftpboot/xenial is a directory into which 
xenial/main/installer-amd64/current/images/netboot/netboot.tar.gz was unpacked. 
 (md5sum of the tarball: 8d7b64c36776fe708210e8ef6deee852)
/var/lib/tftpboot/xenial-amd64{,-initrd.gz} are copies of 
xenial/ubuntu-installer/amd64/{linux,initrd.gz}

/var/lib/tftpboot/pxelinux.cfg/$HEX_IP contains:
DISPLAY /boot-screens/boot.txt
DEFAULT install

LABEL install
kernel xenial-amd64
ipappend 2 
append auto priority=critical netcfg/dhcp_timeout=120 locale=en_US.UTF8 
console-setup/ask_detect=false console-setup/layoutcode=us interface=auto 
netcfg/get_hostname=foo netcfg/get_domain=example.com mirror/http/proxy= 
DEBCONF_DEBUG=5 vga=normal initrd=xenial-amd64.initrd.gz ramdisk_size=16417 
root=/dev/ram rw --

PROMPT 1
TIMEOUT 60

After the install finishes, the reboot shows the root filesystem fsck,
and then nothing.

package install differences are attached (diff xenial.netinst
xenial.server | grep -e '[<>]')

** Affects: systemd (Ubuntu)
 Importance: Undecided
 Status: New

** Attachment added: "diff between netinst and server(iso) installed package 
reports"
   https://bugs.launchpad.net/bugs/1528956/+attachment/4539556/+files/pkgdiff

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1528956

Title:
  netinst produces an unusable system

Status in systemd package in Ubuntu:
  New

Bug description:
  for various reasons of history:
  /var/lib/tftpboot/pxelinux.0 (was precise?  md5sum is 
94fa5add303db869b79cba07449127c2)
  /var/lib/tftpboot/xenial is a directory into which 
xenial/main/installer-amd64/current/images/netboot/netboot.tar.gz was unpacked. 
 (md5sum of the tarball: 8d7b64c36776fe708210e8ef6deee852)
  /var/lib/tftpboot/xenial-amd64{,-initrd.gz} are copies of 
xenial/ubuntu-installer/amd64/{linux,initrd.gz}

  /var/lib/tftpboot/pxelinux.cfg/$HEX_IP contains:
  DISPLAY /boot-screens/boot.txt
  DEFAULT install

  LABEL install
  kernel xenial-amd64
  ipappend 2 
  append auto priority=critical netcfg/dhcp_timeout=120 
locale=en_US.UTF8 console-setup/ask_detect=false console-setup/layoutcode=us 
interface=auto netcfg/get_hostname=foo netcfg/get_domain=example.com 
mirror/http/proxy= DEBCONF_DEBUG=5 vga=normal initrd=xenial-amd64.initrd.gz 
ramdisk_size=16417 root=/dev/ram rw --

  PROMPT 1
  TIMEOUT 60

  After the install finishes, the reboot shows the root filesystem fsck,
  and then nothing.

  package install differences are attached (diff xenial.netinst
  xenial.server | grep -e '[<>]')

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1528956/+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

[Touch-packages] [Bug 1521618] Re: wrong subnet in DHCP answer when multiple networks are present

[LaMont Jones]

I'm having trouble reproducing this...

What version of isc-dhcp-server is running here?

Does it change anything if you (manually) reorder the 2 subnets in
dhcpd.conf and restart the dhcp server?

-- 
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/1521618

Title:
  wrong subnet in DHCP answer when multiple networks are present

Status in MAAS:
  Triaged
Status in isc-dhcp package in Ubuntu:
  New

Bug description:
  So I have 3 interfaces with 3, non-overlapping subnets defined in my
  maas cluster controller.

  The idea would be that there is a provisioning network (10.6.0.0/16)
  to do the actual provisioning and once the node gets deployed it is
  using a different network (because the provisioning network is only
  1x1Gbit while the production network is bonded (LACP) 10Gbit).

  However, when I boot up a fresh, new node to add to MAAS, it gets the
  following DHCP reply:

  ip=10.6.239.3:10.6.250.250:9.4.113.254:255.255.255.0

  So instead of picking up the /16 subnet correctly for the 10.6.239.3
  IP, it picks up the /24 from the network where it gets it's default
  gateway from.

  Is this a bug or my understanding of how MAAS should behave when there
  are multiple networks flawed?

  Here is my /var/lib/maas/dhcpd.conf:

  subnet 9.4.113.0 netmask 255.255.255.0 {
 if option arch = 00:0E {
filename "pxelinux.0";
option path-prefix "ppc64el/";
 } elsif option arch = 00:07 {
filename "bootx64.efi";
 } elsif option arch = 00:0B {
filename "grubaa64.efi";
 } elsif option arch = 00:0C {
filename "bootppc64.bin";
 } else {
filename "pxelinux.0";
 }
 interface "eth0";
 ignore-client-uids true;
 option subnet-mask 255.255.255.0;
 option broadcast-address 9.4.113.255;
 option domain-name-servers 9.4.113.251;
 option domain-name "i.zc2.ibm.com";
 option routers 9.4.113.254;
 option ntp-servers ntp.ubuntu.com;
 range dynamic-bootp 9.4.113.150 9.4.113.190;
 class "PXE" {
match if substring (option vendor-class-identifier, 0, 3) = "PXE";
default-lease-time 30;
max-lease-time 30;
 }
  }
  subnet 10.6.0.0 netmask 255.255.0.0 {
 if option arch = 00:0E {
filename "pxelinux.0";
option path-prefix "ppc64el/";
 } elsif option arch = 00:07 {
filename "bootx64.efi";
 } elsif option arch = 00:0B {
filename "grubaa64.efi";
 } elsif option arch = 00:0C {
filename "bootppc64.bin";
 } else {
filename "pxelinux.0";
 }
 interface "eth1";
 ignore-client-uids true;
 option subnet-mask 255.255.0.0;
 option broadcast-address 10.6.255.255;
 option domain-name-servers 9.4.113.251;
 option domain-name "i.zc2.ibm.com";
 option ntp-servers ntp.ubuntu.com;
 range dynamic-bootp 10.6.239.0 10.6.239.239;
 class "PXE" {
match if substring (option vendor-class-identifier, 0, 3) = "PXE";
default-lease-time 30;
max-lease-time 30;
 }
  }

  Here is "subnets read":

  [
  {
  "dns_servers": [],
  "name": "9.4.113.0/24",
  "space": "space-0",
  "vlan": {
  "name": "untagged",
  "resource_uri": "/MAAS/api/1.0/vlans/0/",
  "fabric": "fabric-0",
  "vid": 0,
  "id": 0
  },
  "gateway_ip": "9.4.113.254",
  "cidr": "9.4.113.0/24",
  "id": 1,
  "resource_uri": "/MAAS/api/1.0/subnets/1/"
  },
  {
  "dns_servers": [],
  "name": "10.7.0.0/16",
  "space": "space-0",
  "vlan": {
  "name": "untagged",
  "resource_uri": "/MAAS/api/1.0/vlans/5001/",
  "fabric": "fabric-1",
  "vid": 0,
  "id": 5001
  },
  "gateway_ip": null,
  "cidr": "10.7.0.0/16",
  "id": 2,
  "resource_uri": "/MAAS/api/1.0/subnets/2/"
  },
  {
  "dns_servers": [],
  "name": "10.6.0.0/16",
  "space": "space-0",
  "vlan": {
  "name": "untagged",
  "resource_uri": "/MAAS/api/1.0/vlans/5002/",
  "fabric": "fabric-2",
  "vid": 0,
  "id": 5002
  },
  "gateway_ip": null,
  "cidr": "10.6.0.0/16",
  "id": 3,
  "resource_uri": "/MAAS/api/1.0/subnets/3/"
  }
  ]

  Running 1.9.0~rc2+bzr4509-0ubuntu1~trusty1.

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1521618/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : 

[Touch-packages] [Bug 1521618] Re: wrong subnet in DHCP answer when multiple networks are present

[LaMont Jones]

Can we also get the output of the following on the cluster controller:
ip addr list; ip route list

thanks

-- 
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/1521618

Title:
  wrong subnet in DHCP answer when multiple networks are present

Status in MAAS:
  Incomplete
Status in isc-dhcp package in Ubuntu:
  New

Bug description:
  So I have 3 interfaces with 3, non-overlapping subnets defined in my
  maas cluster controller.

  The idea would be that there is a provisioning network (10.6.0.0/16)
  to do the actual provisioning and once the node gets deployed it is
  using a different network (because the provisioning network is only
  1x1Gbit while the production network is bonded (LACP) 10Gbit).

  However, when I boot up a fresh, new node to add to MAAS, it gets the
  following DHCP reply:

  ip=10.6.239.3:10.6.250.250:9.4.113.254:255.255.255.0

  So instead of picking up the /16 subnet correctly for the 10.6.239.3
  IP, it picks up the /24 from the network where it gets it's default
  gateway from.

  Is this a bug or my understanding of how MAAS should behave when there
  are multiple networks flawed?

  Here is my /var/lib/maas/dhcpd.conf:

  subnet 9.4.113.0 netmask 255.255.255.0 {
 if option arch = 00:0E {
filename "pxelinux.0";
option path-prefix "ppc64el/";
 } elsif option arch = 00:07 {
filename "bootx64.efi";
 } elsif option arch = 00:0B {
filename "grubaa64.efi";
 } elsif option arch = 00:0C {
filename "bootppc64.bin";
 } else {
filename "pxelinux.0";
 }
 interface "eth0";
 ignore-client-uids true;
 option subnet-mask 255.255.255.0;
 option broadcast-address 9.4.113.255;
 option domain-name-servers 9.4.113.251;
 option domain-name "i.zc2.ibm.com";
 option routers 9.4.113.254;
 option ntp-servers ntp.ubuntu.com;
 range dynamic-bootp 9.4.113.150 9.4.113.190;
 class "PXE" {
match if substring (option vendor-class-identifier, 0, 3) = "PXE";
default-lease-time 30;
max-lease-time 30;
 }
  }
  subnet 10.6.0.0 netmask 255.255.0.0 {
 if option arch = 00:0E {
filename "pxelinux.0";
option path-prefix "ppc64el/";
 } elsif option arch = 00:07 {
filename "bootx64.efi";
 } elsif option arch = 00:0B {
filename "grubaa64.efi";
 } elsif option arch = 00:0C {
filename "bootppc64.bin";
 } else {
filename "pxelinux.0";
 }
 interface "eth1";
 ignore-client-uids true;
 option subnet-mask 255.255.0.0;
 option broadcast-address 10.6.255.255;
 option domain-name-servers 9.4.113.251;
 option domain-name "i.zc2.ibm.com";
 option ntp-servers ntp.ubuntu.com;
 range dynamic-bootp 10.6.239.0 10.6.239.239;
 class "PXE" {
match if substring (option vendor-class-identifier, 0, 3) = "PXE";
default-lease-time 30;
max-lease-time 30;
 }
  }

  Here is "subnets read":

  [
  {
  "dns_servers": [],
  "name": "9.4.113.0/24",
  "space": "space-0",
  "vlan": {
  "name": "untagged",
  "resource_uri": "/MAAS/api/1.0/vlans/0/",
  "fabric": "fabric-0",
  "vid": 0,
  "id": 0
  },
  "gateway_ip": "9.4.113.254",
  "cidr": "9.4.113.0/24",
  "id": 1,
  "resource_uri": "/MAAS/api/1.0/subnets/1/"
  },
  {
  "dns_servers": [],
  "name": "10.7.0.0/16",
  "space": "space-0",
  "vlan": {
  "name": "untagged",
  "resource_uri": "/MAAS/api/1.0/vlans/5001/",
  "fabric": "fabric-1",
  "vid": 0,
  "id": 5001
  },
  "gateway_ip": null,
  "cidr": "10.7.0.0/16",
  "id": 2,
  "resource_uri": "/MAAS/api/1.0/subnets/2/"
  },
  {
  "dns_servers": [],
  "name": "10.6.0.0/16",
  "space": "space-0",
  "vlan": {
  "name": "untagged",
  "resource_uri": "/MAAS/api/1.0/vlans/5002/",
  "fabric": "fabric-2",
  "vid": 0,
  "id": 5002
  },
  "gateway_ip": null,
  "cidr": "10.6.0.0/16",
  "id": 3,
  "resource_uri": "/MAAS/api/1.0/subnets/3/"
  }
  ]

  Running 1.9.0~rc2+bzr4509-0ubuntu1~trusty1.

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1521618/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : 

[Touch-packages] [Bug 1519518] Re: gsettings-schema-convert has syntax errors

[LaMont Jones]

I forget exactly what the error message was, but I think it was the
difference between whatever output is, and that write wanted a
bytestring.  -- it's possibl;e that should be
fout.write(unicode(output))...

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gconf in Ubuntu.
https://bugs.launchpad.net/bugs/1519518

Title:
  gsettings-schema-convert has syntax errors

Status in gconf package in Ubuntu:
  In Progress

Bug description:
  gconf 3.2.6-3ubuntu5 (xenial) has gsettings-schema-convert requiring
  python3, but without correct syntax:

  gsettings-schema-convert --force --gconf --xml --schema-id 
"org.freedesktop.ibus" --output lamont.in ../../data/ibus.schemas.in
    File "/usr/bin/gsettings-schema-convert", line 606
  except GSettingsSchemaConvertException, e:
    ^
  SyntaxError: invalid syntax

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gconf/+bug/1519518/+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

[Touch-packages] [Bug 1472378] Re: upgrading ca-certificates results in broken certificate chains

[LaMont Jones]

Looking at the changelog:
 20111025: Drop bogus c_rehash on upgrades, ...
 20110421:   * Depend on openssl 1.0.0 and force a call of c_rehash so that we 
have both the old and new style of symlinks.  (Closes: #611102)

I fully suspect that the bug was introduced upstream in oct 2011.
If that's the case, then ubuntu introduced it 2014-03-05 with the security 
update to 20130906ubuntu0.12.04.1.

At this point in time, this bug only affects machines upgrading from
lucid to precise, and can be worked around by running c_rehash manually
after do-release-upgrades finishes.  It probably deserves to languish
without fixes until precise EOL in 2017, and then get closed as fully
uninteresting.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ca-certificates in Ubuntu.
https://bugs.launchpad.net/bugs/1472378

Title:
  upgrading ca-certificates results in broken certificate chains

Status in ca-certificates package in Ubuntu:
  New

Bug description:
  Found this (finally) upgrading a web server from lucid to precise (via
  do-release-upgrade):

  Preparing to replace ca-certificates 20141019ubuntu0.10.04.1 (using 
.../ca-certificates_20141019ubuntu0.12.04.1_all.deb) ...^M
  Unpacking replacement ca-certificates ...^M
  ...
  Setting up openssl (1.0.1-4ubuntu5.31) ...^M
  Installing new version of config file /etc/ssl/openssl.cnf ...^M
  Setting up ca-certificates (20141019ubuntu0.12.04.1) ...^M
  Updating certificates in /etc/ssl/certs... 0 added, 0 removed; done.^M
  Running hooks in /etc/ca-certificates/update.ddone.^M
  Setting up netbase (4.47ubuntu1) ...^M
  ...

  And everything is broken.  sometime between lucid and precise, the
  hash function seems to have changed (there are 2 hashes per pemfile in
  precise, and 1 per pemfile in lucid), and update-ca-certificates goes
  nothing to do here instead of hey, I need to rerun c_rehash to
  generate the other symlink.

  to reproduce: install a lucid box, and do-release-upgrade

  lamont

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ca-certificates/+bug/1472378/+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

[Touch-packages] [Bug 1472378] [NEW] upgrading ca-certificates results in broken certificate chains

[LaMont Jones]

Public bug reported:

Found this (finally) upgrading a web server from lucid to precise (via
do-release-upgrade):

Preparing to replace ca-certificates 20141019ubuntu0.10.04.1 (using 
.../ca-certificates_20141019ubuntu0.12.04.1_all.deb) ...^M
Unpacking replacement ca-certificates ...^M
...
Setting up openssl (1.0.1-4ubuntu5.31) ...^M
Installing new version of config file /etc/ssl/openssl.cnf ...^M
Setting up ca-certificates (20141019ubuntu0.12.04.1) ...^M
Updating certificates in /etc/ssl/certs... 0 added, 0 removed; done.^M
Running hooks in /etc/ca-certificates/update.ddone.^M
Setting up netbase (4.47ubuntu1) ...^M
...

And everything is broken.  sometime between lucid and precise, the hash
function seems to have changed (there are 2 hashes per pemfile in
precise, and 1 per pemfile in lucid), and update-ca-certificates goes
nothing to do here instead of hey, I need to rerun c_rehash to
generate the other symlink.

to reproduce: install a lucid box, and do-release-upgrade

lamont

** Affects: ca-certificates (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ca-certificates in Ubuntu.
https://bugs.launchpad.net/bugs/1472378

Title:
  upgrading ca-certificates results in broken certificate chains

Status in ca-certificates package in Ubuntu:
  New

Bug description:
  Found this (finally) upgrading a web server from lucid to precise (via
  do-release-upgrade):

  Preparing to replace ca-certificates 20141019ubuntu0.10.04.1 (using 
.../ca-certificates_20141019ubuntu0.12.04.1_all.deb) ...^M
  Unpacking replacement ca-certificates ...^M
  ...
  Setting up openssl (1.0.1-4ubuntu5.31) ...^M
  Installing new version of config file /etc/ssl/openssl.cnf ...^M
  Setting up ca-certificates (20141019ubuntu0.12.04.1) ...^M
  Updating certificates in /etc/ssl/certs... 0 added, 0 removed; done.^M
  Running hooks in /etc/ca-certificates/update.ddone.^M
  Setting up netbase (4.47ubuntu1) ...^M
  ...

  And everything is broken.  sometime between lucid and precise, the
  hash function seems to have changed (there are 2 hashes per pemfile in
  precise, and 1 per pemfile in lucid), and update-ca-certificates goes
  nothing to do here instead of hey, I need to rerun c_rehash to
  generate the other symlink.

  to reproduce: install a lucid box, and do-release-upgrade

  lamont

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ca-certificates/+bug/1472378/+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

[Touch-packages] [Bug 1358306] [NEW] lxc postinst incorrectly chooses network address to use

[LaMont Jones]

Public bug reported:

The lxc postinst assumes that only /24 networks are used in 10.0.0.0/8.
If the host has a route for 10.0.0.2/23 (or 10.0.0.0/22, or any other
block that includes 10.0.3.0/24 or whatever other block it is checking)
then the postinst chooses a chunk of the existing network block,
breaking connectivity.

Preparing to unpack .../lxc_1.0.5-0ubuntu0.1_amd64.deb ...
Unpacking lxc (1.0.5-0ubuntu0.1) ...
Processing triggers for ureadahead (0.100.0-16) ...
ureadahead will be reprofiled on next reboot
Processing triggers for man-db (2.6.7.1-1) ...
Setting up lxc (1.0.5-0ubuntu0.1) ...
lxc start/running
Setting up lxc dnsmasq configuration.
Processing triggers for ureadahead (0.100.0-16) ...
On branch master
nothing to commit, working directory clean
-soko(root) 308 : netstat -rn | grep ^10.0..\.
10.0.2.010.172.64.1 255.255.254.0   UG0 0  0 tun0
10.0.3.00.0.0.0 255.255.255.0   U 0 0  0 lxcbr0

** Affects: lxc (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1358306

Title:
  lxc postinst incorrectly chooses network address to use

Status in “lxc” package in Ubuntu:
  New

Bug description:
  The lxc postinst assumes that only /24 networks are used in
  10.0.0.0/8.  If the host has a route for 10.0.0.2/23 (or 10.0.0.0/22,
  or any other block that includes 10.0.3.0/24 or whatever other block
  it is checking) then the postinst chooses a chunk of the existing
  network block, breaking connectivity.

  Preparing to unpack .../lxc_1.0.5-0ubuntu0.1_amd64.deb ...
  Unpacking lxc (1.0.5-0ubuntu0.1) ...
  Processing triggers for ureadahead (0.100.0-16) ...
  ureadahead will be reprofiled on next reboot
  Processing triggers for man-db (2.6.7.1-1) ...
  Setting up lxc (1.0.5-0ubuntu0.1) ...
  lxc start/running
  Setting up lxc dnsmasq configuration.
  Processing triggers for ureadahead (0.100.0-16) ...
  On branch master
  nothing to commit, working directory clean
  -soko(root) 308 : netstat -rn | grep ^10.0..\.
  10.0.2.010.172.64.1 255.255.254.0   UG0 0  0 tun0
  10.0.3.00.0.0.0 255.255.255.0   U 0 0  0 
lxcbr0

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1358306/+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