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 related
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 abort
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.
https://bugs.launchpad.net
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: "PXL_20220322_174906705.jpg"
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 has
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
*** 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
Title
*** 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 Ubuntu.
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/
i
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
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,
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 not
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 (U
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 sai
@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 recei
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
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 t
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.
https://b
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 notificati
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 sub
** 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 U
... 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:
Composi
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 with
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.
h
** 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
kern
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 t
** 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 new
@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 noti
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 cause
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
Ti
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.
-
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
500
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 => Conf
** 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.
https://bugs.lau
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
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.
https://bugs.launchpad.net/bug
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: Incomp
** 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 wrongly
** 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 the
** 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 @172.16
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
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:
landsc
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 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)
Impo
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
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 devi
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 because
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 (
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.
https://bugs.lau
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 Ubunt
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-
tftp/python3-txtftp_0.1~bzr47-0ub
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 us
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.
https://bugs.launchpad.ne
@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, wh
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 confi
** 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
** 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 t
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 require
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 3.26.
** 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, whic
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]
ad
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
propagat
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 n
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)
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 t
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
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)
** 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 B
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 th
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.
https://bugs.launchpad.net/bugs/17
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.
https://bugs
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 b
** 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
** 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 particular
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 t
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 Bi
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 attem
*** 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 i
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 th
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 of
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.
https://bugs.launchpad.net/bug
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 secon
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
while
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 ' o
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
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
condition,
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 /usr
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 ad-ho
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 -
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
Title
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.
https://bugs.launchpad.net/bugs/166469
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 0c:c4:7a:c0:31:fa brd ff:ff:ff:ff:ff:ff
--
Y
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
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)
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
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 sysct
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: gfp_
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 c
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
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: "a
1 - 100 of 288 matches
Mail list logo