I'm confused, how is this change going to work when the "container"
environment variable is only present in PID1's environment but not in
any of its descendants?
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to zfs-linux in Ubuntu.
https://
Actually, LXC/LXD can't set environment variables in that way as systemd
strips all inherited environment.
Looking at the backlog it sounds like it'd be safe for us to just turn
off that timeout entirely in Ubuntu given that we can assume we'll
always have devtmpfs where it matters and so there's
This has now been fixed upstream:
https://github.com/zfsonlinux/zfs/pull/7270#event-1510096286
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1753288
Title:
ZFS setgid broken on 0.7
St
That looks like it, yes. As far as I know most of us only noticed this
when bionic switched from 0.6.x to 0.7.x so yes, 0.6.x seems fine and
current 0.7.x is affected.
I've commented on the github issue and will reach out to Wolfgang (Blub)
on IRC otherwise (he hangs out in the LXC/LXD dev channel
Public bug reported:
Hey there,
We've had one of our LXD users report that setting the setgid bit inside
a container using ZFS on Ubuntu 18.04 (zfs 0.7) is silently failing.
This is not a LXD bug as the exact same operation works on other
filesystems.
There are more details available here:
https
Looks good to me. Delta on libseccomp is small and self contained and
aligns with what has been included in the upstream kernel.
FFe granted
** Changed in: libseccomp (Ubuntu)
Status: New => Triaged
--
You received this bug notification because you are a member of Kernel
Packages, which
** Changed in: lxd (Ubuntu Xenial)
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1611078
Title:
Support snaps inside of lxd containers
Stat
** No longer affects: lxd (Ubuntu Xenial)
** No longer affects: lxd (Ubuntu Zesty)
** No longer affects: lxd (Ubuntu Artful)
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to zfs-linux in Ubuntu.
https://bugs.launchpad.net/bugs/1567557
Ti
** No longer affects: lxd (Ubuntu)
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to zfs-linux in Ubuntu.
https://bugs.launchpad.net/bugs/1567557
Title:
Performance degradation of "zfs clone"
Status in Native ZFS for Linux:
New
Status
That's pure ZFS completely outside of LXD.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to zfs-linux in Ubuntu.
https://bugs.launchpad.net/bugs/1567557
Title:
Performance degradation of "zfs clone" when under load
Status in lxd package
(but doing something pretty similar to what LXD does internally as far
as clones and mountpoint handling)
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to zfs-linux in Ubuntu.
https://bugs.launchpad.net/bugs/1567557
Title:
Performance de
I'm seeing similar performance degradation on xenial except that the
server I used seems to be pretty slow to start with too:
root@athos:~# sh test.sh
Creating 100 clones
Took: 11 seconds (9/s)
Creating 200 clones
Took: 46 seconds (4/s)
Creating 400 clones
Took: 297 seconds (1/s)
--
You receive
Creating 100 clones
Took: 4 seconds (25/s)
Creating 200 clones
Took: 13 seconds (15/s)
Creating 400 clones
Took: 46 seconds (8/s)
Creating 600 clones
Took: 156 seconds (3/s)
```
#!/bin/sh
zfs destroy -R castiana/testzfs
rm -Rf /tmp/testzfs
zfs create castiana/testzfs -o mountpoint=none
zfs snaps
I'm trying to remember if we had to bump any of the sysctls to actually
reach 1024 containers, I don't think any of the usual suspects would be
in play until you reach 2000+ Alpine containers though.
If you do run out of some kernel resources, you can try applying the following
sysctls to get you
Our test machines aren't particularly impressive, just 12GB of RAM or so.
Note that as can be seen above, we're using Alpine (busybox) images rather than
Ubuntu to limit the resource usage and get us to a lot more containers per
system.
--
You received this bug notification because you are a me
We're looking at changing lxc to show /dev/ptmx as a real file rather than
symlink. This is however not particularly easy because:
- It can't be a bind-mount from the host (or it will interact with the host's
devpts)
- It can't be a straight mknod (because that's not allowed in unprivileged
co
Ok, so that's an apparmor or apparmor profile problem.
LXD recently changed to also allow for apparmor profiles to be loaded
inside privileged containers. This seems to align with your timeline
above.
Before that change, your kvm process wasn't itself confined when run
inside a privileged LXD con
No, the solution is that snapd shouldn't assume that /lib/modules exist
and just not attempt to bind-mount it if it's missing.
Systems that don't have kernels installed (like containers) shouldn't
have /lib/modules at all.
--
You received this bug notification because you are a member of Kernel
Colin: This is not what this issue is about.
This issue is about getting the ZFS tools installed by default in server
images, with the problem that doing so now would result in zfs-zed
running all the time for everyone, regardless of whether they use ZFS or
not.
What we want is:
- Don't load the
** Changed in: lxd (Ubuntu)
Status: Triaged => Fix Released
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to zfs-linux in Ubuntu.
https://bugs.launchpad.net/bugs/1672749
Title:
Please don't assume zfs module is always loaded
Stat
Adding a priority "high" task against zfs-linux since this is a post-FF
regression in expected behavior from a tool in main.
Consider this as coming from me as a release team member and TB member
rather than LXD upstream.
My preference here is that rather than just breaking every single script
an
I'd have preferred that Ubuntu's zfsutils be patched to attempt to load
the kernel module as needed since that change means that now any
documentation telling the user to use "zpool create" or similar zfs
commands will fail unless the user manually plays with modprobe...
That very much feels like
Oh, I got confused between the two bug reports. So -67 is just the
revert. If so, then it's fine, we've been running with a pre-upload
build of this provided by Jon for a while now and haven't seen any full
hang. We do still run in the original apparmor bug but it's no worse
than before at least.
I'll install -67 on our jenkins runners and see if we can reproduce it.
The changelog is a bit confusing as it shows a whole bunch of apparmor
reverts, including the commits that were meant to fix this issue. So
it's unclear whether a proper implementation of the fix was then applied
on top. If not
Running the same thing on zesty to see if the problem is present there too.
We get something a bit different but the result ends up being the same, all the
test runners crash.
```
buildd07 login: [ 976.607283] NMI watchdog: BUG: soft lockup - CPU#3 stuck for
22s! [lxd:34563]
[ 988.645772] NMI
We can reproduce this very easily by triggering a LXD testsuite run
which causes a lot of apparmor profiles and namespaces
creation/deletion, causing this issue. A busy LXD host would also hit
this eventually (if the similar BUG we had before is any indication).
--
You received this bug notificat
Public bug reported:
After upgrading to 4.4.0-65-generic all of our Jenkins test runners are
dying every 10 minutes or so. They don't answer on the network, on the
console or through serial console.
The kernel backtraces we got are:
```
buildd04 login: [ 1443.707658] BUG: unable to handle kernel
I've had a few armhf systems running cascardo's kernel and so far no
sign of the OOM or any other problem with it.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1655842
Title:
"Out of m
Just a note that Joe's armhf kernel has been working well for me.
I can't test cascardo's kernel as it's not built for armhf.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1655842
Title:
Nope, task removed.
** No longer affects: lxc (Ubuntu)
** No longer affects: lxc (Ubuntu Wily)
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1542049
Title:
lxc: ADT exercise test fail
Did you install squashfuse in your container?
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1611078
Title:
Support snaps inside of lxd containers
Status in Snappy:
Fix Released
Statu
This has been confirmed to affect both the 4.4 and 4.8 kernels.
** Project changed: apparmor => apparmor (Ubuntu)
** Also affects: linux (Ubuntu)
Importance: Undecided
Status: New
** Also affects: apparmor (Ubuntu Zesty)
Importance: Undecided
Status: New
** Also affects: lin
Christian will be testing 4.4.0-45 to see if we hit this issue with a
pre-aastacking kernel.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1645037
Title:
apparmor_parser hangs indefinit
** Changed in: linux (Ubuntu)
Status: Incomplete => Triaged
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1639345
Title:
lxc-attach to malicious container allows access to host
** Changed in: linux (Ubuntu)
Status: Incomplete => New
** Tags added: bot-stop-nagging
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1639345
Title:
lxc-attach to malicious cont
** Package changed: linux (Ubuntu) => lxc (Ubuntu)
** Changed in: lxc (Ubuntu)
Status: Confirmed => Triaged
** Changed in: lxc (Ubuntu)
Assignee: (unassigned) => Christian Brauner (cbrauner)
--
You received this bug notification because you are a member of Kernel
Packages, which is
** Changed in: lxd (Ubuntu Xenial)
Status: New => Fix Committed
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1611078
Title:
Support snaps inside of lxd containers
Status in Sna
Marking this bug fix released as all the bits we wanted done here have
been done.
We still have a separate bug open for the dependency on squashfuse and
its SRU to xenial.
** Changed in: snappy
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a
** Changed in: lxd (Ubuntu)
Status: Fix Committed => Fix Released
** No longer affects: lxd
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1611078
Title:
Support snaps inside of
So the problem is that zfs does its own loop mount handling without
using a loop device so without a block uevent...
Triggering on a uevent would only work for pools that are using physical
devices, not for those using file as loops, which is unfortunately a
rather common setup for LXD users who d
Right, so unfortunately we can't base it on whether the zfs module is
loaded, as it will effectively always be loaded as soon as we pre-
install zfsutils-linux in our images.
Now what we could do I guess is:
- Don't start ANY of the 3 zfs systemd units in containers (that should be
pretty trivia
So I've confirmed that the python3 side of this has been resolved.
zfsutils-linux as it is in yakkety right now has now been changed over
to python3 by Colin.
Though, as discussed by e-mail when Dustin first brought this up, there
is a second issue I think we should have resolved before we start
i
I'm assuming you have a system that's booted with the right kernel
option.
Can you check if /sys/devices/system/cpu/possible includes the isolated
CPU?
If not, then we could copy that value instead of having to parse the CPU
ranges from /sys/devices/system/cpu/isolated and substract that from the
I thought of looking at Cpus_allowed from the status file of the current
task or of pid 1, but since both of those would be affected by the task
being in a non-root cgroup, we can't rely on that.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribe
So the problem here is that LXD itself DOES NOT touch the cpuset
controller at all.
liblxc does have some initialization code in place which will copy the
parent value for cpuset.cpus and cpuset.mems if cgroup.clone_children
hasn't been set to 1 yet.
So I guess we'd need a change to the cgfsng ba
As a workaround, you could do "lxc profile set default limits.cpu 1-2"
which will have LXD setup the cpuset pinning for all containers to avoid
CPU 0.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.
Seems correct to have this tracked as a kernel bug. Unless you set
limits.cpu in LXD, LXD will not alter the cpu pinning in any way. And
even if it did, it'd do so through the cpuset cgroup, which shouldn't
allow a sub-cgroup to be any more permissive than the root cgroup.
--
You received this bu
Moving this over to the kernel. The upstream issue is closed for the
same reason.
The network namespace is somehow still alive despite the container being
fully gone (no processes).
In the past this has been caused by some problems in the
refcount/cleanup code for the network namespace. The inten
This is a kernel bug which sforshee has been working on. It should be
included in the next round of kernel updates.
** Package changed: lxc (Ubuntu) => linux (Ubuntu)
** Changed in: linux (Ubuntu)
Assignee: (unassigned) => Seth Forshee (sforshee)
--
You received this bug notification becau
Public bug reported:
19:06 < stgraber> apw: hey, so looks like powerpc (not 64el) isn't booting with
current 4.4 from xenial
19:06 < stgraber> apw: smoser may have some more details for you, all I know is
that I dist-upgraded my ppc VM and it stopped booting, smoser had to reboot me
into 3.19 m
** Package changed: linux (Ubuntu) => lxd (Ubuntu)
** Changed in: lxd (Ubuntu)
Assignee: (unassigned) => Stéphane Graber (stgraber)
** Changed in: lxd (Ubuntu)
Status: Incomplete => Fix Committed
--
You received this bug notification because you are a member of Kernel
Ok, so investigation shows that:
- LXD bind-mounts all that stuff, it doesn't have a choice as it's not
privileged enough to mount things itself
- mountall fails to run if its "optional" filesystems fail to mount (because
that makes a lot of sense...)
- systemd sets up the host filesystems, o
Oh and "lxc info" too for good measure (just in case lxd wasn't
restarted post-upgrade).
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1551854
Title:
LXD bootstrap issues on xenial
Sta
Please can everyone affected by this issue post the output of: dpkg -l
lxc liblxc1 lxd lxd-client lxcfs
It's very difficult to figure out what's wrong when we don't even know
the version being used.
** Changed in: linux (Ubuntu)
Status: Confirmed => Incomplete
--
You received this bug no
I'd like to note that LXD works differently from LXC here.
In LXC we mount debugfs through ubuntu.common.conf whereas with lxd, we
simply bind-mount /sys/kernel/debug from the host if it exists.
LXD doesn't use any of the /usr/share/lxc/* files. If it does on your
system, then you most definitely
** No longer affects: lxc
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1293549
Title:
Filesystem mount from lxc template causes filesystem permission
breakages
Status in juju-core:
Very much looks like it's related to threading and futexes somehow.
Forcing golang to use a single thread rather than one per container made
things more stable using a very simple test (infinite loop of "lxc
list"), though starting containers then still caused the hang to happen.
I've seen a simi
I unfortunately can't reproduce this on demand. I've had it happen to me
so far twice, both times immediately after resume, on two completely
different wifi networks, once on a mobile hotspot from my phone and
another time at a hotel in Brussels.
My best guess is that it's got to do with some netw
Public bug reported:
After resume, wifi doesn't come back up, all wifi related commands take
a long time before failing with input/output error.
Kernel log only seems to show some slowpaths being hit, but wifi sure
isn't working here...
ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: linux
Unloading and loading iwlmvm and iwlwifi did the trick to fix this.
Last time I had that issue, I attempted to reload iwlmvm, but not
iwlwifi too, maybe that made a difference this time.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to lin
** No longer affects: lxd (Ubuntu)
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-armadaxp in Ubuntu.
https://bugs.launchpad.net/bugs/1527374
Title:
privilege escalation on attach through ptrace
Status in linux package in Ubuntu
** Also affects: linux (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-lts-utopic in Ubuntu.
https://bugs.launchpad.net/bugs/1514785
Title:
kernel 3.16.0.52+53 - ip rule repeats
** Changed in: linux (Ubuntu Trusty)
Status: Triaged => Fix Released
** Changed in: linux (Ubuntu)
Status: Triaged => Fix Released
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/b
** Changed in: linux (Ubuntu)
Status: Confirmed => Fix Released
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1357588
Title:
3.13.0-24 broke nested unprivileged LXC
Status in li
** Changed in: linux (Ubuntu)
Status: Confirmed => Fix Released
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1384711
Title:
btrfs oops on current 3.13
Status in linux package i
** No longer affects: lxc (Ubuntu)
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1507463
Title:
OverlayFS: Wrong mnt_id and path reported in /proc in linux-3.13
Status in linux package
** No longer affects: lxc (Ubuntu)
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1480411
Title:
rm -r * fails to delete directories when using overlayfs in a user-
namespace
Status i
** Changed in: lxc (Ubuntu)
Status: Confirmed => Fix Released
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1471358
Title:
lxc-checkconfig shows Mainline PPA Wily-4.0.7 kernel mi
** No longer affects: lxc (Ubuntu)
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1402763
Title:
Multicast traffic not propating correctly over linux bridge
Status in juju-core:
Triag
root@precise-gui:/# ls -lh /proc/sys/net/ipv4/ip_local_port_range
-rw-r--r-- 1 nobody nogroup 0 Nov 9 12:53
/proc/sys/net/ipv4/ip_local_port_range
root@precise-gui:/# uname -a
Linux precise-gui 3.13.0-66-generic #108-Ubuntu SMP Wed Oct 7 15:20:27 UTC 2015
i686 i686 i386 GNU/Linux
So looks like
** Changed in: lxc (Ubuntu)
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1409425
Title:
lxc-start-ephemeral stops working with kernel 3.18
Hello Andy, or anyone else affected,
Accepted lxc into precise-proposed. The package will build now and be
available at https://launchpad.net/ubuntu/+source/lxc/0.7.5-3ubuntu70 in
a few hours, and then in the -proposed repository.
Please help us by testing this new package. See
https://wiki.ubun
What I don't get is why the other tests aren't failing too, they all
start containers too and so should hit the exact same failure. Why one
of the last tests is the one hanging just doesn't make sense to me.
Anyway, looks like there's a way for us to reproduce this and look into
it. It may well be
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1426618
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1404558
Title:
IPv6 related kernel panic following upgrade to 3.13.0-43
Statu
Public bug reported:
Hello,
Pretty similar to what happened with
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1404558 but this
time with the latest 3.13.0-46.
I've been getting about daily kernel panics (three times so far).
Screenshot attached. Another user also commented in bug 140455
I can confirm that something's broken with the recent kernel update...
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1404558
Title:
IPv6 related kernel panic following upgrade to 3.13.0
Let's file a new bug for that one.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1404558
Title:
IPv6 related kernel panic following upgrade to 3.13.0-43
Status in linux package in Ubun
Booted the new kernel and so far so good. Since there is no real
reproducer for this bug, I'll mark this as verification-done and will
come flip it back to verification-failed if the box panics by the time
you push this kernel to updates.
** Tags removed: verification-needed-trusty
** Tags added:
Still no panic after 48h, let's call it good.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1404558
Title:
IPv6 related kernel panic following upgrade to 3.13.0-43
Status in linux pack
Almost 24 hours and no kernel panic so far!
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1404558
Title:
IPv6 related kernel panic following upgrade to 3.13.0-43
Status in linux packag
Reproduced the panic with -44, same stack trace, screenshot attached.
Booting the machine back on -40 now.
** Attachment added: "Screenshot from 2015-01-05 16:40:16.png"
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1404558/+attachment/4292566/+files/Screenshot%20from%202015-01-05%2016%
Rebooted the Xeon E5-2620v2 system on linux-image-3.13.0-44-generic now.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1404558
Title:
IPv6 related kernel panic following upgrade to 3.13
I don't have a reproducer other than install the kernel and wait 24h as
that's how long it took for some systems to panic...
>From a very quick look, those kernels are mainline kernels,
unfortunately all my hosts are LXC hosts using unprivileged containers
with overlayfs, so I need kernels with th
** Changed in: linux (Ubuntu)
Status: Incomplete => Confirmed
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1404558
Title:
IPv6 related kernel panic following upgrade to 3.13.0-4
Might be worth mentioning that all affected hosts are x86 64bit Intel.
For those I've got access to, the issue happened on:
- 2x Xeon E3-1245v2
- 1x Xeon E5-2620v2
- 1x Atom C2750
- 1x Atom D2500
- 1x Core i5 750
All running on pretty standard Intel boards, so the usual set of Intel
chipsets
Public bug reported:
After updating a dozen machines from 3.13.0-40 to 3.13.0-43, they all
kernel panic within the next 24 hours.
I managed to pull the console from one over an IP KVM and it shows a panic
related to IPv6 networking:
https://dl.stgraber.org/panic-3.13-43.png
All affected machine
SCMP_CMP_MASKED_EQ should be used to restrict MNT_FORCE regardless of
what other mntflags are passed, though I'm failing to find the right
syntax for it...
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launc
So I came up with an alternate way around this which works for both
privileged and unprivileged containers and doesn't require an updated
apparmor. This uses seccomp to filter the umount2 call and return EACCES
when passed MNT_FORCE as second argument.
Code is at: http://paste.ubuntu.com/9568741/
Hmm, I can reproduce the exact same thing even without allow_other.
Sure, my user is getting permission denied if it attempts to read from
the fs, but it can still bind-mount it and then cause it to die by doing
a force unmount.
--
You received this bug notification because you are a member of K
Anything else that's special on that network, e.g. non-standard MTU?
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1402763
Title:
Multicast traffic not propating correctly over linux br
I don't have any good example in mind of fuse being used in that manner
(system wide user accessible filesystem) but if there was, this would be
a potential security issue against them. Once we figure out the root
cause of this and fix it, it may be worth considering this a security
fix.
--
You r
So the problem is that a force unmount of a bind-mount of a fuse
filesystem somehow gets the kernel to send the "destroy" command back to
the user space process running the filesystem. This behavior is clearly
wrong.
As an example, lets say that I'm running "lxcfs" as a fuse filesystem on
my syste
so I think it's some systemd handling which does that. LXC unshares the
mnt namespace which gets it a copy of the host's, then it's doing some
magic (rprivate I believe) to get things working under systemd, then
mounts what it needs, unmounts everything else and pivot_root.
lxc itself has no code
Public bug reported:
I recently noticed a bunch of containers failing in a rather odd way
when running postfix.
The most visible example is when running mailq on an empty queue.
Without apparmor (unconfined container) I see that the queue is empty,
with apparmor, I get Permission denied.
That's
Public bug reported:
So I just updated my home server to the 3.16 from the kernel team PPA
(3.16.0-23-generic #31-Ubuntu) and I'm now getting a ton of warnings
related to what looks like some kind of network hardware offloading.
A 10 minutes kernel.log sample is attached.
The server is a recent
I have since upgraded that server to the upcoming utopic backport (from
the kernel team PPA) and I haven't been able to reproduce this bug. So
it may well be that there are some btrfs bugfixes in 3.16 which haven't
made it to stable.
--
You received this bug notification because you are a member
Yes, this is 3.13 with btrfs on a single encrypted block device with
zlib compression.
The oops doesn't appear particularly armful now that I've turned off
panic_on_oops so it's not something I'm willing to sacrifice 2TB of free
space to workaround :)
--
You received this bug notification becaus
Public bug reported:
I've recently been getting a few kernel panics which I've tracked down
to having panic_on_oops set to 1 and which appear to be related to this
oops:
[ 2182.341680] general protection fault: [#1] SMP
[ 2182.341702] Modules linked in: xt_CHECKSUM esp6 xfrm6_mode_transport
root@qdisc:~# tc qdisc add dev eth0 root netem delay 50ms
root@qdisc:~# ping 10.0.3.1
PING 10.0.3.1 (10.0.3.1) 56(84) bytes of data.
64 bytes from 10.0.3.1: icmp_seq=1 ttl=64 time=50.3 ms
64 bytes from 10.0.3.1: icmp_seq=2 ttl=64 time=50.3 ms
^C
--- 10.0.3.1 ping statistics ---
2 packets transmitte
Public bug reported:
The recent security update kernel broke nested unprivileged LXC containers as
those attempt to do the following:
access("/usr/lib/x86_64-linux-gnu/lxc/dev/console", F_OK) = 0
mount("/dev/console", "/usr/lib/x86_64-linux-gnu/lxc/dev/console",
0x7fff406cd9e9, MS_BIND, NULL) =
101 - 200 of 261 matches
Mail list logo
