[Touch-packages] [Bug 1537125] Re: ubuntu-14.04.04: fail to run systemtap test suites

2016-04-06 Thread Dan Streetman
> I tested systemtap on latest ubuntu16.04 ,make check error and other failures are not yet fixed. it works fine for me, although i'm on x86 so you may be seeing a ppc64-specific failure? # uname -a Linux systemtap 4.4.0-17-generic #33-Ubuntu SMP Tue Mar 29 17:17:28 UTC 2016 x86_64 x86_64

[Touch-packages] [Bug 1537125] Re: ubuntu-14.04.04: fail to run systemtap test suites

2016-03-29 Thread Dan Streetman
> /usr/share/systemtap/runtime/linux/print.c:242:20: error: ?struct module? has > no member named ?module_core? > THIS_MODULE->module_core, ... > root@ubuntu:~/systemtap-2.9# uname -a > Linux ubuntu 4.4.0-15-generic #31-Ubuntu SMP Fri Mar 18 19:06:23 UTC 2016 > ppc64le ppc64le ppc64le GNU/Linux

[Touch-packages] [Bug 1609367] [NEW] ifupdown does not set ipv6-only large mtu

2016-08-03 Thread Dan Streetman
Public bug reported: ifupdown changes a device's mtu differently, between "inet" section mtu and "inet6" section mtu. For "inet", ifupdown changes the device's mtu, using 'ip link set DEV mtu NNN'. However for "inet6", ifupdown changes the interface's IPv6 mtu, using 'sysctl -q -e -w

[Touch-packages] [Bug 1609367] Re: ifupdown does not set ipv6-only large mtu

2016-08-04 Thread Dan Streetman
> and the tl;dr is that IPv6 supports per protocol, rather than interface. the ipv6 mtu is for situations where the host's ipv6 connection uses (at some point down the line) ipv6 tunneling, for example 6in4 or 6rd. The ipv6 mtu is strictly a subset of the device mtu; it can never be more than

[Touch-packages] [Bug 1609367] Re: ifupdown does not set ipv6-only large mtu

2016-08-04 Thread Dan Streetman
> In the original bug where one is comparing ip output of MTU; is there something *not* working ? in that original bug, the user is trying to set up ipv6 tunneling: "This scenario is quiet common when using tunnels (e.g. Sixxs) to provide IPv6 connectivity. My IPv6 MTU needs to be 20 bytes

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

2016-08-05 Thread Dan Streetman
> In what circumstances do dhcpv6 servers hand out an IPv6 address without also > reporting > the prefix length the client should use? Something seems wrong here. (Is it > me? :) unfortunately the dhcpv6 spec (RFC 3315) doesn't provide a way for a dhcpv6 server to tell a client what the

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

2016-08-04 Thread Dan Streetman
** Patch added: "lp1609898.debdiff" https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1609898/+attachment/4714179/+files/lp1609898.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu.

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

2016-08-04 Thread Dan Streetman
yakkety build also at ppa -- 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

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

2016-08-04 Thread Dan Streetman
Public bug reported: [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

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

2016-08-04 Thread Dan Streetman
** Patch added: "lp1609898-yakkety.debdiff" https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1609898/+attachment/4714232/+files/lp1609898-yakkety.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to isc-dhcp in

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

2016-08-04 Thread Dan Streetman
Patched builds for precise, trusty, xenial at ppa: https://launchpad.net/~ddstreet/+archive/ubuntu/lp1609898 -- 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:

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

2016-08-04 Thread Dan Streetman
** Patch added: "lp1609898-precise.debdiff" https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1609898/+attachment/4714181/+files/lp1609898-precise.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to isc-dhcp in

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

2016-08-04 Thread Dan Streetman
** Patch added: "lp1609898-trusty.debdiff" https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1609898/+attachment/4714182/+files/lp1609898-trusty.debdiff ** Patch removed: "lp1609898.debdiff"

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

2016-08-04 Thread Dan Streetman
** Patch added: "lp1609898-xenial.debdiff" https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1609898/+attachment/4714183/+files/lp1609898-xenial.debdiff ** Changed in: isc-dhcp (Ubuntu) Assignee: (unassigned) => Dan Streetman (ddstreet) ** Changed in: isc

[Touch-packages] [Bug 1609367] Re: ifupdown does not set ipv6-only large mtu

2016-08-09 Thread Dan Streetman
> I understand this scenario; however, what I don't understand is why > if we're setting mtu 9002 on the underlying devices, why the mtu on the > "virtual" device (bond0) > matters vs. the mtu setting of the ipv6 link, especially since this is ipv6 > only. I think the slave interface mtu will be

[Touch-packages] [Bug 1647485] Re: NVMe symlinks broken by devices with spaces in model or serial strings

2017-02-07 Thread Dan Streetman
with udev version 204-5ubuntu20.22 the /dev/disk/by-id/ symlinks are incorrect: ubuntu@ip-172-31-27-212:/dev/disk/by-id$ apt list --installed udev Listing... Done udev/trusty-updates,now 204-5ubuntu20.22 amd64 [installed,upgradable to: 204-5ubuntu20.24] ubuntu@ip-172-31-27-212:/dev/disk/by-id$

[Touch-packages] [Bug 1647485] Re: NVMe symlinks broken by devices with spaces in model or serial strings

2017-01-31 Thread Dan Streetman
Has this been committed into trusty yet? I rebased my trusty pull request from comment 24; those patches will apply cleaning into the trusty systemd repository. I'm not sure if there is any other bug holding up trusty. -- You received this bug notification because you are a member of Ubuntu

[Touch-packages] [Bug 1647485] Re: NVMe symlinks broken by devices with spaces in model or serial strings

2017-01-27 Thread Dan Streetman
> 1) The mechanism employed of redirecting s and l (destination buffer and > length remaining count) means that the code inside the redirection is > incredibly fragile. The code inside the switch should be pulled out into > a separate function. Then the redirection would become unnecessary.

[Touch-packages] [Bug 1647485] Re: NVMe symlinks broken by devices with spaces in model or serial strings

2017-01-25 Thread Dan Streetman
> Could someone please look at the autopkgtest regressions in > http://people.canonical.com/~ubuntu- > archive/pending-sru.html against systemd please? I'll ignore the no-longer-supported LTS kernel tests, so that leaves: > Regression in autopkgtest for network-manager (ppc64el): test log This

[Touch-packages] [Bug 1647485] Re: NVMe symlinks broken by devices with spaces in model or serial strings

2017-01-25 Thread Dan Streetman
So the only new autopkgtest failures are: > Regression in autopkgtest for umockdev (armhf): test log this fails with: ERROR:tests/test-umockdev-record.c:706:t_system_single: assertion failed (_tmp10_ == ""): ("Cannot access device /dev/loop0: No such file or directory\n" == "") this is the

[Touch-packages] [Bug 1647485] Re: NVMe symlinks broken by devices with spaces in model or serial strings

2017-01-20 Thread Dan Streetman
Verified with udev 229-4ubuntu16, all /dev/disk/by-id/ NVMe symlinks are present and correct. ** 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 systemd in

[Touch-packages] [Bug 1565804] Re: ifup of vlan interfaces failing during networking start - RTNETLINK answers: File exists

2016-09-08 Thread Dan Streetman
This is a side effect / duplicate of bug 1224007. The initial problem is the high vlan mtu setting, and the "File Exists" error is because ifup doesn't unwind on failure, so the interface is ip but not configured, which causes ifup to keep failing because it isn't expecting the interface to

[Touch-packages] [Bug 1224007] Re: mtu not always set properly on bond/vlan interface

2016-09-07 Thread Dan Streetman
I should note that this is marked as Fix Released in debian, but from the debian bug comments it just looks like Chris asked for that bug to be closed as a configuration issue (which this is not). This is actually only a VLAN issue with higher-than-default mtu. The bond does not have anything to

[Touch-packages] [Bug 1224007] Re: mtu not always set properly on bond/vlan interface

2016-09-07 Thread Dan Streetman
** Also affects: vlan (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/1224007 Title: mtu not always set properly on

[Touch-packages] [Bug 1224007] Re: mtu not always set properly on bond/vlan interface

2016-09-09 Thread Dan Streetman
** Patch added: "debdiff for yakkety vlan" https://bugs.launchpad.net/ubuntu/+source/vlan/+bug/1224007/+attachment/4737643/+files/lp1224007-yakkety.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ifupdown in

[Touch-packages] [Bug 1224007] Re: mtu not always set properly on bond/vlan interface

2016-09-09 Thread Dan Streetman
** Patch added: "patch to yakkety debian/network/if-pre-up.d/vlan script" https://bugs.launchpad.net/ubuntu/+source/vlan/+bug/1224007/+attachment/4737642/+files/lp1224007-yakkety.patch -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is

[Touch-packages] [Bug 1224007] Re: mtu not always set properly on bond/vlan interface

2016-09-09 Thread Dan Streetman
pls ignore patch from above comment; i have a simpler one i'll attach. -- 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/1224007 Title: mtu not always set properly on

[Touch-packages] [Bug 1609367] Re: ifupdown does not set ipv6-only large mtu

2016-09-09 Thread Dan Streetman
> I believe the decision is to add the scripts to ifupdown in y or z only (no SRU) or, we can just close this as wontfix and explain how to work around this by adding a manual inet section with the increased mtu value, since that's quite easy to do when manually configuring ifupdown. -- You

[Touch-packages] [Bug 1609367] Re: ifupdown does not set ipv6-only large mtu

2016-09-09 Thread Dan Streetman
To follow up, I believe the decision is to add the scripts to ifupdown in y or z only (no SRU), and fix this for older releases in curtin via bug 1609861. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ifupdown in Ubuntu.

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

2016-09-12 Thread Dan Streetman
tested on yakkety: using isc-dhcp-client 4.3.3-5ubuntu13, bug exists; dhcpv6 prefix is set to /64. using isc-dhcp-client 4.3.3-5ubuntu13.1, bug is fixed; dhcpv6 prefix is set correctly to /128. ** Tags added: verification-done-yakkety -- You received this bug notification because you are a

[Touch-packages] [Bug 1224007] Re: mtu not always set properly on bond/vlan interface

2016-09-12 Thread Dan Streetman
** Patch added: "patchv2 to yakkety debian/network/if-pre-up.d/vlan script" https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1224007/+attachment/4739533/+files/lp1224007-yakkety-v2.patch -- You received this bug notification because you are a member of Ubuntu Touch seeded packages,

[Touch-packages] [Bug 1224007] Re: mtu not always set properly on bond/vlan interface

2016-09-12 Thread Dan Streetman
sorry, the first patch had an issue where it didn't raise the device mtu if the vlan already existed. the v2 checks and increases if needed the dev mtu, even if the vlan already exists. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is

[Touch-packages] [Bug 1224007] Re: mtu not always set properly on bond/vlan interface

2016-09-12 Thread Dan Streetman
** Patch added: "debdiffv2 for yakkety vlan" https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1224007/+attachment/4739534/+files/lp1224007-yakkety-v2.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ifupdown

[Touch-packages] [Bug 1327412] Re: Delay during PXE Boot, IP-Config gives up

2016-09-15 Thread Dan Streetman
Opened bug 1624014 to patch the wrong-bit regression. -- 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/1327412 Title: Delay during PXE Boot, IP-Config gives up Status in

[Touch-packages] [Bug 1624014] Re: Wrong bit set in klibc PXE dhcp/bootp flags

2016-09-15 Thread Dan Streetman
PPA containing fixed klibc pkg: https://launchpad.net/~ddstreet/+archive/ubuntu/lp1624014 -- 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/1624014 Title: Wrong bit set in

[Touch-packages] [Bug 1624014] [NEW] Wrong bit set in klibc PXE dhcp/bootp flags

2016-09-15 Thread Dan Streetman
Public bug reported: [Description] The patch for bug 1327412 set the wrong bit in the bootp flags field. It set flags to 0x800, but the correct value is 0x8000. That sets the "broadcast" bit, and the spec requires all other bits to be 0. Setting one of the "must be zero" bits in the flags

[Touch-packages] [Bug 1624014] Re: Wrong bit set in klibc PXE dhcp/bootp flags

2016-09-15 Thread Dan Streetman
** Patch added: "patch to correct the bootp flags broadcast bit position" https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1624014/+attachment/4741482/+files/lp1624014.patch -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is

[Touch-packages] [Bug 1624014] Re: Wrong bit set in klibc PXE dhcp/bootp flags

2016-09-15 Thread Dan Streetman
** Patch added: "debdiff for xenial" https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1624014/+attachment/4741484/+files/lp1624014-xenial.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to klibc in Ubuntu.

[Touch-packages] [Bug 1624014] Re: Wrong bit set in klibc PXE dhcp/bootp flags

2016-09-15 Thread Dan Streetman
** Patch added: "debdiff for trusty" https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1624014/+attachment/4741483/+files/lp1624014-trusty.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to klibc in Ubuntu.

[Touch-packages] [Bug 1624014] Re: Wrong bit set in klibc PXE dhcp/bootp flags

2016-09-15 Thread Dan Streetman
** Patch added: "debdiff for yakkety" https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1624014/+attachment/4741485/+files/lp1624014-yakkety.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to klibc in Ubuntu.

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

2016-09-15 Thread Dan Streetman
I assume you mean these 2 failing tests, below; that's correct behavior now, the tests should be changed to expect a /128 DHCPv6 address instead of a /64 DHCPv6 address. == FAIL: test_open_b_ip6_dhcp (__main__.T) Open network,

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

2016-09-15 Thread Dan Streetman
tested on trusty: using isc-dhcp-client 4.2.4-7ubuntu12.6, bug exists; dhcpv6 prefix is set to /64. using isc-dhcp-client 4.2.4-7ubuntu12.7, bug is fixed; dhcpv6 prefix is set correctly to /128. ** Tags removed: verification-needed ** Tags added: verification-done-trusty -- You received this

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

2016-09-15 Thread Dan Streetman
tested on precise: using isc-dhcp-client 4.1.ESV-R4-0ubuntu5.10, bug exists; dhcpv6 prefix is set to /64. using isc-dhcp-client 4.1.ESV-R4-0ubuntu5.11, bug is fixed; dhcpv6 prefix is set correctly to /128. ** Tags added: verification-done-precise -- You received this bug notification because

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

2016-09-15 Thread Dan Streetman
** Patch added: "lp1609898-nm-yakkety.debdiff" https://bugs.launchpad.net/ubuntu/precise/+source/network-manager/+bug/1609898/+attachment/4741543/+files/lp1609898-nm-yakkety.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is

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

2016-09-15 Thread Dan Streetman
** Also affects: network-manager (Ubuntu) Importance: Undecided Status: New ** Changed in: network-manager (Ubuntu Precise) Status: New => Invalid ** Patch added: "debdiff to fix network manager test in trusty"

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

2016-09-15 Thread Dan Streetman
The attached debdiffs lp1609898-nm-[trusty|xenial|yakkety].debdiff patch network-manager's debian/tests/wpa-dhclient test to use /128 instead of /64 for its DHCPv6 address test. Note it leaves the ipv6 Router Advertisement provided addresses with /64, as that prefix length is provided to the

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

2016-09-15 Thread Dan Streetman
** Patch added: "lp1609898-nm-xenial.debdiff" https://bugs.launchpad.net/ubuntu/precise/+source/network-manager/+bug/1609898/+attachment/4741542/+files/lp1609898-nm-xenial.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is

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

2016-09-12 Thread Dan Streetman
tested on xenial: using isc-dhcp-client 4.3.3-5ubuntu12.1, bug exists; dhcpv6 prefix is set to /64. using isc-dhcp-client 4.3.3-5ubuntu12.2, bug is fixed; dhcpv6 prefix is correctly set to /128. ** Tags removed: verification-needed ** Tags added: verification-done-xenial -- You received this

[Touch-packages] [Bug 1013597] Re: No default route for stateful DHCPv6

2016-09-24 Thread Dan Streetman
** Changed in: ifupdown (Ubuntu) Assignee: (unassigned) => Dan Streetman (ddstreet) ** Changed in: ifupdown (Ubuntu Precise) Assignee: (unassigned) => Dan Streetman (ddstreet) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages,

[Touch-packages] [Bug 1510098] Re: /etc/network/interfaces ipv6 static gateway not set

2016-09-24 Thread Dan Streetman
15.10 is EOL, and this does seem to work in 16.04. Please reopen if you still have this problem in 16.04. ** Changed in: ifupdown (Ubuntu) Status: Confirmed => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to

[Touch-packages] [Bug 1543352] Re: inet6 dhcp doesn't wait for link-local address to leave tentative - dhclient fails to bind

2016-09-24 Thread Dan Streetman
This is being worked in bug 1447715. -- 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/1543352 Title: inet6 dhcp doesn't wait for link-local address to leave tentative -

[Touch-packages] [Bug 1543352] Re: inet6 dhcp doesn't wait for link-local address to leave tentative - dhclient fails to bind

2016-09-24 Thread Dan Streetman
@jacob11, I understand your frustration. All I can do is fix the bug. -- 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/1543352 Title: inet6 dhcp doesn't wait for

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

2016-09-21 Thread Dan Streetman
This is fixed in debian ifupdown 0.8.11 by this patch: --- ifupdown-0.8.10/wait-for-ll6.sh 2015-12-01 16:50:26.0 -0500 +++ ifupdown-0.8.11/wait-for-ll6.sh 2016-04-20 08:57:37.0 -0400 @@ -4,7 +4,7 @@ delay=${IF_LL_INTERVAL:-0.1} for attempt in $(seq 1 $attempts); do -

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

2016-09-21 Thread Dan Streetman
** Patch added: "lp1447715-xenial.debdiff" https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1447715/+attachment/4745626/+files/lp1447715-xenial.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ifupdown in

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

2016-09-23 Thread Dan Streetman
For anyone reading this because the isc-dhcp-client update broke their DHCPv6 network: First, I assume you're running a DHCPv6 server to provide the ipv6 addresses to your clients. If you do not have any Router Advertisement service configured on your server, the easiest thing to do is use

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

2016-09-23 Thread Dan Streetman
Also note that dnsmasq can act as both a dhcpv6 server as well as serving router advertisements. The ISC dhcp server only does dhcpv6, it does not have support (that I know of) for serving router advertisements. If you do want your clients to use slaac addresses in addition to the dhcpv6

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

2016-09-23 Thread Dan Streetman
And yakkety has ifupdown 0.8.13 which contains the fix already. ** Tags added: sts-sru -- 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/1447715 Title: dhclient -6: Can't

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

2016-09-23 Thread Dan Streetman
I tested on precise and trusty, and this problem doesn't appear there, so only xenial requires the ifupdown SRU. ** Changed in: ifupdown (Ubuntu Trusty) Status: In Progress => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is

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

2016-09-21 Thread Dan Streetman
@arges, yep the attached lp1609898-nm-[trusty|xenial|yakkety].debdiff patches update network-manager's test script to the new behavior. I can pull the patches out of the debdiffs, if that's easier. I did a brief search in the network-manager tests and didn't find any other place that looks like

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

2016-09-21 Thread Dan Streetman
Unfortunately, while I initially put in the bug description that there was no regresssion potential, I've been made aware that some network configurations rely on the previous (incorrect) behavior of the dhcp client to set a prefix len of /64. Such configurations will break when the dhcp clients

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

2016-09-22 Thread Dan Streetman
** Changed in: ifupdown (Ubuntu Xenial) Assignee: (unassigned) => Dan Streetman (ddstreet) ** Changed in: ifupdown (Ubuntu Precise) Assignee: (unassigned) => Dan Streetman (ddstreet) ** Changed in: ifupdown (Ubuntu Trusty) Assignee: (unassigned) => Dan Streetman

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

2016-09-21 Thread Dan Streetman
ng in wily. ** Changed in: ifupdown (Ubuntu) Assignee: (unassigned) => Dan Streetman (ddstreet) -- 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/1447715 Title:

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

2016-09-21 Thread Dan Streetman
** Description changed: - 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: + (Original bug description follows SRU info) + + [Description] + + When using dhcpv6 configured via

[Touch-packages] [Bug 1609367] Re: ifupdown does not set ipv6-only large mtu

2016-08-26 Thread Dan Streetman
Ryan are you working on adding the script to ifupdown in ubuntu and/or debian? -- 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/1609367 Title: ifupdown does not set

[Touch-packages] [Bug 1609367] Re: ifupdown does not set ipv6-only large mtu

2016-08-29 Thread Dan Streetman
> While we could see about getting the script included in yakkety (or y+1); > curtin will still need to > handle this unless we want to SRU ifdowndown in precise, trusty and > xenial. This has an enormous > impact; so it's not something we should take lightly. As long as curtin handles it

[Touch-packages] [Bug 1609367] Re: ifupdown does not set ipv6-only large mtu

2016-08-22 Thread Dan Streetman
> if we have a higher mtu onthe ipv6 link, like 4800, then the inet section > mtu setting clobbers it and they both end up at 1500. > > Now, that case I still believe is *invalid* configuration; I agree - if the ifupdown config has the inet mtu set lower than the inet6 mtu, that's a

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

2016-11-07 Thread Dan Streetman
** Tags added: sts-sponsor -- 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/1447715 Title: dhclient -6: Can't bind to dhcp address: Cannot assign requested address

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

2016-11-07 Thread Dan Streetman
update for this: this patch is already included upstream in debian, and is already included in yakkety. It's not yet in xenial. It's not required in trusty (bug doesn't exist there). additionally, bug 1633479 (which fixes this by putting the DAD wait in isc-dhcp-client) is in proposed for

[Touch-packages] [Bug 1628552] Re: on startup gateway & dns- options in /etc/network/interfaces are not always set

2016-10-20 Thread Dan Streetman
> well i've now been able to restart 3 of the 4 systems about 5-10x each > through the day. all have > had their gateway and dns- settings from /e/n/i reliably set. that is, until > now. i've got one > system that did not get gateway or dns- settings. The gateway is set directly from ifup (by

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

2016-10-20 Thread Dan Streetman
> The use case I found was in initramfs-tools, which recently SRU'd a change > that uses dhclient to > support 'ip=' command lines and dhcpv6. aha, and busybox ip doesn't support the -tentative param that the ifupdown change uses. +1 on fixing isc-dhcp then (as well as leaving this fix in

[Touch-packages] [Bug 1624014] Re: Wrong bit set in klibc PXE dhcp/bootp flags

2016-11-16 Thread Dan Streetman
to clarify, tcpdump with klibc-utils 2.0.3-0ubuntu1.14.04.1 shows the flag is 0x0800 (incorrect) while tcpdump with klibc-utils 2.0.3-0ubuntu1.14.04.2 (from -proposed) shows the flag is 0x8000 (correct). -- You received this bug notification because you are a member of Ubuntu Touch seeded

[Touch-packages] [Bug 1624014] Re: Wrong bit set in klibc PXE dhcp/bootp flags

2016-11-16 Thread Dan Streetman
I confirmed the fix is correct in trusty by tcpdumping a run of /usr/lib/klibc/bin/ipconfig ** Tags removed: verification-needed-trusty ** Tags added: verification-done-trusty -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to

[Touch-packages] [Bug 1642903] Re: introduce disk/by-id (model_serial) symlinks for NVMe drives

2016-11-18 Thread Dan Streetman
** Patch added: "lp1642903-yakkety.debdiff" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1642903/+attachment/4779386/+files/lp1642903-yakkety.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in

[Touch-packages] [Bug 1642903] Re: introduce disk/by-id (model_serial) symlinks for NVMe drives

2016-11-18 Thread Dan Streetman
** Patch added: "lp1642903-trusty.debdiff" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1642903/+attachment/4779388/+files/lp1642903-trusty.debdiff ** Tags added: sts sts-sponsor sts-sru -- You received this bug notification because you are a member of Ubuntu Touch seeded

[Touch-packages] [Bug 1642903] Re: introduce disk/by-id (model_serial) symlinks for NVMe drives

2016-11-18 Thread Dan Streetman
** Patch added: "lp1642903-xenial.debdiff" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1642903/+attachment/4779387/+files/lp1642903-xenial.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in

[Touch-packages] [Bug 1642903] Re: introduce disk/by-id (model_serial) symlinks for NVMe drives

2016-11-18 Thread Dan Streetman
This is fixed with commit a5110c90303cf455db5062faef34d5724d12e2e9 from upstream systemd, which is already included in zesty. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu.

[Touch-packages] [Bug 1642903] [NEW] introduce disk/by-id (model_serial) symlinks for NVMe drives

2016-11-18 Thread Dan Streetman
Public bug reported: [Impact] NVMe drives can't be identified/accessed via /dev/disk/by-id/nvme-SERIAL symlinks. [Test Case] On a system with an NVMe drive, check the /dev/disk/by-id/ directory; with the patch, it will contain link(s) named by the drive serial number. [Regression Potential]

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

2016-10-14 Thread Dan Streetman
> The fix i intended was to dhclient, so that dhclient would wait in PREINIT6 dhclient-script. Looks good to me, fixing dhclient as well is a good idea. > I think that is generally more functional as it would mean ifupdown or any > other user of dhclient > would get the fix. What other users

[Touch-packages] [Bug 1647485] Re: NVMe symlinks broken by devices with spaces in model or serial strings

2016-12-06 Thread Dan Streetman
** Description changed: [Impact] After including the patch from bug 1642903, NVMe devices that include spaces in their model or serial strings result in incorrect symlinks, e.g. if the model string is "XYZ Corp NVMe drive" then instead of creating: /dev/disk/by-id/nvme-XYZ Corp NVMe

[Touch-packages] [Bug 1647485] Re: NVMe symlinks broken by devices with spaces in model or serial strings

2016-12-06 Thread Dan Streetman
** Patch added: "lp1647485-xenial.debdiff" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1647485/+attachment/4788139/+files/lp1647485-xenial.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in

[Touch-packages] [Bug 1647485] Re: NVMe symlinks broken by devices with spaces in model or serial strings

2016-12-06 Thread Dan Streetman
** Patch added: "lp1647485-yakkety.debdiff" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1647485/+attachment/4788138/+files/lp1647485-yakkety.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in

[Touch-packages] [Bug 1647485] Re: NVMe symlinks broken by devices with spaces in model or serial strings

2016-12-06 Thread Dan Streetman
** Patch added: "lp1647485-trusty.debdiff" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1647485/+attachment/4788140/+files/lp1647485-trusty.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in

[Touch-packages] [Bug 1647485] Re: NVMe symlinks broken by devices with spaces in model or serial strings

2016-12-06 Thread Dan Streetman
** Patch added: "lp1647485-zesty.debdiff" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1647485/+attachment/4788137/+files/lp1647485-zesty.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in

[Touch-packages] [Bug 1647485] Re: NVMe symlinks broken by devices with spaces in model or serial strings

2016-12-06 Thread Dan Streetman
debdiffs added for t/x/y/z that add all 3 patches proposed in the upstream bug, that: -change udev to replace spaces in all SYMLINK values by default (unless option string_escape=none is used by a rule) -update test/udev-test.pl test case to use string_escape=none option for test cases that use

[Touch-packages] [Bug 1642903] Re: introduce disk/by-id (model_serial) symlinks for NVMe drives

2016-12-12 Thread Dan Streetman
> Note that there is a current SRU in trusty which blocks this. is that current SRU for bug 1562344? > But this being "wishlist" it's not > that urgent anyway, This isn't really wishlist, this is needed to persistently identify NVMe drives on systems with multiple drives. > and my gut feeling

[Touch-packages] [Bug 1647485] Re: NVMe symlinks broken by devices with spaces in model or serial strings

2016-12-12 Thread Dan Streetman
** Patch removed: "lp1647485-trusty.debdiff" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1647485/+attachment/4788261/+files/lp1647485-trusty.debdiff ** Patch removed: "lp1647485-xenial.debdiff"

[Touch-packages] [Bug 1647485] Re: NVMe symlinks broken by devices with spaces in model or serial strings

2016-12-12 Thread Dan Streetman
> Note that there is not much point with debdiffs, it's easier to cherry-pick > the fix directly into > the packaging branches with gbp pq and debian/git-cherry-pick. ok, I removed the debdiffs as they're not needed. I did attach a single patch, that works around the bug in a simple way, by

[Touch-packages] [Bug 1647485] Re: NVMe symlinks broken by devices with spaces in model or serial strings

2016-12-06 Thread Dan Streetman
** Patch added: "lp1647485-xenial.debdiff" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1647485/+attachment/4788262/+files/lp1647485-xenial.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in

[Touch-packages] [Bug 1647485] Re: NVMe symlinks broken by devices with spaces in model or serial strings

2016-12-06 Thread Dan Streetman
** Patch added: "lp1647485-trusty.debdiff" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1647485/+attachment/4788261/+files/lp1647485-trusty.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in

[Touch-packages] [Bug 1647485] Re: NVMe symlinks broken by devices with spaces in model or serial strings

2016-12-06 Thread Dan Streetman
** Patch added: "lp1647485-zesty.debdiff" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1647485/+attachment/4788264/+files/lp1647485-zesty.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in

[Touch-packages] [Bug 1647485] Re: NVMe symlinks broken by devices with spaces in model or serial strings

2016-12-06 Thread Dan Streetman
** Patch added: "lp1647485-yakkety.debdiff" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1647485/+attachment/4788263/+files/lp1647485-yakkety.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in

[Touch-packages] [Bug 1647485] Re: NVMe symlinks broken by devices with spaces in model or serial strings

2016-12-06 Thread Dan Streetman
debdiffs updated to include (LP: #1647485) in changelog -- 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/1647485 Title: NVMe symlinks broken by devices with spaces in model

[Touch-packages] [Bug 1647485] Re: NVMe symlinks broken by devices with spaces in model or serial strings

2016-12-06 Thread Dan Streetman
This tarball contains debdiffs for x/y/z that *workaround* - not fix - the problem, by adding the string_escape=replace option to the NVMe rules that create the model/serial symlinks. This is possible as a temporary alternative to the real fix to udev. Unlike the real fix, which will change the

[Touch-packages] [Bug 1647485] Re: NVMe symlinks broken by devices with spaces in model or serial strings

2016-12-06 Thread Dan Streetman
https://github.com/systemd/systemd/issues/4833 ** Bug watch added: github.com/systemd/systemd/issues #4833 https://github.com/systemd/systemd/issues/4833 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu.

[Touch-packages] [Bug 1640293] Re: Backport graphical-session{, -pre}.target to xenial

2016-12-14 Thread Dan Streetman
I verified this does add the targets, without enabling them. with systemd 229-4ubuntu7: ubuntu@lp1640293:~$ systemctl --user status graphical-session{,-pre}.target ● graphical-session.target Loaded: not-found (Reason: No such file or directory) Active: inactive (dead) ●

[Touch-packages] [Bug 1647485] Re: NVMe symlinks broken by devices with spaces in model or serial strings

2017-01-13 Thread Dan Streetman
Yakkety: with udev 231-9ubuntu2, the /dev/disk/by-id/ NVMe symlinks were not created correctly: $ ls -l /dev/disk/by-id/ total 0 lrwxrwxrwx 1 root root 13 Jan 13 22:34 nvme-Amazon -> ../../nvme2n1 and with udev 231-9ubuntu3, the /dev/disk/by-id/ NVMe symlinks are created correctly: $ ls -l

[Touch-packages] [Bug 1647485] Re: NVMe symlinks broken by devices with spaces in model or serial strings

2017-01-13 Thread Dan Streetman
Xenial: with udev 229-4ubuntu13, the /dev/disk/by-id/ NVMe symlinks were not correctly created: $ ls -l /dev/disk/by-id/ total 0 lrwxrwxrwx 1 root root 13 Jan 13 22:01 nvme-Amazon -> ../../nvme0n1 and with udev 229-4ubuntu15 from -proposed, the /dev/disk/by-id/ NVMe symlinks were correctly

[Touch-packages] [Bug 1647485] Re: NVMe symlinks broken by devices with spaces in model or serial strings

2017-01-09 Thread Dan Streetman
Regarding the workaround patch from comment 17, I should note that the workaround involves replacing all whitespace in the NVMe model or serial string with underscores. This matches what is done for the by-id symlinks for scsi, ata, and all other buses. However, another possibility is instead of

[Touch-packages] [Bug 1647485] Re: NVMe symlinks broken by devices with spaces in model or serial strings

2017-01-12 Thread Dan Streetman
My pull request has been merged upstream, the commits are: 0a10235 udev-rules: perform whitespace replacement for symlink subst values e20a917 udev-event: add replace_whitespace param to udev_event_apply_format a9d99b3 libudev-util: change util_replace_whitespace to return number of chars in

[Touch-packages] [Bug 1647485] Re: NVMe symlinks broken by devices with spaces in model or serial strings

2017-01-12 Thread Dan Streetman
** Also affects: systemd (Debian) via http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851164 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu.

  1   2   3   4   5   6   7   8   9   10   >