[Touch-packages] [Bug 1439436] Re: NM in vivid tries to take over my libvirt bridge, deconfigures its address

I'm seeing this on Trusty for VLAN interfaces. In the log I see: info (eth0.1): carrier is OFF info (eth0.1): VLAN ID 1 with parent eth0 info (eth0.1): new VLAN device (driver: '8021q' ifindex: 26) info (eth0.1): exported as /org/freedesktop/NetworkManager/Devices/18 info (eth0.1): device state

[Touch-packages] [Bug 1439436] Re: NM in vivid tries to take over my libvirt bridge, deconfigures its address

I missed some relevant logs: SCPlugin-Ifupdown: devices added (path: /sys/devices/virtual/net/eth0.1, iface: eth0.1) SCPlugin-Ifupdown: device added (path: /sys/devices/virtual/net/eth0.1, iface: eth0.1): no ifupdown configuration found. From that, I think I found the root cause. After doing

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

As an aside, Zoltan, I'm curious what symptoms you see due to this issue. Since the gateway is off-link, it should not be reachable from the provisioning network. What errors occur in your environment due to this bug? -- You received this bug notification because you are a member of Ubuntu Touch

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

Ah, disregard my previous question. When I re-read this bug I missed the part where you said "So instead of picking up the /16 subnet correctly for the 10.6.239.3 IP, it picks up the /24 from the network where it gets it's default gateway from." ** Changed in: isc-dhcp (Ubuntu) Status: New

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

Ah, thanks for all the information. (I didn't realize you were pasting the kernel parameter.) After researching this problem, I think this definitely looks like a bug in isc-dhcp. (The other possibility is that MAAS is configuring dhcpd incorrectly in this situation, but so far it looks like our

[Touch-packages] [Bug 1519120] Re: Xenial: VLAN interfaces don't work until after a reboot

After I rebooted, the "vlan100" interface was created. So perhaps this bug just has to do with the fact that I tried to configure the a VLAN without the 'vlan' package installed. ** Summary changed: - Xenial: VLAN interfaces don't work when defined in the UI + Xenial: VLAN interfaces don't work

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

Thanks for taking the time to report a bug in MAAS. Can you give us more information on this line in your bug report: ip=10.6.239.3:10.6.250.250:9.4.113.254:255.255.255.0 Is this from a packet capture? (if so, on which interface?) I'm trying to figure out what this means. In it you have:

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

Would it be possible for you to capture the DHCP packets (for example, using Wireshark) and attach them to the bug? Thanks! ** Changed in: maas Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to

[Touch-packages] [Bug 1518118] [NEW] IBus 1.5.11 needs to be packaged, to avoid breaking certain software

Public bug reported: IBus 1.5.11 needs to be packaged. Whenever I launch a recent JetBrains IDE (such as PyCharm), it warns on startup that IBus has a bug that can cause input to be blocked. See: https://youtrack.jetbrains.com/issue/IDEA-78860 They claim that IBus 1.5.11 is needed in order to

[Touch-packages] [Bug 1519120] Re: Xenial: VLAN interfaces don't work when defined in the UI

(For the record, 172.16.42.88 is my local mirror of us.archive.ubuntu.com and is updated hourly.) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1519120 Title:

[Touch-packages] [Bug 1519120] [NEW] Xenial: VLAN interfaces don't work when defined in the UI

Public bug reported: I tried to use the network manager UI to define a VLAN interface, and nothing happened. There are a few bugs here: (1) When creating a VLAN interface through the UI, the "vlan interface name" must be filled in. This should just default to ., rather than being a required

[Touch-packages] [Bug 1591411] Re: systemd-logind must be restarted every ~1000 SSH logins to prevent a ~25 second delay

Here's my (sad) workaround: $ sudo crontab -l 1,11,21,31,41,51 * * * * service systemd-logind restart ** Description changed: I noticed on a system that accepts large numbers of SSH connections that after awhile, SSH sessions were taking ~25 seconds to complete. Looking in

[Touch-packages] [Bug 1591411] [NEW] systemd-logind must be restarted every ~1000 SSH logins to prevent a ~25 second delay

Public bug reported: I noticed on a system that accepts large numbers of SSH connections that after awhile, SSH sessions were taking ~25 seconds to complete. Looking in /var/log/auth.log, systemd-logind starts failing with the following: Jun 10 23:55:28 test sshd[3666]: pam_unix(sshd:session):

[Touch-packages] [Bug 1519120] Re: Xenial: VLAN interfaces don't work until after a reboot

I'll leave this bug open, because as an Ubuntu Desktop user, I would expect this to work properly out-of-the-box without installing a package or rebooting. (That is, I shouldn't have to figure out that I needed to install the "vlan" package to get it to work, as a desktop user trying to

[Touch-packages] [Bug 1519120] Re: Xenial: VLAN interfaces don't work until after a reboot

How does the script in /etc/network/if-pre-up.d have anything to do with this bug? I thought that was placed there for ifupdown. This bug is about configuring VLANs with Network Manager, so that script shouldn't be relevant here. I just tried it again today on a freshly installed Xenial desktop.

[Touch-packages] [Bug 1519120] Re: NetworkManager VLAN support fails unless vlan package is manually installed

Another note: in addition to VLANs, NetworkManager lists other interface types for which the dependencies aren't installed as well: Bond Bridge Team The "ifenslave" and "bridge-utils" package would be needed for bonds and bridges to work out of the box. (I think bridge-utils might

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

In my testing on Xenial, you cannot set a child interface MTU to a value greater than its parent. For example, if eth0's MTU is 1500, setting eth0.100's MTU to 9000 (or 1501) causes: SIOCSIFMTU: Numerical result out of range This restriction makes sense when you consider the physical topology,

[Touch-packages] [Bug 1567744] Re: USB NICs get too long name for ifupdown aliases

This is also an issue for VLAN interfaces. To support VLANs, 10 characters should be the max. (16 - 1 [for \0], -1 [.], -4 [vid]) Throw in VLANs plus aliases, and, well, I guess we ought to use shorter names, such as (I don't know) "eth0". ;-) -- You received this bug notification because you

[Touch-packages] [Bug 1591411] Re: systemd-logind must be restarted every ~1000 SSH logins to prevent a ~25 second delay

Actually, please disregard the portion of my previous comment where I suspected we should consider patching systemd as well. I no longer think that is necessary. (My test case was flawed.) After correcting the issue (ensuring I was running with the properly-updated dbus fix), I was able to run

[Touch-packages] [Bug 1591411] Re: systemd-logind must be restarted every ~1000 SSH logins to prevent a ~25 second delay

I would like to thank the GitLab team for their excellent work triaging this issue (and getting a patch ready). Very nice work. I tested the version of dbus in Stan Hu's PPA here: https://launchpad.net/~stanhu/+archive/ubuntu/dbus After updating dbus to the version in this PPA, I ran my "ssh to

[Touch-packages] [Bug 1661869] Re: maas install fails inside of a 16.04 lxd container due to avahi problems

Since [the released version of] MAAS declares avahi-utils as a "Recommends", you can use `apt-get --no-install-recommends` as an alternate workaround. But then you'll lose zeroconf hostname discoveries in MAAS. I understand that this has been changed to a hard dependency in MAAS 2.2, so I'm glad

[Touch-packages] [Bug 1664748] Re: wifi connection drops, reconnects every 10 minutes

^ That is, please run that command on the client so we can see the full transaction history. It's hard to tell if the DHCP client isn't renewing fast enough, or possibly it's trying to renew but for some reason the server no longer recognizes the lease. -- You received this bug notification

[Touch-packages] [Bug 1664748] Re: wifi connection drops, reconnects every 10 minutes

Normal behavior is that the DHCP client begins to renew the lease half way through the lease time. So, for MAAS's 10 minute lease, it should be after ~5 minutes. After ~85-90% of the time (the rebind time), the client will give up on the lease and try to get a new one, under the assumption that

[Touch-packages] [Bug 1664748] Re: wifi connection drops, reconnects every 10 minutes

Marking 'Opinion' for MAAS since we might want to discuss if it's possible to better balance renewal times for clients on unreliable networks. I do not believe this is a bug in the ISC DHCP client or NetworkManager, so marking 'Invalid' for NM. -- You received this bug notification because you

[Touch-packages] [Bug 1664748] Re: wifi connection drops, reconnects every 10 minutes

** Changed in: maas (Ubuntu) Status: Opinion => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1664748 Title: wifi connection drops, reconnects

[Touch-packages] [Bug 1664748] Re: wifi connection drops, reconnects every 10 minutes

After further investigation, this is also invalid for MAAS. The root cause of this issue is: two separate interfaces requesting an address from the same DHCP server cannot be supported. (At least, not without some serious sysctl hacking at a minimum, but I'm not even sure about that.) If you

[Touch-packages] [Bug 1664748] Re: wifi connection drops, reconnects every 10 minutes

One last note on this. It might be possible to get this setup to work (on the client) using the following sysctl changes: net.ipv4.conf.all.arp_filter = 1 (or 0) net.ipv4.conf.all.rp_filter = 2 net.ipv4.conf.all.arp_ignore = 2 This is completely untested. But in theory[1]: - arp_filter = 1:

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

I have regression-tested MAAS images (supplied by LaMont) containing the proposed fixes on a set of amd64 virtual machines in an IPv4 environment, and LaMont has carried out testing in an IPv6 environment. Everything seems to be working, so I'm setting this to verification- done. ** Tags

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

Note, this is NOT a case where IPv6 has been disabled explicitly; this is the case where I have a link-down interface. (`ip link` reports NO- CARRIER.) 3: eno1: mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000 link/ether

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

I'm still seeing this on trunk. Mar 28 22:58:05 skylake dhclient[4804]: no link-local IPv6 address for eno1 Mar 28 22:58:05 skylake dhclient[4804]: Mar 28 22:58:05 skylake dhclient[4804]: If you think you have received this message due to a bug rather Mar 28 22:58:05 skylake dhclient[4804]: than

[Touch-packages] [Bug 1664846] Re: [Wishlist] Support for teaming driver

If we decide to implement this (I think it's still a wishlist item), I would prefer it to be more of a 'preferred driver choice' type of option. That is, model it like a normal bond in the YAML, but have something like a "preferred-driver: teaming" or similar, with a way to pass in additional

[Touch-packages] [Bug 1779767] [NEW] Default cron PATH does not include /snap/bin

Public bug reported: I recently changed from a .deb install of LXD to a snap, and was surprised that one of my crontab scripts stopped working. I see that $PATH in a cron script only contains "/usr/bin:/bin", whereas my default shell also includes "/snap/bin". It seems to me that for the best

[Touch-packages] [Bug 1739672] Re: Regression in getaddrinfo(): calls block for much longer on Bionic (compared to Xenial)

Workaround: grep -q 'LLMNR=no' /etc/systemd/resolved.conf || \ echo 'LLMNR=no' | sudo tee -a /etc/systemd/resolved.conf sudo service systemd-networkd restart -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to

[Touch-packages] [Bug 1739672] Re: Regression in getaddrinfo(): calls block for much longer on Bionic (compared to Xenial)

** Description changed: When testing MAAS on Bionic, we noticed sluggish performance that we could not immediately explain. After comparing the results from a run of the test suite on Xenial to a run on Bionic, we determined that the slowdowns had to do with DNS lookups. In

[Touch-packages] [Bug 1739672] Re: Regression in getaddrinfo(): calls block for much longer on Bionic (compared to Xenial)

I just tested with the Xenial kernel and Bionic userspace and observed that the bug still occurs, so marked Invalid for 'linux'. ** Changed in: linux (Ubuntu) Status: Incomplete => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages,

[Touch-packages] [Bug 1739672] Re: Regression in getaddrinfo(): calls block for much longer on Bionic (compared to Xenial)

Interesting; the first thing I tried when triaging this was to edit /etc/nsswitch.conf as follows: # hosts: files mdns4_minimal [NOTFOUND=return] dns myhostname hosts: files dns ... to eliminate the possibility that it was multicast DNS causing the slowdown. But it appears I'm

[Touch-packages] [Bug 1744015] [NEW] [bionic] Locating necessary Network Manager plugins (for example, OpenVPN) is not a good experience

Public bug reported: Steps to reproduce: (0) Install Bionic desktop (1) Observe that only PPTP connection type is available when adding a VPN in the UI (using any method). (2) Run `sudo apt-get install network-manager-openvpn`. (3) Observe that in the top panel "VPN Settings" option, clicking

[Touch-packages] [Bug 1744015] Re: [bionic] Installing network-manager-openvpn is not enough to add OpenVPN options to the connection editor

IMHO, it would be nice if the Desktop install supported all the VPN plugins out-of-the-box. Users shouldn't need to hunt for plugin packages to install. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in

[Touch-packages] [Bug 1750884] Re: [2.4, bionic] /etc/resolv.conf not configured correctly in Bionic, leads to no DNS resolution

I don't want to change the v1 YAML in MAAS to output per-interface DNS, because this risks causing a change of behavior in pre-netplan deployments. It seems this is necessary in Netplan, but it isn't clear to me that this is correct. I think it's valuable to take a step back and look at the

[Touch-packages] [Bug 1739672] [NEW] Regression in getaddrinfo(): calls block for much longer on Bionic (compared to Xenial)

Public bug reported: When testing MAAS on Bionic, we noticed sluggish performance that we could not immediately explain. After comparing the results from a run of the test suite on Xenial to a run on Bionic, we determined that the slowdowns had to do with DNS lookups. In particular, if MAAS

[Touch-packages] [Bug 1739672] Re: Regression in getaddrinfo(): calls block for much longer on Bionic (compared to Xenial)

Note: I doubt this bug is in the kernel itself; I initially attempted to file it under glibc at first, but for some reason the `linux` package was selected. I also added `systemd` in case the difference in behavior can be explained by the addition of resolved. Note that these tests were run on

[Touch-packages] [Bug 1739672] Re: Regression in getaddrinfo(): calls block for much longer on Bionic (compared to Xenial)

** Tags added: bionic -- 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/1739672 Title: Regression in getaddrinfo(): calls block for much longer on Bionic (compared to

[Touch-packages] [Bug 1744015] Re: [bionic] Locating necessary Network Manager plugins (for example, OpenVPN) is not a good experience

** Summary changed: - [bionic] Installing network-manager-openvpn is not enough to add OpenVPN options to the connection editor + [bionic] Locating necessary Network Manager plugins (for example, OpenVPN) is not a good experience ** Description changed: Steps to reproduce: (0) Install

[Touch-packages] [Bug 1750884] Re: [2.4, bionic] /etc/resolv.conf not configured correctly in Bionic, leads to no DNS resolution

We discussed this today and decided that the proper place to fix this is not in MAAS; the v1 YAML containing global DNS servers should be converted to equivalent valid Netplan (using a heuristic). Alternatively, global DNS could be added to the Netplan schema (possibly as a shortcut to apply

[Touch-packages] [Bug 1750884] Re: [2.4, bionic] /etc/resolv.conf not configured correctly in Bionic, leads to no DNS resolution

** Changed in: maas Status: Triaged => Won't Fix ** Changed in: maas Assignee: Mike Pontillo (mpontillo) => (unassigned) ** Changed in: maas Milestone: 2.4.0alpha2 => None -- You received this bug notification because you are a member of Ubuntu Touch seeded packag

[Touch-packages] [Bug 1763534] Re: ifconfig -s (or -a -s) only outputs 8 characters of the interface name, when interfaces are 10+ characters.

Note: if you are using a Xenial based MAAS that has not been patched to use `ip` instead, and you use it to commission on Bionic, it will fail due to this issue. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to net-tools in

[Touch-packages] [Bug 1752737] Re: [2.3.0-6434] mDNS observer problems

** Also affects: avahi via https://github.com/lathiat/avahi/issues/169 Importance: Unknown Status: Unknown ** Also affects: avahi (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages,

[Touch-packages] [Bug 1858883] [NEW] date utility format unexpectedly changed after upgrade from bionic to focal

Public bug reported: After upgrading my Bionic system to Focal, I noticed a significant change in the output of the `date` utility. This could potentially cause regressions for those who are relying on a consistent date format when using `date` in shell scripts. EXPECTED BEHAVIOR

[Touch-packages] [Bug 1858883] Re: date utility format unexpectedly changed after upgrade from bionic to focal

Thanks for taking a look. Yes, it looks like the `date` utility now observes locale-based defaults, such as the new default: $ date Wed 25 Mar 2020 09:47:47 AM PDT Here are some other combinations I tried: $ LC_TIME="" date Wed 25 Mar 2020 09:47:53 AM PDT (setting LC_TIME to an empty string