[Bug 1964037] Re: gnome-shell crashes (fatal error logged in create_fallback_offscreen) when attempting to enable second monitor on second GPU (Nvidia >= 495) in a Wayland session

Thanks for your attention to this bug, Daniel. For the record, I don't think a set up like this is particularly weird; I'm seeing this issue on a laptop with embedded NVIDIA graphics. The "second video card", in my case, is the integrated Intel graphics card. Also, I'm not sure if this is

[Bug 1965805] Re: Ubiquity failure - Error while installing packages Ubuntu Jammy

Thanks for your attention. For the record, I saw the same errors mentioned in this bug after the Firefox install timed out, which is why I posted the screenshot. (I thought it might provide additional detail about the root cause.) After the snap install timed out, the entire install process

[Bug 1965805] Re: Ubiquity failure - Error while installing packages Ubuntu Jammy

FYI: I was able to work around this by asking Ubiquity to do a minimal install, not to download packages during install, and turning off WiFi (just to be sure). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu.

[Bug 1965805] Re: Ubiquity failure - Error while installing packages Ubuntu Jammy

I'm seeing what might be the same issue with the Jammy live image. Before I got the error, I saw that it was trying to install the Firefox snap and was not able to reach the snap store. (For the record, the machine _did_ have a network connection.) ** Attachment added:

[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

[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

[Bug 1664698] Re: No documented way to set the MAC for a bridge or bond

*** This bug is a duplicate of bug 1690388 *** https://bugs.launchpad.net/bugs/1690388 ** Changed in: maas Milestone: next => 2.6.0 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1664698

[Bug 1664698] Re: No documented way to set the MAC for a bridge or bond

*** This bug is a duplicate of bug 1690388 *** https://bugs.launchpad.net/bugs/1690388 ** Merge proposal linked: https://code.launchpad.net/~mpontillo/maas/+git/maas/+merge/361468 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to

[Bug 1805920] Re: iPXE ignores vlan 0 traffic

Sorry for the confusion. To be clear, the idea of using MAAS on Xenial was in order to test if the newly-modified iPXE (on Bionic) can support iSCSI boot. But come to think of it, I don't think that's a good test. If I remember correctly, MAAS used TFTP to transfer the kernel and initrd, /then/

[Bug 1805920] Re: iPXE ignores vlan 0 traffic

Yes, MAAS 2.3 (the last revision of MAAS supported on Xenial) can support iSCSI when it is placed in backward compatibility mode; how to do this is documented in the changelog as follows: maas $PROFILE maas set-config name=http_boot value=False MAAS 2.2 and earlier (no longer supported) used

[Bug 1804861] Re: MTU size defined on /etc/netplan/50-cloud-init.yaml not applied

Thanks Steve; that's good to know. I think that will be very useful, especially when deploying a machine that has hardware such as switch ports, which may show up as separate interfaces but share a MAC. I'm open to adding driver information in future releases. We still need to be careful on this,

[Bug 1805920] Re: iPXE ignores vlan 0 traffic

Unfortunately, a modern MAAS no longer uses iSCSI; it will fetch all necessary data over HTTP. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1805920 Title: iPXE ignores vlan 0 traffic To manage

[Bug 1805920] Re: iPXE ignores vlan 0 traffic

Setting to 'Confirmed' in the kernel, although it's not clear what the actual fix would entail. It would certainly be nice to be able to tell a Linux virtual bridge to transparently strip off priority tags before L2 forwarding occurs. That would prevent the issue with iPXE. ** Changed in: linux

[Bug 1805920] Re: iPXE ignores vlan 0 traffic

I think the issue is that removing the tag could be seen as a bug, not a feature, since by removing it, you would be potentially stripping off a priority tag that could be used further up the stack. (For example, if the machine was deployed with a virtual bridge that was capable of manipulating

[Bug 1805920] Re: iPXE ignores vlan 0 traffic

@vhart, can you clarify that last comment? Do you mean that the CentOS 6 VMs exhibit the issue caused by the VLAN 0 tags and the CentOS 7 tags do not? Or are you saying the tags are filtered elsewhere in the stack on CentOS 6 (such as the NIC driver, 8021q driver, or virtual bridge)? -- You

[Bug 1804861] Re: MTU size defined on /etc/netplan/50-cloud-init.yaml not applied

This is a long thread; sorry for adding fuel to the fire. But I have a some questions/comments. (1) I feel like if we don't fix how matching works for 'ethernets' in Netplan, we're not mapping the user's intent to an appropriate configuration. The user is saying "I have two physical interfaces. I

[Bug 1805920] Re: iPXE ignores vlan 0 traffic

Interesting developments. I agree that it doesn't seem like `bridge-nf- filter-vlan-tagged` is what we want, unless there is a special case not filter packets tagged on VID 0. It might be worth trying this out on the bridge used to boot the pod VMs. The frustrating thing about this bug report is

[Bug 1805920] Re: iPXE ignores vlan 0 traffic

Marking Invalid for MAAS since this is unrelated to MAAS itself. ** Changed in: maas Status: Incomplete => Opinion ** Changed in: maas Status: Opinion => Invalid -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu.

[Bug 1797581] Re: Composing a VM in MAAS with exactly 2048 MB RAM causes the VM to kernel panic

Looking again at the date stamps, I don't see any squashfs filesystems older than October 15th. The kernels are all from ~September 25th. So I feel like this must have been an interaction between the kernel September 25th and whatever the previous squashfs was. -- You received this bug

[Bug 1797581] Re: Composing a VM in MAAS with exactly 2048 MB RAM causes the VM to kernel panic

After triaging this again on a call with Andres (who originally reported this) this morning, we determined that this issue is no longer reproducible with MAAS. The only way for me to explain it at this point was that there was something wrong with the daily image MAAS was using last week, and a

[Bug 1797581] Re: Composing a VM in MAAS with exactly 2048 MB RAM causes the VM to kernel panic

** Changed in: linux (Ubuntu) Status: Confirmed => Incomplete ** Changed in: maas Status: Invalid => Incomplete ** Changed in: qemu (Ubuntu) Status: Invalid => Incomplete -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to

[Bug 1797581] Re: Composing a VM in MAAS with exactly 2048 MB RAM causes the VM to kernel panic

... it's interesting that [practically?] the same kernel version that fails consistently with Bionic works just fine with Xenial. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1797581 Title:

[Bug 1797581] Re: Composing a VM in MAAS with exactly 2048 MB RAM causes the VM to kernel panic

I just tried Xenial with the HWE kernel - same result (success). FYI. https://paste.ubuntu.com/p/WpqHnzbsS7/ -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1797581 Title: Composing a VM in MAAS

[Bug 1797581] Re: Composing a VM in MAAS with exactly 2048 MB RAM causes the VM to kernel panic

Good idea @rharper. It's easy for MAAS to attempt commissioning on Xenial or Bionic, so I gave Xenial a try. It works fine![1] [1]: Console log - https://paste.ubuntu.com/p/58hfBX6BhY/ -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu.

[Bug 1797581] Re: Composing a VM in MAAS with exactly 2048 MB RAM causes the VM to kernel panic

** Changed in: qemu (Ubuntu) Status: Incomplete => Invalid -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1797581 Title: Composing a VM in MAAS with exactly 2048 MB RAM causes the VM to

[Bug 1797581] Re: Composing a VM in MAAS with exactly 2048 MB RAM causes the VM to kernel panic

I agree that this doesn't look like a QEMU issue, and I agree that it doesn't look like a [general] networking hiccup. @paelzer, the easiest way to get the exact configs you need would be to install MAAS similar to how I've described on our discourse forum[1]. The PXE config will be /similar/ to

[Bug 1796164] Re: After interface/IP changes, bind9 can fail to respond to queries on the new interface

** Changed in: bind9 (Ubuntu) Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1796164 Title: After interface/IP changes, bind9 can fail to respond to queries on the

[Bug 1796164] Re: After interface/IP changes, bind9 can fail to respond to queries on the new interface

@ahasenack, nice find! I guess I had assumed the second-dns-server-past- the-post would have failed to come online, so didn't think to check this. In addition to my discourse post, I think we may have some tutorials and/or docs that need to be updated based on this. -- You received this bug

[Bug 1797581] Re: Composing a VM in MAAS with exactly 2048 MB RAM causes the VM to kernel panic

Here's a full console log from the failure. https://paste.ubuntu.com/p/zmS7CP7NKr/ -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1797581 Title: Composing a VM in MAAS with exactly 2048 MB RAM

[Bug 1797581] Re: Composing a VM in MAAS with exactly 2048 MB RAM causes the VM to kernel panic

It's an empty image - MAAS PXE boots the VM. Could you give it a try with MAAS? I can help you with the setup if needed - just ping me on IRC. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1797581

[Bug 1797581] Re: Composing a VM in MAAS with exactly 2048 MB RAM causes the VM to kernel panic

Here's the log from the failing VM. Doesn't look too unusual to me... https://paste.ubuntu.com/p/JpmSxmwjfM/ ** Description changed: Using latest MAAS master, I'm unable to compose a VM over the UI - successfully. BY this it means that the VM is created, but it fails with - a kernel panic. -

[Bug 1797581] Re: Composing a VM in MAAS with exactly 2048 MB RAM causes the VM to kernel panic

Here's the version information. libvirt-bin: Installed: 4.0.0-1ubuntu8.5 Candidate: 4.0.0-1ubuntu8.5 Version table: *** 4.0.0-1ubuntu8.5 500 500 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages 100 /var/lib/dpkg/status 4.0.0-1ubuntu8.2 500

[Bug 1797581] Re: Composing a VM in MAAS with exactly 2048 MB RAM causes the VM to kernel panic

Here's an example of working XML (with 2047 MB RAM) that MAAS generated: https://paste.ubuntu.com/p/mkF6Kp4hx8/ And here's an example of non-working XML (with 2048 MB RAM) that MAAS generated: https://paste.ubuntu.com/p/27HHDrzwm8/ ** Changed in: linux (Ubuntu) Status: Incomplete =>

[Bug 1797581] Re: Composing a VM in MAAS with exactly 2048 MB RAM causes the VM to kernel panic

** Summary changed: - Composing a VM in MAAS with exactly 2048 MB RAM causes kernel panic + Composing a VM in MAAS with exactly 2048 MB RAM causes the VM to kernel panic -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu.

[Bug 1797581] Re: [2.5] Composing a VM with 2048 MB RAM causes kernel panic

We can't run apport-collect since the machine doesn't boot, but this was seen with a non-tainted 4.15.0.36-generic kernel in my environment. ** Changed in: linux (Ubuntu) Status: Incomplete => New ** Summary changed: - [2.5] Composing a VM with 2048 MB RAM causes kernel panic + Composing

[Bug 1797581] Re: [2.5] Composing a VM with 2048 MB RAM causes kernel panic

To be clear, the kernel panic is seen when a VM is composed in MAAS with exactly 2048 MB of RAM. Composing with 2047 or 2049 MB RAM results in a working VM. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu.

[Bug 1797581] Re: [2.5] Composing a VM with 2048 MB RAM causes kernel panic

Adding the linux package; we should narrow down the issue to see if it's in kernel space or user space. ** Summary changed: - [2.5, UI] Composing a VM over the UI is broken - VM has kernel panic + [2.5] Composing a VM with 2048 MB RAM causes kernel panic ** Changed in: maas Status:

[Bug 713556] Re: Sharkoon Fireglider mouse is wrongly detected as a joystick

** Merge proposal unlinked: https://code.launchpad.net/~newell-jensen/maas/+git/maas/+merge/343053 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/713556 Title: Sharkoon Fireglider mouse is

[Bug 1796164] Re: After interface/IP changes, bind9 can fail to respond to queries on the new interface

** Description changed: Steps to reproduce: (1) Install MAAS. - (2) Add an interface to a MAAS controller with an IP address + (2) Add a bridge interface to a MAAS controller with an IP address (this + can be easily done using libvirt)[1]. - (3) Observe that bind9 is responding on

[Bug 1796164] Re: [2.5] MAAS must restart the bind9 service if controller IP addresses change

** Description changed: Steps to reproduce: (1) Install MAAS. (2) Add an interface to a MAAS controller with an IP address - (3) Observe that bind9 is not listening on that interface, and MAAS - internal domains will not resolve (for example, if you run something - like `dig

[Bug 1796164] Re: [2.5] MAAS must restart the bind9 service if controller IP addresses change

Looks like `automatic-interface-scan`, which is a default option in BIND 9.10, is supposed to handle this. But in this case, even though bind9 listens on the new IP address, it still allows queries. I tried forcing the issue using `rndc scan`, but I still could not use the new IP address to query

[Bug 277038] Re: landscape-common.postinst stuck with defunct who

Another data point: this is happening in the service monitor in MAAS when using `getProcessOutputAndValue`. (See also bug #1793448) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/277038 Title:

[Bug 1439473] Re: Adding a boot image sync URL with an unqualified hostname fails

Adding python-django since this is actually a bug in Django, not in MAAS. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1439473 Title: Adding a boot image sync URL with an unqualified hostname

[Bug 1439473] Re: Adding a boot image sync URL with an unqualified hostname fails

I just re-tested this on 2.5; it's still a problem. Rather than Invalid, we can consider this a Won't Fix. I don't think it's a priority. ** Changed in: maas Status: Invalid => Triaged ** Changed in: maas Status: Triaged => Won't Fix ** Also affects: python-django (Ubuntu)

[Bug 1773959] Re: High CPU usage by gnome-shell when only running gnome-terminal

I'm seeing moderately high CPU usage from the gnome-shell process as well. It seems to stay running at at least 5% at all times. I decided to use strace to see what it was doing: $ sudo strace -c -p 6916 strace: Process 6916 attached strace: Process 6916 detached % time seconds usecs/call

[Bug 1784501] Re: libvirtd is unable to configure bridge devices inside of LXD containers

My 2nd theory was correct. ;-) Sorry for polluting this bug report with my thinking-out-loud. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1784501 Title: libvirtd is unable to configure bridge

[Bug 1784501] Re: libvirtd is unable to configure bridge devices inside of LXD containers

To be fair, it's also possible that I did something like the following in my previous test container and forgot about it. ;-) cat << EOF > maas.xml maas EOF virsh net-define maas.xml rm maas.xml virsh net-start maas virsh net-autostart maas -- You received this bug notification

[Bug 1784501] Re: libvirtd is unable to configure bridge devices inside of LXD containers

Nothing has changed regarding privileged vs. unprivileged settings. I just set this up again with a privileged container, and I believe the cause of the regression to actually be in libvirt. I think it must have silently ignored the bridge configuration error before and marked the network active

[Bug 1784501] Re: libvirtd is unable to configure bridge devices inside of LXD containers

This seems to be a regression on bionic; I have been using libvirtd inside a container for several weeks; today when I tore down and rebuilt the container I hit this bug. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu.

[Bug 1736975] Re: netplan does not bring up anonymous bridge on boot

I had just filed bug #1782155, which may be a duplicate of this one. Adding 'accept-ra: no' does not work around the issue for me. I'm happy to test the newer version of Netplan though; is it available in a PPA pending SRU? -- You received this bug notification because you are a member of

[Bug 1376483] Re: AttributeError: 'Port' object has no attribute 'socket'

Can those of you who are still encountering this issue try the latest version of python3-txtftp? It seems that it may still need to be backported to Xenial. It can be downloaded directly from the archive at: http://archive.ubuntu.com/ubuntu/pool/main/p/python-tx-

[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

[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 Bugs, which is subscribed to Ubuntu.

[Bug 1759920] Re: intel-microcode 3.20180312.0 causes lockup at login screen(w/ linux-image-4.13.0-37-generic)

@tyhicks, I don't have an Artful test system, but I confirmed on Xenial (4.4.0-116-generic) that `apparmor=0` is a workaround, without the `noibpb` option and with intel-microcode version 3.20180312.0~ubuntu16.04.1. -- You received this bug notification because you are a member of Ubuntu Bugs,

[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

[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 Bugs, which is s

[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 Bugs, which is subscribed

[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

[Bug 1748573] [NEW] gdm-session-worker crashed with SIGABRT in g_assertion_message()

Public bug reported: This occurred after disabling Wayland in the gdm3 configuration file (I installed Bionic prior to the switch to Xorg) and installing the DisplayLink driver so that the DisplayPort on my Lenovo dock would work. ProblemType: Crash DistroRelease: Ubuntu 18.04 Package: gdm3

[Bug 1748332] Re: Bridges fail to come online when configured via LXD, netplan, and cloud-init

** No longer affects: cloud-init (Ubuntu) ** Summary changed: - Bridges fail to come online when configured via LXD, netplan, and cloud-init + Bridges without an address fail to come online with netplan+networkd -- You received this bug notification because you are a member of Ubuntu Bugs,

[Bug 1748332] Re: Bridges fail to come online when configured via LXD, netplan, and cloud-init

I can confirm that this is a workaround (specifying an address to configure the bridge with): lxc config set bionic-maas2 user.network-config "version: 2 ethernets: eth0: match: name: eth0 dhcp4: true eth1: match: name: eth1 bridges: br0: interfaces: [eth1]

[Bug 1748332] Re: Bridges fail to come online when configured via LXD, netplan, and cloud-init

Actually it might be nice in this case to, in fact, bind the carrier to eth1. In this scenario, I was planning on hanging other nested VMs and/or containers on the virtual bridge inside the LXC. If the underlying link was down for whatever reason, it would be more honest for that state to

[Bug 1748332] [NEW] Bridges fail to come online when configured via LXD, netplan, and cloud-init

Public bug reported: I configured a container as follows, using some bridges (virbr0 and virbr1, my NAT network and test network, respectively) that I had previously configured in libvirt: lxc init ubuntu-daily:b bionic-maas2 -p '' -s default lxc network attach virbr0 bionic-maas2 eth0 eth0 lxc

[Bug 1655447] Re: IEEE indexes in netaddr package may not match data in ieee-data package

Reopening due to bug #1748031, which was seen when running MAAS with the latest netaddr version in Bionic. ** Changed in: maas Status: Won't Fix => Triaged ** Changed in: maas/2.1 Status: Won't Fix => Triaged ** Changed in: maas Assignee: (unassigned) => Mike

[Bug 1743249] Re: Failed Deployment after timeout trying to retrieve grub cfg

Ah, I see what you mean there; I used the following filter in Wireshark: udp.dstport == 25305 or udp.srcport == 25305 This is not the behavior I saw if the TFTP request is answered in a timely manner, so I suspect that the long delay between the initial request and the answer is causing the

[Bug 1743249] Re: Failed Deployment after timeout trying to retrieve grub cfg

Steve, can you be more specific about which packet capture showed the "stacked OACK" behavior? I looked at a packet capture Andres pointed me to, and don't see the "stacked OACKs" you describe. Each TFTP transaction (per RFC 1350) is indicated by the (source port, dest port) tuple, and I see that

[Bug 1744026] [NEW] [bionic] Connection issues are not possible to debug in the UI

Public bug reported: When using a graphical VPN client, one expects a concise error message, and/or graphical log viewer (specific to the failed connection) to explain what went wrong. This does not happen when using the OpenVPN gnome plugin. Instead, I have observed two possible behaviors: (1)

[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

[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

[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 Bugs, which is subscribed to Ubuntu.

[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 Bugs, which is subscribed to Ubuntu.

[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

[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 Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1739672 Title: Regression in getaddrinfo(): calls block for much longer on Bionic (compared to Xenial) To manage notifications

[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

[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 Bugs, which is subscribed

[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

[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

[Bug 1389830] Re: Don't use wlan0 for cluster to region communication [when cluster and region are on same machine]

*** This bug is a duplicate of bug 1418044 *** https://bugs.launchpad.net/bugs/1418044 ** This bug has been marked a duplicate of bug 1418044 Avoid picking the wrong IP for MAAS_URL and DEFAULT_MAAS_URL -- You received this bug notification because you are a member of Ubuntu Bugs, which

[Bug 1729127] Re: storage: No available machine matches constraints

If you want to debug this from the MAAS constraints perspective, there are a couple options that might be useful: dry_run=true verbose=true These parameters can be passed to the `machines allocate` API in MAAS in order to test which machine would be allocated, given the constraints. With

[Bug 1642298] Re: UEFI Xenial install sets computer to boot from hard disk

Targeting for MAAS 2.3.0 since it sounds like MAAS changes are required. ** Changed in: maas Status: Invalid => Triaged ** Changed in: maas Importance: Undecided => High ** Changed in: maas Milestone: None => 2.3.0 -- You received this bug notification because you are a member

[Bug 1710278] Re: [2.3a1] named stuck on reload, DNS broken

Thanks. I wonder if we shouldn't fix this in Ubuntu by tweaking the systemd control files so that the timeout values are more acceptable for production use. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu.

[Bug 1710278] Re: [2.3a1] named stuck on reload, DNS broken

Mark, if you observe the deadlock again, can you run "systemctl stop bind9", wait a few minutes (at least 2, but maybe up to 5), and then check if bind9 successfully stops? It looks like systemd will (by default) resort to more aggressive methods to kill a service if it doesn't stop after ~90

[Bug 1710278] Re: [2.3a1] named stuck on reload, DNS broken

I attempted to reproduce the bind9 issue by doing the following (in two separate sessions): # Queue 10,000 concurrent reloads (also tried removing the & to make it less parallel) i=0; while [ $i -lt 1 ]; do (/usr/sbin/rndc reload&); let i=$i+1; done # Hammer the DNS server with queries

[Bug 1710278] Re: [2.3a1] named stuck on reload, DNS broken

I'm +1 on throttling reloads; I think that is the most obvious and critical work item for the MAAS team to address. I have filed that as bug #1710308. I'm also +1 on better service monitoring using actual queries; I've filed that as bug #1710310. I think something equivalent to 'dig @127.0.0.1 '

[Bug 1710278] Re: [2.3a1] named stuck on reload, DNS broken

Right; to attempt to reproduce the issue, I would aggressively reload (changing the zone files each time) while at the same time sending a large amount of queries to the server (for records in locally authoritative zones?). -- You received this bug notification because you are a member of Ubuntu

[Bug 1710278] Re: [2.3a1] named stuck on reload, DNS broken

This is technically Invalid for MAAS unless there is something unsupported about how we're using BIND, but I'm marking it Triaged for now so we don't lose visibility (in case a fix in MAAS itself turns out to be required). It would be nice if the service monitoring in MAAS detected this

[Bug 1710278] Re: [2.3a1] named stuck on reload, DNS broken

Assuming the debug symbols I grabbed[1] for my install of bind9 on Xenial match yours (I have bind9 version 1:9.10.3.dfsg.P4-8ubuntu1.7 installed per "apt-cache policy bind9"), I did the following to grab a traceback: $ sudo apt-get install bind9-dbgsym libdns162-dbgsym libisc160-dbgsym $ gdb

[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

[Bug 1688335] [NEW] Classic confinement doesn't work with custom environment

Public bug reported: I have a snap that works fine in devmode with the following snapcraft YAML: ... environment: LD_LIBRARY_PATH: $LD_LIBRARY_PATH:$SNAP/lib:$SNAP/usr/lib/x86_64-linux-gnu However, this doesn't work when I change the confinement mode to 'classic'. When I do 'snap run

[Bug 1680266] Re: interface update will return successful with invalid params

I think this should be targeted for a later MAAS release. To do this correctly and consistently would mean re-examining the entire MAAS API. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1680266

[Bug 1664698] Re: No documented way to set the MAC for a bridge or bond

Curious what you mean by 're-applying'. Are you syaing it generates the correct configuration the first time, but it cannot subsequently be updated? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu.

[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

[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

[Bug 1448917] Re: apt-get -o quiet=1 dist-upgrade isn't quiet anymore

This bug also affects MAAS, since it clutters our hardware testing output with things like: (Reading database ... (Reading database ... 5%(Reading database ... 10%(Reading database ... 15%(Reading database ... 20%(Reading database ... 25%(Reading database .. ** Changed in: dpkg (Ubuntu)

[Bug 1666683] Re: Default VM overcommit sysctls in Ubuntu lead to unnecessary oom-killer invocation

After a few days of uptime I still saw issues with the ratio set to 100. I'll give 0 a try. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/183 Title: Default VM overcommit sysctls in Ubuntu lead

[Bug 1666683] Re: Default VM overcommit sysctls in Ubuntu lead to unnecessary oom-killer invocation

Hm. Oddly enough, pulseaudio seemed to have problems for me until I set the overcommit ratio higher (to 150). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/183 Title: Default VM overcommit

[Bug 1666683] Re: Default VM overcommit sysctls in Ubuntu lead to unnecessary oom-killer invocation

Changing status to "Confirmed". I don't think there are any relevant logs for this issue. Here's some anecdotal evidence, though: # dmesg | grep oom-killer [1389379.248406] apt-mirror invoked oom-killer: gfp_mask=0x26000c0, order=2, oom_score_adj=0 [1399428.772409] chrome invoked oom-killer:

[Bug 1666683] [NEW] Default VM overcommit sysctls in Ubuntu lead to unnecessary oom-killer invocation

Public bug reported: On my system, running a couple of LXD containers and VMs (16 GB RAM, 16 GB swap) seems to cause the kernel oom-killer to be frequently triggered. In order to try to resolve this, first I tried limiting the memory my containers were allowed to use, such as by using: lxc

[Bug 1665680] Re: Deploying nodes in multiple VLANs fails due to RPF filtering

I would recommend using loose-mode reverse path filtering on the MAAS server for now. Strict reverse path filtering seems like it would make a lot of sense for a border router, but little sense for an internal MAAS server. But I agree that it makes sense to supply a cloud-config-url (and related

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

  1   2   3   4   >