[Group.of.nepali.translators] [Bug 1738998] Re: netplan does not allow dhcp client identifier type to be specified
This bug was fixed in the package nplan - 0.32~16.04.5 --- nplan (0.32~16.04.5) xenial; urgency=medium * bond/bridge: Support suffixes for time-based values so things like "mii-monitor-interval" can support milliseconds. (LP: #1745597) * Do not attempt to rebind driver 'qeth'. (LP: #1756322) * Allow setting ClientIdentifier=mac for networkd-renderered devices (LP: #1738998) * IPv6: accept-ra should default to being unset, so that the kernel default can be used. (LP: #1732002) * doc/netplan.md: Clarify the behavior for time-based values for bonds and bridges. (LP: #1756587) * critical: provide a way to set "CriticalConnection=true" on a networkd connection, especially for remote-fs scenarios. (LP: #1769682) * networkd: don't wipe out /run/netplan on generate: we do want to keep any YAML configurations in that directory, we just need to remove generated wpasupplicant configs. (LP: #1764869) -- Mathieu Trudel-Lapierre Tue, 08 May 2018 10:36:24 -0400 ** Changed in: nplan (Ubuntu Xenial) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1738998 Title: netplan does not allow dhcp client identifier type to be specified Status in netplan: Fix Released Status in nplan package in Ubuntu: Fix Released Status in nplan source package in Xenial: Fix Released Status in nplan source package in Artful: Fix Released Bug description: [Impact] Users of Ubuntu dealing with a DHCP server based on Windows Server, Solarwinds IPAM, or possibly other DHCP server products that do no support RFC 4361. [Test case] -- requires a Windows Server DHCP setup, or another product without support for client identifier DUIDs. 1) Configure a reservation for the device, using the device's MAC address. 2) Configure the device for DHCP: network: version: 2 renderer: networkd ethernets: eth0: dhcp4: yes dhcp-identifier: mac 3) Run 'netplan apply' 4) Verify that 'netplan apply' completes successfully, and that the expected IP address is received as part of the reservation. It may be required to clear the DHCP server's cache of DHCP requests/responses. [Regression potential] These DHCP behavior changes may lead to systems not receiving the same IP as they previously did on reservations from a DHCP server; the default is not changing from using DUIDs so unchanged configurations should not be affected at all, but changes to add the new feature will likely change the IP address returned to the client from the DHCP server. Additionally, failure to parse netplan configuration or invalid DHCP behavior should be investigated as possible regressions coming from this SRU. To manage notifications about this bug go to: https://bugs.launchpad.net/netplan/+bug/1738998/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1732002] Re: cloud images in lxc get ipv6 address
This bug was fixed in the package nplan - 0.32~17.10.4 --- nplan (0.32~17.10.4) artful; urgency=medium * bond/bridge: Support suffixes for time-based values so things like "mii-monitor-interval" can support milliseconds. (LP: #1745597) * debian/postinst: Write breadcrumbs on disk in /etc/network/interfaces to denote the migration to using netplan. (LP: #1756742) * DHCPv4: add a "dhcp-identifier: mac" field that can be set to fix interop with Windows Server-based DHCP servers which don't support RFC 4361. (LP: #1738998) * IPv6: accept-ra should default to being unset, so that the kernel default can be used. (LP: #1732002) * doc/netplan.md: Clarify the behavior for time-based values for bonds and bridges. (LP: #1756587) * critical: provide a way to set "CriticalConnection=true" on a networkd connection, especially for remote-fs scenarios. (LP: #1769682) * networkd: don't wipe out /run/netplan on generate: we do want to keep any YAML configurations in that directory, we just need to remove generated wpasupplicant configs. (LP: #1764869) -- Mathieu Trudel-Lapierre Tue, 08 May 2018 11:04:30 -0400 ** Changed in: nplan (Ubuntu Artful) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1732002 Title: cloud images in lxc get ipv6 address Status in nplan package in Ubuntu: Fix Released Status in systemd package in Ubuntu: New Status in nplan source package in Xenial: Fix Released Status in nplan source package in Artful: Fix Released Bug description: [Impact] All users of netplan. [Test case] == LXD containers == 1) Start an LXD container (artful or bionic) 2) Verify that an IPv6 address is present 3) Verify that the system is brought up in a reasonable time (does not wait 2 minutes to be reachable). == servers / cloud instances == 1) Start a bionic system, with no IPv6 connectivity (no router to advertise a prefix) 2) Verify that the system boots quickly (does not wait 2 minutes to be reachable). [Regression potential] Since this changes default IPv6 behavior, care should be taken to validate that systems are maintaining IPv6 connectivity when it is available, and similarly that systems where no IPv6 connectivity is available on the network are behaving correctly: there should not be long boot delays, and no extra IPv6 addresses aside from link-local addresses generated by the kernel. -- I noticed that lxd (lxc list) reports that an lxc container has an ipv6 address in artful or bionic. It does not list this in xenial or zesty. I suspect this change occurred in the switch over to netplan/networkd. This may at first seem harmless or even desired, but note that the user configuration did not request ipv6 config, so its presence is a bug. $ for rel in xenial zesty artful bionic; do lxc launch ubuntu-daily:$rel $rel-demo; done Creating xenial-demo Starting xenial-demo .. Creating bionic-demo Starting bionic-demo $ sleep 10 $ lxc list $ lxc list +-+-+--+++---+ |NAME | STATE | IPV4 | IPV6 |TYPE| SNAPSHOTS | +-+-+--+++---+ | artful-demo | RUNNING | 10.75.205.208 (eth0) | fd42:eee5:7c43:3d62:3a42:611c:3f6f:1184 (eth0) | PERSISTENT | 0 | +-+-+--+++---+ | bionic-demo | RUNNING | 10.75.205.187 (eth0) | fd42:eee5:7c43:3d62:6f4:155b:39cc:fc3d (eth0) | PERSISTENT | 0 | +-+-+--+++---+ | xenial-demo | RUNNING | 10.75.205.143 (eth0) | | PERSISTENT | 0 | +-+-+--+++---+ | zesty-demo | RUNNING | 10.75.205.123 (eth0) | | PERSISTENT | 0 | +-+-+--+++---+ ## Here is the config that was provided by lxd $ lxc exec bionic-demo cat /var/lib/cloud/seed/nocloud-net/network-config version: 1 config: - type: physical name: eth0 subnets: - type: dhcp control: auto ## Here is the config that cloud-init rendered. $ lxc exec bionic-demo -- grep -v '^#'
[Group.of.nepali.translators] [Bug 1732002] Re: cloud images in lxc get ipv6 address
This bug was fixed in the package nplan - 0.32~16.04.5 --- nplan (0.32~16.04.5) xenial; urgency=medium * bond/bridge: Support suffixes for time-based values so things like "mii-monitor-interval" can support milliseconds. (LP: #1745597) * Do not attempt to rebind driver 'qeth'. (LP: #1756322) * Allow setting ClientIdentifier=mac for networkd-renderered devices (LP: #1738998) * IPv6: accept-ra should default to being unset, so that the kernel default can be used. (LP: #1732002) * doc/netplan.md: Clarify the behavior for time-based values for bonds and bridges. (LP: #1756587) * critical: provide a way to set "CriticalConnection=true" on a networkd connection, especially for remote-fs scenarios. (LP: #1769682) * networkd: don't wipe out /run/netplan on generate: we do want to keep any YAML configurations in that directory, we just need to remove generated wpasupplicant configs. (LP: #1764869) -- Mathieu Trudel-Lapierre Tue, 08 May 2018 10:36:24 -0400 ** Changed in: nplan (Ubuntu Xenial) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1732002 Title: cloud images in lxc get ipv6 address Status in nplan package in Ubuntu: Fix Released Status in systemd package in Ubuntu: New Status in nplan source package in Xenial: Fix Released Status in nplan source package in Artful: Fix Released Bug description: [Impact] All users of netplan. [Test case] == LXD containers == 1) Start an LXD container (artful or bionic) 2) Verify that an IPv6 address is present 3) Verify that the system is brought up in a reasonable time (does not wait 2 minutes to be reachable). == servers / cloud instances == 1) Start a bionic system, with no IPv6 connectivity (no router to advertise a prefix) 2) Verify that the system boots quickly (does not wait 2 minutes to be reachable). [Regression potential] Since this changes default IPv6 behavior, care should be taken to validate that systems are maintaining IPv6 connectivity when it is available, and similarly that systems where no IPv6 connectivity is available on the network are behaving correctly: there should not be long boot delays, and no extra IPv6 addresses aside from link-local addresses generated by the kernel. -- I noticed that lxd (lxc list) reports that an lxc container has an ipv6 address in artful or bionic. It does not list this in xenial or zesty. I suspect this change occurred in the switch over to netplan/networkd. This may at first seem harmless or even desired, but note that the user configuration did not request ipv6 config, so its presence is a bug. $ for rel in xenial zesty artful bionic; do lxc launch ubuntu-daily:$rel $rel-demo; done Creating xenial-demo Starting xenial-demo .. Creating bionic-demo Starting bionic-demo $ sleep 10 $ lxc list $ lxc list +-+-+--+++---+ |NAME | STATE | IPV4 | IPV6 |TYPE| SNAPSHOTS | +-+-+--+++---+ | artful-demo | RUNNING | 10.75.205.208 (eth0) | fd42:eee5:7c43:3d62:3a42:611c:3f6f:1184 (eth0) | PERSISTENT | 0 | +-+-+--+++---+ | bionic-demo | RUNNING | 10.75.205.187 (eth0) | fd42:eee5:7c43:3d62:6f4:155b:39cc:fc3d (eth0) | PERSISTENT | 0 | +-+-+--+++---+ | xenial-demo | RUNNING | 10.75.205.143 (eth0) | | PERSISTENT | 0 | +-+-+--+++---+ | zesty-demo | RUNNING | 10.75.205.123 (eth0) | | PERSISTENT | 0 | +-+-+--+++---+ ## Here is the config that was provided by lxd $ lxc exec bionic-demo cat /var/lib/cloud/seed/nocloud-net/network-config version: 1 config: - type: physical name: eth0 subnets: - type: dhcp control: auto ## Here is the config that cloud-init rendered. $ lxc exec bionic-demo -- grep -v '^#' /etc/netplan/50-cloud-init.yaml network: version: 2 ethernets: eth0: dhcp4: true $ lxc exec bionic-demo cat
[Group.of.nepali.translators] [Bug 1745597] Re: mii-monitor-interval unit is undocumented, and may be wrong
This bug was fixed in the package nplan - 0.32~17.10.4 --- nplan (0.32~17.10.4) artful; urgency=medium * bond/bridge: Support suffixes for time-based values so things like "mii-monitor-interval" can support milliseconds. (LP: #1745597) * debian/postinst: Write breadcrumbs on disk in /etc/network/interfaces to denote the migration to using netplan. (LP: #1756742) * DHCPv4: add a "dhcp-identifier: mac" field that can be set to fix interop with Windows Server-based DHCP servers which don't support RFC 4361. (LP: #1738998) * IPv6: accept-ra should default to being unset, so that the kernel default can be used. (LP: #1732002) * doc/netplan.md: Clarify the behavior for time-based values for bonds and bridges. (LP: #1756587) * critical: provide a way to set "CriticalConnection=true" on a networkd connection, especially for remote-fs scenarios. (LP: #1769682) * networkd: don't wipe out /run/netplan on generate: we do want to keep any YAML configurations in that directory, we just need to remove generated wpasupplicant configs. (LP: #1764869) -- Mathieu Trudel-Lapierre Tue, 08 May 2018 11:04:30 -0400 ** Changed in: nplan (Ubuntu Artful) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1745597 Title: mii-monitor-interval unit is undocumented, and may be wrong Status in netplan: Fix Released Status in nplan package in Ubuntu: Fix Released Status in nplan source package in Xenial: Fix Released Status in nplan source package in Artful: Fix Released Bug description: [Impact] Users of bond and bridges devices requiring tuning of the default device parameters. [Test case] == Configure MII monitor interval == 1) Configure a bond device 2) Add parameters: bonds: mybond0: parameters: mii-monitor-interval: 1 3) Verify that the applied MII monitor interval is of 1ms, as opposed to 1 second (1000ms), by verifying the contents of /sys/class/net/mybond0/bonding/miimon == Validate default behavior == 1) Configure a bond device without parameters. 2) Verify that no special MII monitor interval is applied, the default value should be 0: $ cat /sys/class/net/mybond0/bonding/miimon 0 [Regression potential] MII monitor behavior is changing with this SRU. Default behavior for an unqualified value (ie. a number alone), which was also the only way to specify parameters, was to interpret the values as *seconds*. This leads to relatively slow checking of the device link status (for MII monitor), much slower than generally expected. The same applies to other time-based values such as up delay, down delay, arp interval. The interpretation for these values changes to reading them as *milliseconds* when unqualified, and a new way of qualifying the values (adding a modifier) was added. This was, people who do require "slow" checking of the MII link status will be migrated to "fast" checking right now, moving from an interval of 1 second to 1 millisecond (more checking means less false-negatives for packet passing through an interface, should reduce packet loss, at the cost of potentially flapping the interfaces (bringing down a path often if MII status is bad or slow to be returned)). Users who require the old behavior may add "s" at the end of the value to make it read as "1 second" again, or modify the value to be "1000", which will be 1000ms (1 second). We estimate the impact of this change to users to be minimal, actually requiring a 1 second interval for MII monitoring / up/down delay, and ARP interval is very uncommon and counter-intuitive as all other systems work on a millisecond basis. --- The manpage for netplan doesn't indicate what the unit for mii- monitor-interval is on bond devices. It appears to be in whole seconds, but at the kernel level, the unit is milliseconds. From my testing, it appears to be impossible to set a value for mii- monitor-interval with netplan that is <1s (e.g. I got a syntax error with a value of 0.1 for 100ms) To manage notifications about this bug go to: https://bugs.launchpad.net/netplan/+bug/1745597/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1756322] Re: 'netplan apply' fails when trying to activate another interface on another QETH device ...
This bug was fixed in the package nplan - 0.32~16.04.5 --- nplan (0.32~16.04.5) xenial; urgency=medium * bond/bridge: Support suffixes for time-based values so things like "mii-monitor-interval" can support milliseconds. (LP: #1745597) * Do not attempt to rebind driver 'qeth'. (LP: #1756322) * Allow setting ClientIdentifier=mac for networkd-renderered devices (LP: #1738998) * IPv6: accept-ra should default to being unset, so that the kernel default can be used. (LP: #1732002) * doc/netplan.md: Clarify the behavior for time-based values for bonds and bridges. (LP: #1756587) * critical: provide a way to set "CriticalConnection=true" on a networkd connection, especially for remote-fs scenarios. (LP: #1769682) * networkd: don't wipe out /run/netplan on generate: we do want to keep any YAML configurations in that directory, we just need to remove generated wpasupplicant configs. (LP: #1764869) -- Mathieu Trudel-Lapierre Tue, 08 May 2018 10:36:24 -0400 ** Changed in: nplan (Ubuntu Xenial) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1756322 Title: 'netplan apply' fails when trying to activate another interface on another QETH device ... Status in netplan: Fix Released Status in Ubuntu on IBM z Systems: Fix Released Status in netplan.io package in Ubuntu: Fix Released Status in nplan package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Invalid Status in netplan.io source package in Xenial: Invalid Status in nplan source package in Xenial: Fix Released Status in systemd source package in Xenial: Invalid Status in netplan.io source package in Artful: Invalid Status in nplan source package in Artful: Won't Fix Status in systemd source package in Artful: Invalid Bug description: [Impact] Server users on s390x configuring qeth devices. [Test case] 1) Reconfigure an interface for a QETH device 2) Verify that 'netplan apply' completes successfully, without error. [Regression potential] This change has minimal potential for regression, and it only skip qeth-based devices from "replugging", which "disconnects" them by unbinding and rebinding the driver. Potential issues would be limited to failure to rename interfaces without a reboot, for configurations that depend on this (but it already would not have worked due to netplan apply failing to rebind the device). --- When trying to add another interface for a QETH device on a s390x system netplan apply fails: sudo netplan apply Cannot replug encc003: [Errno 19] No such device Traceback (most recent call last): File "/usr/sbin/netplan", line 23, in netplan.main() File "/usr/share/netplan/netplan/cli/core.py", line 50, in main self.run_command() File "/usr/share/netplan/netplan/cli/utils.py", line 110, in run_command self.func() File "/usr/share/netplan/netplan/cli/commands/apply.py", line 40, in run self.run_command() File "/usr/share/netplan/netplan/cli/utils.py", line 110, in run_command self.func() File "/usr/share/netplan/netplan/cli/commands/apply.py", line 87, in command_apply stdout=fd, stderr=fd) File "/usr/lib/python3.6/subprocess.py", line 291, in check_call raise CalledProcessError(retcode, cmd) subprocess.CalledProcessError: Command '['udevadm', 'test-builtin', 'net_setup_link', '/sys/class/net/encc003']' returned non-zero exit status 4. It seems like rebinding of qeth devices is not allowed. With qeth devices, I guess one needs to "offline & online" them... Or like unbind a whole group of them, as there are three of them per interface. ubuntu@s1lp14:/sys/class/net/encc006/device$ ls -latr total 0 drwxr-xr-x 5 root root0 Mar 16 02:06 .. -rw-r--r-- 1 root root 4096 Mar 16 13:44 uevent drwxr-xr-x 6 root root0 Mar 16 13:44 . -rw-r--r-- 1 root root 4096 Mar 16 13:44 online lrwxrwxrwx 1 root root0 Mar 16 13:44 subsystem -> ../../../bus/ccwgroup lrwxrwxrwx 1 root root0 Mar 16 13:44 driver -> ../../../bus/ccwgroup/drivers/qeth drwxr-xr-x 2 root root0 Mar 16 13:44 vnicc --w--- 1 root root 4096 Mar 16 13:44 recover -rw-r--r-- 1 root root 4096 Mar 16 13:44 priority_queueing -rw-r--r-- 1 root root 4096 Mar 16 13:44 portno -rw-r--r-- 1 root root 4096 Mar 16 13:44 portname -rw-r--r-- 1 root root 4096 Mar 16 13:44 performance_stats -rw-r--r-- 1 root root 4096 Mar 16 13:44 layer2 -rw-r--r-- 1 root root 4096 Mar 16 13:44 isolation -rw-r--r-- 1 root root 4096 Mar 16 13:44 hw_trap lrwxrwxrwx 1 root root0 Mar 16 13:44 cdev2 -> ../../css0/0.0.0bb4/0.0.c008 lrwxrwxrwx 1 root root0 Mar 16 13:44 cdev1 -> ../../css0/0.0.0bb3/0.0.c007 lrwxrwxrwx 1 root root0 Mar 16 13:44 cdev0 ->
[Group.of.nepali.translators] [Bug 1738998] Re: netplan does not allow dhcp client identifier type to be specified
This bug was fixed in the package nplan - 0.32~17.10.4 --- nplan (0.32~17.10.4) artful; urgency=medium * bond/bridge: Support suffixes for time-based values so things like "mii-monitor-interval" can support milliseconds. (LP: #1745597) * debian/postinst: Write breadcrumbs on disk in /etc/network/interfaces to denote the migration to using netplan. (LP: #1756742) * DHCPv4: add a "dhcp-identifier: mac" field that can be set to fix interop with Windows Server-based DHCP servers which don't support RFC 4361. (LP: #1738998) * IPv6: accept-ra should default to being unset, so that the kernel default can be used. (LP: #1732002) * doc/netplan.md: Clarify the behavior for time-based values for bonds and bridges. (LP: #1756587) * critical: provide a way to set "CriticalConnection=true" on a networkd connection, especially for remote-fs scenarios. (LP: #1769682) * networkd: don't wipe out /run/netplan on generate: we do want to keep any YAML configurations in that directory, we just need to remove generated wpasupplicant configs. (LP: #1764869) -- Mathieu Trudel-Lapierre Tue, 08 May 2018 11:04:30 -0400 ** Changed in: nplan (Ubuntu Artful) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1738998 Title: netplan does not allow dhcp client identifier type to be specified Status in netplan: Fix Released Status in nplan package in Ubuntu: Fix Released Status in nplan source package in Xenial: Fix Released Status in nplan source package in Artful: Fix Released Bug description: [Impact] Users of Ubuntu dealing with a DHCP server based on Windows Server, Solarwinds IPAM, or possibly other DHCP server products that do no support RFC 4361. [Test case] -- requires a Windows Server DHCP setup, or another product without support for client identifier DUIDs. 1) Configure a reservation for the device, using the device's MAC address. 2) Configure the device for DHCP: network: version: 2 renderer: networkd ethernets: eth0: dhcp4: yes dhcp-identifier: mac 3) Run 'netplan apply' 4) Verify that 'netplan apply' completes successfully, and that the expected IP address is received as part of the reservation. It may be required to clear the DHCP server's cache of DHCP requests/responses. [Regression potential] These DHCP behavior changes may lead to systems not receiving the same IP as they previously did on reservations from a DHCP server; the default is not changing from using DUIDs so unchanged configurations should not be affected at all, but changes to add the new feature will likely change the IP address returned to the client from the DHCP server. Additionally, failure to parse netplan configuration or invalid DHCP behavior should be investigated as possible regressions coming from this SRU. To manage notifications about this bug go to: https://bugs.launchpad.net/netplan/+bug/1738998/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1745597] Re: mii-monitor-interval unit is undocumented, and may be wrong
This bug was fixed in the package nplan - 0.32~16.04.5 --- nplan (0.32~16.04.5) xenial; urgency=medium * bond/bridge: Support suffixes for time-based values so things like "mii-monitor-interval" can support milliseconds. (LP: #1745597) * Do not attempt to rebind driver 'qeth'. (LP: #1756322) * Allow setting ClientIdentifier=mac for networkd-renderered devices (LP: #1738998) * IPv6: accept-ra should default to being unset, so that the kernel default can be used. (LP: #1732002) * doc/netplan.md: Clarify the behavior for time-based values for bonds and bridges. (LP: #1756587) * critical: provide a way to set "CriticalConnection=true" on a networkd connection, especially for remote-fs scenarios. (LP: #1769682) * networkd: don't wipe out /run/netplan on generate: we do want to keep any YAML configurations in that directory, we just need to remove generated wpasupplicant configs. (LP: #1764869) -- Mathieu Trudel-Lapierre Tue, 08 May 2018 10:36:24 -0400 ** Changed in: nplan (Ubuntu Xenial) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1745597 Title: mii-monitor-interval unit is undocumented, and may be wrong Status in netplan: Fix Released Status in nplan package in Ubuntu: Fix Released Status in nplan source package in Xenial: Fix Released Status in nplan source package in Artful: Fix Released Bug description: [Impact] Users of bond and bridges devices requiring tuning of the default device parameters. [Test case] == Configure MII monitor interval == 1) Configure a bond device 2) Add parameters: bonds: mybond0: parameters: mii-monitor-interval: 1 3) Verify that the applied MII monitor interval is of 1ms, as opposed to 1 second (1000ms), by verifying the contents of /sys/class/net/mybond0/bonding/miimon == Validate default behavior == 1) Configure a bond device without parameters. 2) Verify that no special MII monitor interval is applied, the default value should be 0: $ cat /sys/class/net/mybond0/bonding/miimon 0 [Regression potential] MII monitor behavior is changing with this SRU. Default behavior for an unqualified value (ie. a number alone), which was also the only way to specify parameters, was to interpret the values as *seconds*. This leads to relatively slow checking of the device link status (for MII monitor), much slower than generally expected. The same applies to other time-based values such as up delay, down delay, arp interval. The interpretation for these values changes to reading them as *milliseconds* when unqualified, and a new way of qualifying the values (adding a modifier) was added. This was, people who do require "slow" checking of the MII link status will be migrated to "fast" checking right now, moving from an interval of 1 second to 1 millisecond (more checking means less false-negatives for packet passing through an interface, should reduce packet loss, at the cost of potentially flapping the interfaces (bringing down a path often if MII status is bad or slow to be returned)). Users who require the old behavior may add "s" at the end of the value to make it read as "1 second" again, or modify the value to be "1000", which will be 1000ms (1 second). We estimate the impact of this change to users to be minimal, actually requiring a 1 second interval for MII monitoring / up/down delay, and ARP interval is very uncommon and counter-intuitive as all other systems work on a millisecond basis. --- The manpage for netplan doesn't indicate what the unit for mii- monitor-interval is on bond devices. It appears to be in whole seconds, but at the kernel level, the unit is milliseconds. From my testing, it appears to be impossible to set a value for mii- monitor-interval with netplan that is <1s (e.g. I got a syntax error with a value of 0.1 for 100ms) To manage notifications about this bug go to: https://bugs.launchpad.net/netplan/+bug/1745597/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1769682] Re: NFS-based remote root hangs when running 'netplan apply'
This bug was fixed in the package nplan - 0.32~16.04.5 --- nplan (0.32~16.04.5) xenial; urgency=medium * bond/bridge: Support suffixes for time-based values so things like "mii-monitor-interval" can support milliseconds. (LP: #1745597) * Do not attempt to rebind driver 'qeth'. (LP: #1756322) * Allow setting ClientIdentifier=mac for networkd-renderered devices (LP: #1738998) * IPv6: accept-ra should default to being unset, so that the kernel default can be used. (LP: #1732002) * doc/netplan.md: Clarify the behavior for time-based values for bonds and bridges. (LP: #1756587) * critical: provide a way to set "CriticalConnection=true" on a networkd connection, especially for remote-fs scenarios. (LP: #1769682) * networkd: don't wipe out /run/netplan on generate: we do want to keep any YAML configurations in that directory, we just need to remove generated wpasupplicant configs. (LP: #1764869) -- Mathieu Trudel-Lapierre Tue, 08 May 2018 10:36:24 -0400 ** Changed in: nplan (Ubuntu Xenial) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1769682 Title: NFS-based remote root hangs when running 'netplan apply' Status in initramfs-tools package in Ubuntu: Fix Released Status in netplan.io package in Ubuntu: Fix Released Status in nplan package in Ubuntu: Invalid Status in initramfs-tools source package in Xenial: Confirmed Status in netplan.io source package in Xenial: Invalid Status in nplan source package in Xenial: Fix Released Status in initramfs-tools source package in Artful: Confirmed Status in netplan.io source package in Artful: Invalid Status in nplan source package in Artful: Fix Released Status in initramfs-tools source package in Bionic: Confirmed Status in netplan.io source package in Bionic: Fix Committed Status in nplan source package in Bionic: Invalid Bug description: [Impact] Netboot users with a remote filesystem over NFS (possibly over other networked filesystems). [Test cases] 1) Boot a system with its root filesystem over NFS. 2) Run 'sudo netplan apply' 3) Validate that the system remains responsive and keeps connectivity over the same IP address as it had. [Regression potential] This SRU changes network properties, and enforces that networkd does not release and re-request an IP address from DHCP when it is restarted. Environments relying on the IP release/renew behavior may find themselves staying on the previous IP address, which might negatively impact connectivity. Changes in connectivity on a system running netplan should be investigated as a potential regression from this SRU. Other regression possibilities would include failure to get a new IP address over time (usually seen as losing connectivity) or possible IP conflicts on a network. --- With a system booted on the network, with its remote root fs on NFS: Running 'netplan apply' restarts systemd-networkd, which releases the IP received from DHCP. With no IP (and and IP potentially changing), the NFS server can't be reached so the system hangs. 'netplan apply' or restarting systemd-networkd should not affect teh system, it should continue working normally despite "changing" network states, as long as the effective IP remains the same. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1769682/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1769682] Re: NFS-based remote root hangs when running 'netplan apply'
This bug was fixed in the package nplan - 0.32~17.10.4 --- nplan (0.32~17.10.4) artful; urgency=medium * bond/bridge: Support suffixes for time-based values so things like "mii-monitor-interval" can support milliseconds. (LP: #1745597) * debian/postinst: Write breadcrumbs on disk in /etc/network/interfaces to denote the migration to using netplan. (LP: #1756742) * DHCPv4: add a "dhcp-identifier: mac" field that can be set to fix interop with Windows Server-based DHCP servers which don't support RFC 4361. (LP: #1738998) * IPv6: accept-ra should default to being unset, so that the kernel default can be used. (LP: #1732002) * doc/netplan.md: Clarify the behavior for time-based values for bonds and bridges. (LP: #1756587) * critical: provide a way to set "CriticalConnection=true" on a networkd connection, especially for remote-fs scenarios. (LP: #1769682) * networkd: don't wipe out /run/netplan on generate: we do want to keep any YAML configurations in that directory, we just need to remove generated wpasupplicant configs. (LP: #1764869) -- Mathieu Trudel-Lapierre Tue, 08 May 2018 11:04:30 -0400 ** Changed in: nplan (Ubuntu Artful) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1769682 Title: NFS-based remote root hangs when running 'netplan apply' Status in initramfs-tools package in Ubuntu: Fix Released Status in netplan.io package in Ubuntu: Fix Released Status in nplan package in Ubuntu: Invalid Status in initramfs-tools source package in Xenial: Confirmed Status in netplan.io source package in Xenial: Invalid Status in nplan source package in Xenial: Fix Released Status in initramfs-tools source package in Artful: Confirmed Status in netplan.io source package in Artful: Invalid Status in nplan source package in Artful: Fix Released Status in initramfs-tools source package in Bionic: Confirmed Status in netplan.io source package in Bionic: Fix Committed Status in nplan source package in Bionic: Invalid Bug description: [Impact] Netboot users with a remote filesystem over NFS (possibly over other networked filesystems). [Test cases] 1) Boot a system with its root filesystem over NFS. 2) Run 'sudo netplan apply' 3) Validate that the system remains responsive and keeps connectivity over the same IP address as it had. [Regression potential] This SRU changes network properties, and enforces that networkd does not release and re-request an IP address from DHCP when it is restarted. Environments relying on the IP release/renew behavior may find themselves staying on the previous IP address, which might negatively impact connectivity. Changes in connectivity on a system running netplan should be investigated as a potential regression from this SRU. Other regression possibilities would include failure to get a new IP address over time (usually seen as losing connectivity) or possible IP conflicts on a network. --- With a system booted on the network, with its remote root fs on NFS: Running 'netplan apply' restarts systemd-networkd, which releases the IP received from DHCP. With no IP (and and IP potentially changing), the NFS server can't be reached so the system hangs. 'netplan apply' or restarting systemd-networkd should not affect teh system, it should continue working normally despite "changing" network states, as long as the effective IP remains the same. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1769682/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1764869] Re: YAML configs wiped out from /run/netplan
This bug was fixed in the package nplan - 0.32~17.10.4 --- nplan (0.32~17.10.4) artful; urgency=medium * bond/bridge: Support suffixes for time-based values so things like "mii-monitor-interval" can support milliseconds. (LP: #1745597) * debian/postinst: Write breadcrumbs on disk in /etc/network/interfaces to denote the migration to using netplan. (LP: #1756742) * DHCPv4: add a "dhcp-identifier: mac" field that can be set to fix interop with Windows Server-based DHCP servers which don't support RFC 4361. (LP: #1738998) * IPv6: accept-ra should default to being unset, so that the kernel default can be used. (LP: #1732002) * doc/netplan.md: Clarify the behavior for time-based values for bonds and bridges. (LP: #1756587) * critical: provide a way to set "CriticalConnection=true" on a networkd connection, especially for remote-fs scenarios. (LP: #1769682) * networkd: don't wipe out /run/netplan on generate: we do want to keep any YAML configurations in that directory, we just need to remove generated wpasupplicant configs. (LP: #1764869) -- Mathieu Trudel-Lapierre Tue, 08 May 2018 11:04:30 -0400 ** Changed in: nplan (Ubuntu Artful) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1764869 Title: YAML configs wiped out from /run/netplan Status in netplan.io package in Ubuntu: Fix Released Status in nplan package in Ubuntu: Fix Released Status in netplan.io source package in Xenial: Invalid Status in nplan source package in Xenial: Fix Released Status in netplan.io source package in Artful: Invalid Status in nplan source package in Artful: Fix Released Bug description: [Impact] Netboot users, and any scenario where YAML configuration is written to /run/netplan. [Test case] 1) Run 'sudo netplan apply' 2) Verify that existing configuration *.yaml files in /run/netplan is not removed. [Regression Potential] /run/netplan is meant as a location for yaml configuration generated by other parts of the system, or by the boot processes, to be used and complement / override local config in /etc/netplan. Additional files are created in /run/netplan (such as wpa configuration when using wifi) which must be removed. Removal of the netplan configuration files may lead to incomplete configuration for network devices. This may cause a system to lose connectivity. Changes in network connectivity following "netplan apply" where configuration didn't otherwise change in /etc/netplan/*.yaml may indicate a regression. --- Any .yaml file in /run/netplan are wiped out when 'netplan generate' is run. This is wrong, we might actually want to have .yaml files there for netplan configuration. What we don't want, however, is for generated wpa-*.conf files to be left around: wpasupplicant configuration really does need to go, as it will be generated again by 'netplan generate'. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/netplan.io/+bug/1764869/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1756587] Re: mii-mon should have a consistent unit schema
This bug was fixed in the package nplan - 0.32~16.04.5 --- nplan (0.32~16.04.5) xenial; urgency=medium * bond/bridge: Support suffixes for time-based values so things like "mii-monitor-interval" can support milliseconds. (LP: #1745597) * Do not attempt to rebind driver 'qeth'. (LP: #1756322) * Allow setting ClientIdentifier=mac for networkd-renderered devices (LP: #1738998) * IPv6: accept-ra should default to being unset, so that the kernel default can be used. (LP: #1732002) * doc/netplan.md: Clarify the behavior for time-based values for bonds and bridges. (LP: #1756587) * critical: provide a way to set "CriticalConnection=true" on a networkd connection, especially for remote-fs scenarios. (LP: #1769682) * networkd: don't wipe out /run/netplan on generate: we do want to keep any YAML configurations in that directory, we just need to remove generated wpasupplicant configs. (LP: #1764869) -- Mathieu Trudel-Lapierre Tue, 08 May 2018 10:36:24 -0400 ** Changed in: nplan (Ubuntu Xenial) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1756587 Title: mii-mon should have a consistent unit schema Status in netplan: Fix Released Status in netplan.io package in Ubuntu: Fix Released Status in nplan package in Ubuntu: Invalid Status in netplan.io source package in Xenial: Invalid Status in nplan source package in Xenial: Fix Released Status in netplan.io source package in Artful: Invalid Status in nplan source package in Artful: Fix Released Status in netplan.io source package in Bionic: Fix Committed Status in nplan source package in Bionic: Invalid Bug description: [Impact] Documentation is confusing to users wishing to tune bond and bridge parameters. This potentially affects all users of netplan. [Test case] 1) Update the netplan.io package. 2) Run 'man netplan' 3) Verify that the documentation under "parameters" for bridges and bonds is clear that time-based parameters are in milliseconds unless otherwise specified by the individual parameter: For example, in the bonds section: - learn-packet-interval is in seconds - mii-monitor-interval, up-delay, down-delay, arp-interval are in milliseconds [Regression potential] Change is limited to the manpage; there is no risk of regression there, except for a garbled manpage or missing file. Any new bugs in netplan behavior found after this SRU that can't be reproduced with the immediately previous version should be investigated as potential toolchain / build issues introduced by the new build required for the SRU. --- The docs say "Using the NetworkManager renderer, parameter values for intervals should be expressed in milliseconds; for the systemd renderer, they should be in seconds unless otherwise specified." This however fails to encapsulate the description of the network in a form abstracted from the renderer. We should have a scheme which is clear, has one and only one explicit form, and works with all renderers. To manage notifications about this bug go to: https://bugs.launchpad.net/netplan/+bug/1756587/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1764869] Re: YAML configs wiped out from /run/netplan
This bug was fixed in the package nplan - 0.32~16.04.5 --- nplan (0.32~16.04.5) xenial; urgency=medium * bond/bridge: Support suffixes for time-based values so things like "mii-monitor-interval" can support milliseconds. (LP: #1745597) * Do not attempt to rebind driver 'qeth'. (LP: #1756322) * Allow setting ClientIdentifier=mac for networkd-renderered devices (LP: #1738998) * IPv6: accept-ra should default to being unset, so that the kernel default can be used. (LP: #1732002) * doc/netplan.md: Clarify the behavior for time-based values for bonds and bridges. (LP: #1756587) * critical: provide a way to set "CriticalConnection=true" on a networkd connection, especially for remote-fs scenarios. (LP: #1769682) * networkd: don't wipe out /run/netplan on generate: we do want to keep any YAML configurations in that directory, we just need to remove generated wpasupplicant configs. (LP: #1764869) -- Mathieu Trudel-Lapierre Tue, 08 May 2018 10:36:24 -0400 ** Changed in: nplan (Ubuntu Xenial) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1764869 Title: YAML configs wiped out from /run/netplan Status in netplan.io package in Ubuntu: Fix Released Status in nplan package in Ubuntu: Fix Released Status in netplan.io source package in Xenial: Invalid Status in nplan source package in Xenial: Fix Released Status in netplan.io source package in Artful: Invalid Status in nplan source package in Artful: Fix Released Bug description: [Impact] Netboot users, and any scenario where YAML configuration is written to /run/netplan. [Test case] 1) Run 'sudo netplan apply' 2) Verify that existing configuration *.yaml files in /run/netplan is not removed. [Regression Potential] /run/netplan is meant as a location for yaml configuration generated by other parts of the system, or by the boot processes, to be used and complement / override local config in /etc/netplan. Additional files are created in /run/netplan (such as wpa configuration when using wifi) which must be removed. Removal of the netplan configuration files may lead to incomplete configuration for network devices. This may cause a system to lose connectivity. Changes in network connectivity following "netplan apply" where configuration didn't otherwise change in /etc/netplan/*.yaml may indicate a regression. --- Any .yaml file in /run/netplan are wiped out when 'netplan generate' is run. This is wrong, we might actually want to have .yaml files there for netplan configuration. What we don't want, however, is for generated wpa-*.conf files to be left around: wpasupplicant configuration really does need to go, as it will be generated again by 'netplan generate'. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/netplan.io/+bug/1764869/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1756587] Re: mii-mon should have a consistent unit schema
This bug was fixed in the package nplan - 0.32~17.10.4 --- nplan (0.32~17.10.4) artful; urgency=medium * bond/bridge: Support suffixes for time-based values so things like "mii-monitor-interval" can support milliseconds. (LP: #1745597) * debian/postinst: Write breadcrumbs on disk in /etc/network/interfaces to denote the migration to using netplan. (LP: #1756742) * DHCPv4: add a "dhcp-identifier: mac" field that can be set to fix interop with Windows Server-based DHCP servers which don't support RFC 4361. (LP: #1738998) * IPv6: accept-ra should default to being unset, so that the kernel default can be used. (LP: #1732002) * doc/netplan.md: Clarify the behavior for time-based values for bonds and bridges. (LP: #1756587) * critical: provide a way to set "CriticalConnection=true" on a networkd connection, especially for remote-fs scenarios. (LP: #1769682) * networkd: don't wipe out /run/netplan on generate: we do want to keep any YAML configurations in that directory, we just need to remove generated wpasupplicant configs. (LP: #1764869) -- Mathieu Trudel-Lapierre Tue, 08 May 2018 11:04:30 -0400 ** Changed in: nplan (Ubuntu Artful) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1756587 Title: mii-mon should have a consistent unit schema Status in netplan: Fix Released Status in netplan.io package in Ubuntu: Fix Released Status in nplan package in Ubuntu: Invalid Status in netplan.io source package in Xenial: Invalid Status in nplan source package in Xenial: Fix Released Status in netplan.io source package in Artful: Invalid Status in nplan source package in Artful: Fix Released Status in netplan.io source package in Bionic: Fix Committed Status in nplan source package in Bionic: Invalid Bug description: [Impact] Documentation is confusing to users wishing to tune bond and bridge parameters. This potentially affects all users of netplan. [Test case] 1) Update the netplan.io package. 2) Run 'man netplan' 3) Verify that the documentation under "parameters" for bridges and bonds is clear that time-based parameters are in milliseconds unless otherwise specified by the individual parameter: For example, in the bonds section: - learn-packet-interval is in seconds - mii-monitor-interval, up-delay, down-delay, arp-interval are in milliseconds [Regression potential] Change is limited to the manpage; there is no risk of regression there, except for a garbled manpage or missing file. Any new bugs in netplan behavior found after this SRU that can't be reproduced with the immediately previous version should be investigated as potential toolchain / build issues introduced by the new build required for the SRU. --- The docs say "Using the NetworkManager renderer, parameter values for intervals should be expressed in milliseconds; for the systemd renderer, they should be in seconds unless otherwise specified." This however fails to encapsulate the description of the network in a form abstracted from the renderer. We should have a scheme which is clear, has one and only one explicit form, and works with all renderers. To manage notifications about this bug go to: https://bugs.launchpad.net/netplan/+bug/1756587/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1772940] Re: linux-azure: 4.15.0-1013.13~16.04.2 -proposed tracker
** Changed in: kernel-sru-workflow/automated-testing Status: Incomplete => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1772940 Title: linux-azure: 4.15.0-1013.13~16.04.2 -proposed tracker Status in Kernel SRU Workflow: In Progress Status in Kernel SRU Workflow automated-testing series: Fix Released Status in Kernel SRU Workflow certification-testing series: Invalid Status in Kernel SRU Workflow prepare-package series: Fix Released Status in Kernel SRU Workflow prepare-package-meta series: Fix Released Status in Kernel SRU Workflow prepare-package-signed series: Fix Released Status in Kernel SRU Workflow promote-to-proposed series: Fix Released Status in Kernel SRU Workflow promote-to-security series: New Status in Kernel SRU Workflow promote-to-updates series: New Status in Kernel SRU Workflow regression-testing series: Confirmed Status in Kernel SRU Workflow security-signoff series: In Progress Status in Kernel SRU Workflow snap-release-to-beta series: Fix Released Status in Kernel SRU Workflow snap-release-to-candidate series: Confirmed Status in Kernel SRU Workflow snap-release-to-edge series: Fix Released Status in Kernel SRU Workflow snap-release-to-stable series: Invalid Status in Kernel SRU Workflow stakeholder-signoff series: In Progress Status in Kernel SRU Workflow upload-to-ppa series: New Status in Kernel SRU Workflow verification-testing series: Confirmed Status in linux-azure package in Ubuntu: Invalid Status in linux-azure source package in Xenial: Confirmed Bug description: This bug is for tracking the upload package. This bug will contain status and testing results related to that upload. For an explanation of the tasks and the associated workflow see: https://wiki.ubuntu.com/Kernel/kernel-sru-workflow -- swm properties -- boot-testing-requested: true kernel-stable-master-bug: 1772927 phase: Promoted to proposed proposed-announcement-sent: true proposed-testing-requested: true To manage notifications about this bug go to: https://bugs.launchpad.net/kernel-sru-workflow/+bug/1772940/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1775290] [NEW] SRU of LXD 3.0.1 (upstream bugfix release)
Public bug reported: LXD upstream released LXD 3.0.1 as a bugfix release with following changelog: - lxc: Fix mistakenly hidden commands - i18n: Update translation templates - lxd/migration: Pre-validate profiles - client: Improve remote operation errors - Fix some typos and wording. - Wording fix. - lxc/image: Fix crash due to bad arg parsing - lxd: add missing limits.h include - lxd/init: Fix --auto with network config - lxc: Consistent naming of clustering terms - i18n: Update translation templates - lxc/file: Fix pushing files to remote - lxd/init: Don’t setup a remote storage pool by default - Fix lxd init failing to join cluster interactively with existing zfs pool - lxc/query: Fix -d and -X - lxc/help: Make help respect --all too - Fix typo in help of “lxc network” - Properly filter node-level storage configs by pool ID - i18n: Update translation templates - lxd/init: Consistency - Make new gofmt happy - lxc/file: Allow using -r to follow symlinks - Replace juju/idmclient with CanonicalLtd/candidclient - lxc/config: Fix adding trust cert on snap - lxc/alias: Fix example in help message - i18n: Update translation templates - client: Introduce LXD_SOCKET - Makefile: Add a manifest - containers: fix snapshot deletion - lxc/init: Add missing --no-profiles - i18n: Update translations - lxc/file: Fix pull target logic - doc: Fix example in userns-idmap - devices: fail if Nvidia device minor is missing - Add db.ContainersNodeList - storage: createContainerMountpoint() fix perms - ceph: s/0755/0711/g - lvm: s/0755/0711/g - storage utils: s/0755/0711/g - zfs: s/0755/0711/g - patches: add “storage_api_path_permissions” - sys/fs: s/MkdirAll/Mkdir/g - btrfs: fix permissions - Pass a logger to raft-http - Add new cluster.Promote function - Add new cluster.Rebalance function - Notify the cluster leader after a node removal, so it can rebalance - Add integration test - doc: Tweak backup.md - lxd/init: Require root for interactive cluster join - Disable flaky unit tests for now - Log the error that made Daemon.Init() fail - client: Expose http URL in ConnectionInfo - lxc/query: Add support for non-JSON endpoints - Handle empty query strings - Support reading queries from standard in - Support passing multiple queries - Rename database files - Support querying both local and global database - Update integration tests - Normalize name of images_aliases table - Add query.Dump helper to dump schema and data - Add support for dump command in lxd sql - lxd/containers: Fix lxc.net 1 check - doc/backup.md: update snap path - Add lxc cluster enable command - Fix command description formatting - Update .pot files - Use an isolated LXD instance in integration tests - Start a container in the integration test - Address style comments - add LXD_UNPRIVILEGED_ONLY to disallow privileged containers. - lxd: tweak LXD_UNPRIVILEGED_ONLY - doc: add LXD_UNPRIVILEGED_ONLY - tests: add tests for LXD_UNPRIVILEGED_ONLY - Reword errors when LXD_UNPRIVILEGED_ONLY is set - lxd/containers: Allow sending progress - lxc/rename: Deal with remote renames - lxd/db: Don’t crash on empty queries - lxd/sql: Drop custom table renderer - lxd/network: Fix fan subnet calculation logic - Update translations from weblate - lxc/main: Fix remote caching - lxc/storage_volumes: Various fixes - tests: Add extra cleanup code - lxd/storage: Also set zfs.pool_name on upgrade - migration: fix btrfs live migration - lxd/containers: Fix broken unix hotplug logic - lxc/list: Reduce number of API calls - Make the interaction betwean lxd daemon and waitready non-blocking - Increase logging during startup - Remove log alias for waitready - Remove log alias for db.OpenCluster - Make Unavailable accept an error parameter - Add a new Schema.File() method to load extra queries from a file - Add support for patch.local.sql and patch.global.sql - Add integration tests - Add shared.DirCopy to recursively copy a directory. - Update database.md - Backup global database if non-clustered - lxd/init: Offer to setup a Fan bridge when clustered - lxd init: fix maas.api.url check when setting up existing bridge - Take raft snapshots more frequently and at shutdown - Add --schema flag to lxd sql to dump only the schema. - Update database.md with information about lxd sql and patch.*.sql - Document how to dump the content or schema of databases - Fix shell lints - Disable snapshot logging, as it’s too verbose now - Make .dump and .schema special queries, for consistency with sqlite3 - Run make i18n - xattr: Support empty values - doc: s/status
[Group.of.nepali.translators] [Bug 1769954] Re: package desktop-file-utils 0.23-1ubuntu3 failed to install/upgrade: dependency problems - leaving triggers unprocessed
This bug was fixed in the package desktop-file-utils - 0.23-1ubuntu4 --- desktop-file-utils (0.23-1ubuntu4) cosmic; urgency=medium * Use noawait trigger (LP: #1769954) -- Julian Andres Klode Tue, 05 Jun 2018 10:30:25 -0700 ** Changed in: desktop-file-utils (Ubuntu) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1769954 Title: package desktop-file-utils 0.23-1ubuntu3 failed to install/upgrade: dependency problems - leaving triggers unprocessed Status in desktop-file-utils package in Ubuntu: Fix Released Status in desktop-file-utils source package in Xenial: In Progress Status in desktop-file-utils source package in Artful: In Progress Status in desktop-file-utils source package in Bionic: In Progress Bug description: [Impact] dist-upgrade from artful to bionic fails with attached tarball [Test case] artful: 1. Install new desktop-file-utils 2. check that dist-upgrade works bionic: 1. Download new deb 2. Run apt-get dist-upgrade path/to/deb in xenial to trigger upgrade with that deb being upgraded too. [Regression potential] Packages installing desktop files to /usr/share/applications won't get put in triggers-awaited state due to d-f-u. [Other info] Just fixing bionic makes an apt dist-upgrade work (not sure about do-release-upgrade); but it might not work in other circumstances I guess, so it might make sense to upload the fix to older releases. We can only verify artful and bionic, though, so xenial would have to go in unchecked. The trigger causes the desktop database to be updated, as such it is possible to use noawait here, as there's no reason for packages shipping .desktop files to be not configured just because the database has not been updated yet. The same change has been made in Debian in 0.23-2. [Original bug report] run `sudo do-release-upgrade` on a relativity new 16.04 EC2 instance. ProblemType: Package DistroRelease: Ubuntu 18.04 Package: desktop-file-utils 0.23-1ubuntu3 ProcVersionSignature: Ubuntu 4.13.0-36.40-generic 4.13.13 Uname: Linux 4.13.0-36-generic x86_64 NonfreeKernelModules: zfs zunicode zavl zcommon znvpair ApportVersion: 2.20.7-0ubuntu3.8 Architecture: amd64 Date: Tue May 8 16:59:12 2018 Ec2AMI: ami-70873908 Ec2AMIManifest: (unknown) Ec2AvailabilityZone: us-west-2a Ec2InstanceType: t2.large Ec2Kernel: unavailable Ec2Ramdisk: unavailable ErrorMessage: dependency problems - leaving triggers unprocessed Python3Details: /usr/bin/python3.6, Python 3.6.5, python3-minimal, 3.6.5-3 PythonDetails: /usr/bin/python2.7, Python 2.7.15rc1, python-minimal, 2.7.15~rc1-1 RelatedPackageVersions: dpkg 1.19.0.5ubuntu2 apt 1.6.1 SourcePackage: desktop-file-utils Title: package desktop-file-utils 0.23-1ubuntu3 failed to install/upgrade: dependency problems - leaving triggers unprocessed UpgradeStatus: Upgraded to bionic on 2018-05-08 (0 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/desktop-file-utils/+bug/1769954/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1775283] [NEW] SRU of LXC 3.0.1
Public bug reported: LXC upstream released LXC 3.0.1 as a bugfix release with following changelog: - tools: fix unitialized variable - storage: fix lvm fs uuid generation - lxc-oci: fix Cmd/Entrypoint parsing - lxc-oci: make umoci less verbose - lxclock: use thread-safe OFD fcntl() locks - locktests: fix test suite - conf: ensure umounts don’t propagate to host - doc: Tweak Japanese translation in lxc.container.conf(5) - fix signal sending in lxc.init - rootfs pinning: On NFS, make file hidden but don’t delete it - conf: fix temporary file creation - ringbuf: fix temporary file creation - Fix compilation with static libcap and shared gnutls - attach: always drop supplementary groups - lxc init: remove dead code - storage/rsync: free memory on error - tools/utils: free memory on error - lxc init: coding style - utils: define __NR_setns if missing on old glibcs - attach: try to always drop supplementary groups - conf: ret-try devpts mount without gid=5 on error - execute: fix app containers without root mapping - conf: fix net type checks in run_script_argv() - seccomp: handle arch inversion - seccomp: handle all errors - seccomp: cleanup compat architecture handling - seccomp: improve logging - tools: document -d/–daemonize for lxc-execute - seccomp: non-functional changes - seccomp: handle arch inversion II - lxc-oci: mkdir the download directory - do_lxcapi_create: set umask - lxc/tools/lxc_monitor: include missing - pam-cgfs: ignore the system umask when creating the cgroup hierarchy - Also pass action scripts to CRIU on checkpointing - Fix the memory leak in cgfsng_attach - Fix memory leak in list_active_containers - Fix tool_utils.c build when HAVE_SETNS is unset - coverity: #1435210 - coverity: #1435208 - coverity: #1435207 - coverity: #1435206 - coverity: #1435205 - coverity: #1435203 - coverity: #1435200 - coverity: #1435198 - coverity: #1426734 - lxccontainer: non-functional changes - lxccontainer: use thread-safe OFD locks - lxccontainer: non-functional changes - lxccontainer: do_lxcapi_is_running() - lxccontainer: do_lxcapi_freeze() - lxccontainer: do_lxcapi_unfreeze() - lxccontainer: non-functional changes - lxccontainer: use thread-safe open() + write() - lxccontainer: non-functional changes - lxccontainer: non-functional changes - lxccontainer: non-functional changes - coverity: #1435263 - fix logic for execute log file - utils: add LXC_PROC_PID_FD_LEN - execute: use static buffer - execute: do not check inherited fds again - add some TRACE/ERROR reporting - execute: account for -o path option count - execute: set init_path when existing init is found - genl: remove - coverity: #1248104 - coverity: #1248105 - coverity: #1425744 - utils: account for terminating \0 byte - confile: satisfy gcc-8 - network: silence gcc-8 - network: adhere to IFNAMSIZ limit - support case ignored suffix for sizes - utils: fix parse_byte_size_string() coding style - strlcpy: add strlcpy() implementation - tree-wide: s/strncpy()/strlcpy()/g - CODING_STYLE: add section about using strlcpy() - tools: s/strncpy()/strlcpy()/g - Revert “tools: s/strncpy()/strlcpy()/g” - tools: s/strncpy()/memcpy()/ - doc: Add “-d/–daemon” option to Japanese lxc-execute(1) - doc: Fix size unit style in Japanese lxc.container.conf(5) - coverity: #1435604 - coverity: #1435603 - coverity: #1435602 - coverity: #1425844 - config: allow read-write /sys in user namespace - coverity: #1425836 - coverity: #1248106 - capabilities: raise ambient capabilities - coverity: #1425802 - cgroups: refactor cgroup handling - cgroups: remove freezer_state() - seccomp: #ifdef SCMP_ARCH_AARCH64 - conf: simplify write_id_mapping() - log: enable per-thread container name prefix - lxc-init: skip signals that can’t be caught - execute: use execveat() syscall if supported - tools: only create log file when requested - seccomp: fix off-by-one error in array allocation for sscanf - seccomp: remove confusing comment line - seccomp: remove unnecessary memset - seccomp: fix type mismatch when parsing syscall arguments filters - lxcseccomp: cleanup header - seccomp: parse_config_v1() - utils: add remove_trailing_newlines() - seccomp: get_v2_default_action() - seccomp: get_action_name() - seccomp: get_v2_action() - seccomp: fix get_seccomp_arg_value() - seccomp: parse_v2_rules() - seccomp: move #ifdefines - seccomp: get_hostarch() - seccomp: scmp_filter_ctx get_new_ctx() - seccomp: do_resolve_add_rule() - seccomp: parse_config_v2() - seccomp: parse_config() - seccomp: lxc_read_seccomp_config() -
[Group.of.nepali.translators] [Bug 1775271] [NEW] SRU of LXCFS 3.0.1 (upstream bugfix release)
Public bug reported: LXCFS upstream released LXCFS 3.0.1 as a bugfix release with following changelog: - Add support for the nonempty FUSE mount option Just like Ubuntu itself, upstream releases long term support releases, as is 3.0 and then periodic point releases including all the accumulated bugfixes. Only the latest upstream release gets full support from the upstream developers, everyone else is expected to first update to it before receiving any kind of support. This should qualify under the minor upstream bugfix release allowance of the SRU policy, letting us SRU this without paperwork for every single change included in this upstream release. Once the SRU hits -updates, we will be backporting this to xenial- backports as well, making sure we have the same version everywhere. ** Affects: lxcfs (Ubuntu) Importance: Medium Assignee: Stéphane Graber (stgraber) Status: Fix Released ** Affects: lxcfs (Ubuntu Xenial) Importance: Medium Assignee: Stéphane Graber (stgraber) Status: Triaged ** Affects: lxcfs (Ubuntu Bionic) Importance: Medium Assignee: Stéphane Graber (stgraber) Status: In Progress ** Affects: lxcfs (Ubuntu Cosmic) Importance: Medium Assignee: Stéphane Graber (stgraber) Status: Fix Released ** Also affects: lxcfs (Ubuntu Cosmic) Importance: Undecided Status: New ** Also affects: lxcfs (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: lxcfs (Ubuntu Xenial) Importance: Undecided Status: New ** Changed in: lxcfs (Ubuntu Cosmic) Status: New => Fix Released ** Changed in: lxcfs (Ubuntu Xenial) Status: New => Triaged ** Changed in: lxcfs (Ubuntu Bionic) Status: New => In Progress ** Changed in: lxcfs (Ubuntu Xenial) Importance: Undecided => Medium ** Changed in: lxcfs (Ubuntu Bionic) Importance: Undecided => Medium ** Changed in: lxcfs (Ubuntu Cosmic) Importance: Undecided => Medium ** Changed in: lxcfs (Ubuntu Xenial) Assignee: (unassigned) => Stéphane Graber (stgraber) ** Changed in: lxcfs (Ubuntu Bionic) Assignee: (unassigned) => Stéphane Graber (stgraber) ** Changed in: lxcfs (Ubuntu Cosmic) Assignee: (unassigned) => Stéphane Graber (stgraber) -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1775271 Title: SRU of LXCFS 3.0.1 (upstream bugfix release) Status in lxcfs package in Ubuntu: Fix Released Status in lxcfs source package in Xenial: Triaged Status in lxcfs source package in Bionic: In Progress Status in lxcfs source package in Cosmic: Fix Released Bug description: LXCFS upstream released LXCFS 3.0.1 as a bugfix release with following changelog: - Add support for the nonempty FUSE mount option Just like Ubuntu itself, upstream releases long term support releases, as is 3.0 and then periodic point releases including all the accumulated bugfixes. Only the latest upstream release gets full support from the upstream developers, everyone else is expected to first update to it before receiving any kind of support. This should qualify under the minor upstream bugfix release allowance of the SRU policy, letting us SRU this without paperwork for every single change included in this upstream release. Once the SRU hits -updates, we will be backporting this to xenial- backports as well, making sure we have the same version everywhere. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxcfs/+bug/1775271/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1768905] Re: package menu 2.1.47ubuntu2 failed to install/upgrade: dependency problems - leaving triggers unprocessed
This bug was fixed in the package menu - 2.1.47ubuntu3 --- menu (2.1.47ubuntu3) cosmic; urgency=medium * Switch triggers to use noawait (LP: #1768905) -- Julian Andres Klode Tue, 05 Jun 2018 10:48:23 -0700 ** Changed in: menu (Ubuntu) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1768905 Title: package menu 2.1.47ubuntu2 failed to install/upgrade: dependency problems - leaving triggers unprocessed Status in apt package in Ubuntu: Incomplete Status in menu package in Ubuntu: Fix Released Status in apt source package in Xenial: New Status in menu source package in Xenial: In Progress Status in apt source package in Artful: New Status in menu source package in Artful: New Status in apt source package in Bionic: New Status in menu source package in Bionic: New Status in menu package in Debian: Unknown Bug description: [Impact] Breaks some upgrades, depending on install order. [Test case] N/A. After consultation with the dpkg maintainer and investigating the situation, it's reasonably safe to assume that noawait is the right thing to do: * the intended use for the trigger is to run _after_ packages with .menu files are configured, not before; therefore * the file trigger is triggered manually from the postinst again, discussion has been that the file trigger is not actually needed. [Regression potential] Menu might not be updated correctly [Original bug report] I get this error when I update to 18.04 ProblemType: Package DistroRelease: Ubuntu 18.04 Package: menu 2.1.47ubuntu2 ProcVersionSignature: Ubuntu 4.15.0-20.21-generic 4.15.17 Uname: Linux 4.15.0-20-generic x86_64 ApportVersion: 2.20.9-0ubuntu7 Architecture: amd64 Date: Thu May 3 16:51:28 2018 Dependencies: gcc-8-base 8-20180414-1ubuntu2 libc6 2.27-3ubuntu1 libgcc1 1:8-20180414-1ubuntu2 libstdc++6 8-20180414-1ubuntu2 ErrorMessage: dependency problems - leaving triggers unprocessed InstallationDate: Installed on 2018-04-11 (22 days ago) InstallationMedia: Ubuntu-MATE 17.10 "Artful Aardvark" - Release amd64 (20180106) Python3Details: /usr/bin/python3.6, Python 3.6.5, python3-minimal, 3.6.5-3 PythonDetails: /usr/bin/python2.7, Python 2.7.15rc1, python-minimal, 2.7.15~rc1-1 RelatedPackageVersions: dpkg 1.19.0.5ubuntu2 apt 1.6.1 SourcePackage: menu Title: package menu 2.1.47ubuntu2 failed to install/upgrade: dependency problems - leaving triggers unprocessed UpgradeStatus: Upgraded to bionic on 2018-05-03 (0 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1768905/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1768905] Re: package menu 2.1.47ubuntu2 failed to install/upgrade: dependency problems - leaving triggers unprocessed
** Bug watch added: Debian Bug tracker #900838 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900838 ** Also affects: menu (Debian) via https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900838 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1768905 Title: package menu 2.1.47ubuntu2 failed to install/upgrade: dependency problems - leaving triggers unprocessed Status in apt package in Ubuntu: Incomplete Status in menu package in Ubuntu: Fix Committed Status in apt source package in Xenial: New Status in menu source package in Xenial: New Status in apt source package in Artful: New Status in menu source package in Artful: New Status in apt source package in Bionic: New Status in menu source package in Bionic: New Status in menu package in Debian: Unknown Bug description: [Impact] Breaks some upgrades, depending on install order. [Test case] N/A. After consultation with the dpkg maintainer and investigating the situation, it's reasonably safe to assume that noawait is the right thing to do: * the intended use for the trigger is to run _after_ packages with .menu files are configured, not before; therefore * the file trigger is triggered manually from the postinst again, discussion has been that the file trigger is not actually needed. [Regression potential] Menu might not be updated correctly [Original bug report] I get this error when I update to 18.04 ProblemType: Package DistroRelease: Ubuntu 18.04 Package: menu 2.1.47ubuntu2 ProcVersionSignature: Ubuntu 4.15.0-20.21-generic 4.15.17 Uname: Linux 4.15.0-20-generic x86_64 ApportVersion: 2.20.9-0ubuntu7 Architecture: amd64 Date: Thu May 3 16:51:28 2018 Dependencies: gcc-8-base 8-20180414-1ubuntu2 libc6 2.27-3ubuntu1 libgcc1 1:8-20180414-1ubuntu2 libstdc++6 8-20180414-1ubuntu2 ErrorMessage: dependency problems - leaving triggers unprocessed InstallationDate: Installed on 2018-04-11 (22 days ago) InstallationMedia: Ubuntu-MATE 17.10 "Artful Aardvark" - Release amd64 (20180106) Python3Details: /usr/bin/python3.6, Python 3.6.5, python3-minimal, 3.6.5-3 PythonDetails: /usr/bin/python2.7, Python 2.7.15rc1, python-minimal, 2.7.15~rc1-1 RelatedPackageVersions: dpkg 1.19.0.5ubuntu2 apt 1.6.1 SourcePackage: menu Title: package menu 2.1.47ubuntu2 failed to install/upgrade: dependency problems - leaving triggers unprocessed UpgradeStatus: Upgraded to bionic on 2018-05-03 (0 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1768905/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1768905] Re: package menu 2.1.47ubuntu2 failed to install/upgrade: dependency problems - leaving triggers unprocessed
Adding tasks for down to xenial, but not sure what we want to do. I don't foresee any trouble with that change, but we can't test it, and even if we get a failing upgrade, we can only test for that release. ** Changed in: menu (Ubuntu) Status: In Progress => Fix Committed ** Also affects: apt (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: menu (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: apt (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: menu (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: apt (Ubuntu Artful) Importance: Undecided Status: New ** Also affects: menu (Ubuntu Artful) Importance: Undecided Status: New -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1768905 Title: package menu 2.1.47ubuntu2 failed to install/upgrade: dependency problems - leaving triggers unprocessed Status in apt package in Ubuntu: Incomplete Status in menu package in Ubuntu: Fix Committed Status in apt source package in Xenial: New Status in menu source package in Xenial: New Status in apt source package in Artful: New Status in menu source package in Artful: New Status in apt source package in Bionic: New Status in menu source package in Bionic: New Bug description: I get this error when I update to 18.04 ProblemType: Package DistroRelease: Ubuntu 18.04 Package: menu 2.1.47ubuntu2 ProcVersionSignature: Ubuntu 4.15.0-20.21-generic 4.15.17 Uname: Linux 4.15.0-20-generic x86_64 ApportVersion: 2.20.9-0ubuntu7 Architecture: amd64 Date: Thu May 3 16:51:28 2018 Dependencies: gcc-8-base 8-20180414-1ubuntu2 libc6 2.27-3ubuntu1 libgcc1 1:8-20180414-1ubuntu2 libstdc++6 8-20180414-1ubuntu2 ErrorMessage: dependency problems - leaving triggers unprocessed InstallationDate: Installed on 2018-04-11 (22 days ago) InstallationMedia: Ubuntu-MATE 17.10 "Artful Aardvark" - Release amd64 (20180106) Python3Details: /usr/bin/python3.6, Python 3.6.5, python3-minimal, 3.6.5-3 PythonDetails: /usr/bin/python2.7, Python 2.7.15rc1, python-minimal, 2.7.15~rc1-1 RelatedPackageVersions: dpkg 1.19.0.5ubuntu2 apt 1.6.1 SourcePackage: menu Title: package menu 2.1.47ubuntu2 failed to install/upgrade: dependency problems - leaving triggers unprocessed UpgradeStatus: Upgraded to bionic on 2018-05-03 (0 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1768905/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1761442] Re: sosreport: AttributeError: 'str' object has no attribute 'decode'
This bug was fixed in the package sosreport - 3.5-1ubuntu4
---
sosreport (3.5-1ubuntu4) cosmic; urgency=medium
* d/p/Fix-string-decoding-for-debug-log-output.patch:
Fix bug in _collect_strings that causes error trying to str.decode()
(LP: #1761442)
-- Dan Streetman Tue, 05 Jun 2018 10:52:56
-0400
** Changed in: sosreport (Ubuntu Cosmic)
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1761442
Title:
sosreport: AttributeError: 'str' object has no attribute 'decode'
Status in sosreport:
New
Status in The Ubuntu-power-systems project:
In Progress
Status in sosreport package in Ubuntu:
Fix Released
Status in sosreport source package in Trusty:
In Progress
Status in sosreport source package in Xenial:
In Progress
Status in sosreport source package in Artful:
In Progress
Status in sosreport source package in Bionic:
In Progress
Status in sosreport source package in Cosmic:
Fix Released
Bug description:
---Problem Description---
sosreport: ubuntu 16.04.04: AttributeError: 'str' object has no attribute
'decode'
---uname output---
Linux guest 4.15.0-13-generic #14~16.04.1-Ubuntu SMP Sat Mar 17 03:03:53 UTC
2018 ppc64le ppc64le ppc64le GNU/Linux
Machine Type = boston-LC
---Debugger---
A debugger is not configured
---Steps to Reproduce---
running sosreport throws below error. report collection succeeds. this bug
is to fix below:
root@guest:~/sosreport-guest-20180405020015/sos_logs# cat
logs-plugin-errors.txt
Traceback (most recent call last):
File "/usr/share/sosreport/sos/sosreport.py", line 1300, in collect
plug.collect()
File "/usr/share/sosreport/sos/plugins/__init__.py", line 877, in collect
self._collect_strings()
File "/usr/share/sosreport/sos/plugins/__init__.py", line 860, in
_collect_strings
(content.splitlines()[0]).decode('utf8', 'ignore'))
AttributeError: 'str' object has no attribute 'decode'
root@guest:~/sosreport-guest-20180405020015/sos_logs# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.04.4 LTS
Release: 16.04
Codename: xenial
root@guest:~/sosreport-guest-20180405020015/sos_logs# dpkg -l | grep -i sos
ii sosreport3.5-1~ubuntu16.04.2
ppc64el Set of tools to gather troubleshooting data from a system
== Comment: #5 - SEETEENA THOUFEEK - 2018-04-05
04:53:10 ==
identified this commit will fix the issue.
https://github.com/sosreport/sos/commit/1fd12690870e85e8ac83b0e99bb272ce4489dc60
To manage notifications about this bug go to:
https://bugs.launchpad.net/sosreport/+bug/1761442/+subscriptions
___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1771283] Re: iperf2 long time run on 40Gb/s NIC crashes
** Bug watch added: Debian Bug tracker #900793 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900793 ** Also affects: iperf (Debian) via https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900793 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1771283 Title: iperf2 long time run on 40Gb/s NIC crashes Status in iperf package in Ubuntu: New Status in iperf source package in Xenial: New Status in iperf source package in Artful: New Status in iperf source package in Bionic: New Status in iperf source package in Cosmic: New Status in iperf package in Debian: Unknown Bug description: ubuntu@recht:~$ iperf -c 192.168.121.2 -P10 -w 130k -t 3600 Client connecting to 192.168.121.2, TCP port 5001 TCP window size: 254 KByte (WARNING: requested 127 KByte) [ 10] local 192.168.121.3 port 40756 connected with 192.168.121.2 port 5001 [ 12] local 192.168.121.3 port 40760 connected with 192.168.121.2 port 5001 [ 11] local 192.168.121.3 port 40758 connected with 192.168.121.2 port 5001 [ 8] local 192.168.121.3 port 40754 connected with 192.168.121.2 port 5001 [ 9] local 192.168.121.3 port 40752 connected with 192.168.121.2 port 5001 [ 7] local 192.168.121.3 port 40750 connected with 192.168.121.2 port 5001 [ 6] local 192.168.121.3 port 40746 connected with 192.168.121.2 port 5001 [ 5] local 192.168.121.3 port 40748 connected with 192.168.121.2 port 5001 [ 3] local 192.168.121.3 port 40744 connected with 192.168.121.2 port 5001 [ 4] local 192.168.121.3 port 40742 connected with 192.168.121.2 port 5001 Segmentation fault (core dumped) Will report more information with gdb attached. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iperf/+bug/1771283/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1775195] Re: sosreport v3.6
Here's the release note for the interim version 3.5.1 to give an idea of what 3.6 will look like: https://github.com/sosreport/sos/releases v3.6 will pretty much look like 3.5.1 with extra enhancements. ** Also affects: sosreport (Ubuntu Trusty) Importance: Undecided Status: New ** Also affects: sosreport (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: sosreport (Ubuntu Cosmic) Importance: Wishlist Status: New ** Also affects: sosreport (Ubuntu Bionic) Importance: Undecided Status: New ** Changed in: sosreport (Ubuntu Bionic) Importance: Undecided => Wishlist ** Changed in: sosreport (Ubuntu Xenial) Importance: Undecided => Wishlist ** Changed in: sosreport (Ubuntu Trusty) Importance: Undecided => Wishlist ** Changed in: sosreport (Ubuntu Cosmic) Importance: Wishlist => Medium ** Bug watch added: Debian Bug tracker #900818 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 ** Also affects: sosreport (Debian) via https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 Importance: Unknown Status: Unknown ** Description changed: As we speak, sosreport released an interim version of sosreport (3.5.1) 7 days ago, but 3.6 will be release in late June 2018 with further enhancements in core sosreport functionality. I already did the request for debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 It would be great to have sosreport v3.6 in Cosmic & SRU'd in all - supported stable release once official release upstream. Just like we - did for v3.5. + supported stable release once official release upstream, considering the + fact that the release will contain a number of enhancements, new + features, and bug fixes and that sosreport is widely use by Canonical + support team to troubleshoot UA customer. - Considering the fact that the release will contain a number of - enhancements, new features, and bug fixes and that sosreport is widely - use by Canonical support team to troubleshoot UA customer. + Just like we did for v3.5, -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1775195 Title: sosreport v3.6 Status in sosreport package in Ubuntu: New Status in sosreport source package in Trusty: New Status in sosreport source package in Xenial: New Status in sosreport source package in Bionic: New Status in sosreport source package in Cosmic: New Status in sosreport package in Debian: Unknown Bug description: As we speak, sosreport released an interim version of sosreport (3.5.1) 7 days ago, but 3.6 will be release in late June 2018 with further enhancements in core sosreport functionality. I already did the request for debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 It would be great to have sosreport v3.6 in Cosmic & SRU'd in all supported stable release once official release upstream, considering the fact that the release will contain a number of enhancements, new features, and bug fixes and that sosreport is widely use by Canonical support team to troubleshoot UA customer. Just like we did for v3.5, To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sosreport/+bug/1775195/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
