@IBM - overall that means, please test from proposed:
libvirt 4.6.0-2ubuntu3.1 + qemu 1:2.12+dfsg-3ubuntu8.2 on 18.10
libvirt 4.0.0-1ubuntu8.6 + qemu 1:2.11+dfsg-1ubuntu7.9 on 18.04
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in
Done in Chrony and setting to Won't Fix (to manage expectations) for NTP
as it is universe only and if people care they can drop in networkd-
dispatcher files to get it working (open for community contribution, but
main will rely on chrony).
** Changed in: ntp (Ubuntu)
Status: Triaged => Wo
** Package changed: kvm (Ubuntu) => linux (Ubuntu)
** Changed in: linux (Ubuntu)
Status: Triaged => New
--
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/1782212
Title:
KVM CLX ACPI
Verified Bionic with the libvirt+qemu setup outlined in comment #66
Guest starting fine and in the guest:
$ lszcrypt
CARD.DOMAIN TYPE MODESTATUS REQUEST_CNT
-
00 CEX5C CCA-Coproc online1
00.0016 CEX5C CCA-Coproc
Did cosmic as well now.
First verified that with the non-proposed version it fails (on
1:2.12+dfsg-3ubuntu8.1 / 4.6.0-2ubuntu3)
=> fails as expected (can't even define the XML)
Then upgraded to 1:2.12+dfsg-3ubuntu8.2 and 4.6.0-2ubuntu3.1 from cosmic
proposed.
With that qemu works as intended and
Looking back I'm afraid comment #59 was not testing "all" releases when
it said "I successfully tested on s390 the provided libvirt packages as
requested in point 4 of paelzer last comment".
There really is more than just the latest LTS :-)
Now lets find the patch that makes it stop adding that si
Seems to me like:
4.7 d6f97d13 "qemu: mdev: Use vfio-pci 'display' property only with vfio-pci
mdevs"
Related:
4.6 d48813e8 conf: Introduce new video type 'none'
4.6 c0ca6dcf qemu: command: Enable formatting vfio-pci.display option onto
cmdline
4.6 d54e45b6 conf: Introduce new attribute 'displa
Respins with that fix on top build now for Bionic and Disco in the PPA [1]
(same we used so far).
Lets see if they build and work as expected ...
[1]: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3520
--
You received this bug notification because you are a member of Kernel
Packag
Tested 4.6.0-2ubuntu3.2~ppa1 from the PPA.
I can now add
without getting display='off' added
- no new/different related apparmor issues
- starting the guest works fine
- generated qemu line LGTM
-device
vfio-ap,id=hostdev0,sysfsdev=/sys/bus/mdev/devices/24f952
I'm glad that the ipxe in the PPA seems to make it work.
I now read the discussions and all questions that came up for me while
doing so were asked and clarified already in later comments.
Therefore I just reviewed the proposed change and it looks good to me
(other than the version string but tha
> Unfortunately, a modern MAAS no longer uses iSCSI; it will fetch all
> necessary data over HTTP.
Yeah that matches what I heard, used in the past but no more.
But you certainly still have the best knowledge how to set it up from
the past when it did.
Checking that pre/post an upgrade to that PPA
Hi Jose, I'm puzzled that you update that series here. AFAIK per
discussions this project will run it's own custom qemu, so for I'm not
considering the backports for the main Archive (for everybody).
** Changed in: qemu (Ubuntu Bionic)
Status: New => Won't Fix
** Changed in: qemu (Ubuntu)
As Ryan I can not reproduce locally - hrm.
The crash in your log is the root-fs mount.
[ 22.524541] VFS: Cannot open root device
"squash:http://172.16.99.2:5248/images/ubuntu/amd64/generic/bion"; or
unknown-block(0,0): error -6
[ 22.575588] Please append a correct "root=" boot option; here
After DHCP is up it works just fine.
(initramfs) wget http://192.168.122.1:80/squashfs
Connecting to 192.168.122.1:80 (192.168.122.1:80)
squashfs 100% |***| 174M 0:00:00 ETA
(initramfs) mount -t squashfs squashfs /root
(initramfs) mount
rootfs on / type r
Working on this I found by accident that I actually can reproduce:
VFS: Cannot open root device "squash:http://192.168.122.1:80/squashfs"; or
unknown-block(0,0): error -6
But the way I got there lets assume some more potential reasons.
I got there by breaking my initramfs :-)
After realizing t
Repro crash with the case - still triggering
Installed 32bit Test kernel
It boots this one:
Linux 4.15.0-36-generic #40 SMP Fri Oct 12 00:17:54 UTC 2018
Seems to have no "special" version suffix to identify it other than #40 and
build time.
But #40 and the build time indicate this is the provid
Since it is reproducible maybe not a networking hiccup.
But maybe a hiccup of the PXE setup (thats why I asked for it).
Or a hiccup of the quite complex shim loading if signed kernels are used.
@Mike - in addition to my questions above could you use a non
signed/shim load pattern as well to check
I must admit, compared to you just sharing your kernel/initrd/squash asking to
install an own dev maas in comment #23 consumes quite some time :-/
Waiting for a sync here, setting up users there, sorting out how to make us
provide PXE and such on the "maas" virtual network, ... - it just isn't on
I didn't see any guests crashing, instead they all just hang finding
nothing to boot.
I reduced this to just qemu (for debugging later on) but it reliably
breaks finding nothing from PXE.
Guest Console:
iPXE (PCI 00:03.0) starting execution...ok
iPXE initialising devices...ok
iPXE 1.0.0+git
I didn't let me calm down - I found in the doc [1] that the switch might
be on the VLAN and not the subnet (Hrm why?)
It was on the vlan
http://horsea:5240/MAAS/#/vlan/5021
Not on the subnet
http://horsea:5240/MAAS/#/subnet/11
There I found the "provide dhcp" entry \o/
That unlocked some understa
Taking the x86 pxelinux.0 from /usr/lib/PXELINUX/pxelinux.0 and
otherwise doing the same tftp setup as in [1] and switching from the
"maas" to the "default" network where I have set up dhcp to netboot by
libvirt as in [1]. I can see netboot happening.
With that instead of pushing things from libvi
There actually is no need to debug further on my non-maas PXE setup.
As identified before - your setup breaks due to
[ 20.690329] Initramfs unpacking failed: junk in compressed archive
Everything else is a follow on issue, with eventually:
[ 22.524541] VFS: Cannot open root device
"squash:http://
Hi,
thanks for your feedback.
We are at least much closer to what happened and thereby should be faster if it
reoccurs.
I don't think it is an interaction of the Kernel and Squashfs as we found that
already initramfs unpack was broken. That is before Squash comes into play.
I'll keep my test set
** Description changed:
---Problem Description---
When running stress test, sometimes seeing IO hung in dmesg or seeing "Host
adapter abort request" error.
-
+
---Steps to Reproduce---
- There are two ways to re-create the issues:
+ There are two ways to re-create the issues:
(1)run
I discussed some background with the Kernel Developers today.
Due to that I sanitized the description a bit to make it clear in the first few
lines that this is not only a 4.10 kernel issue.
On a side note I had to smile as there is LTC LTC22393 (long ago) that had Suse
switch to deadline on s39
I agree that adding a dependency and pulling in python2 from the kernel
seems very wrong.
Per https://www.python.org/dev/peps/pep-0394/#recommendation I think the right
header would be
#!/usr/bin/env python3
That would be a (trivial) upstream change to the kernel as code is held there.
Unless
I'm seeing this as well in 18.10 with an Apple MagicTouch 1 bluetooth connected
to an Asus laptop.
It disconnects every few minutes of use and then reconnects after about 30sec.
Oct 28 09:37:39 marconi bluetoothd[979]: Can't get HIDP connection info
Oct 28 09:37:41 marconi kernel: [48771.558941]
I did just figure out that it locks up many seconds before the "unknown
main item tag 0x0" shows up in the log. That may be an artifact of the
error recovery and not indicating the original problem.
--
You received this bug notification because you are a member of Kernel
Packages, which is subsc
** Tags added: libvirt-19.04 qemu-19.04
--
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/1787405
Title:
[19.04 FEAT] Guest-dedicated Crypto Adapters
Status in Ubuntu on IBM z Systems:
T
/*
* Device creation by udev is asynchronous and waiting may be
* required. Busy wait for 10ms and then fall back to polling every
* 10ms for the allowed timeout (default 10s, max 10m). This is
* done to optimize for the common case where the device is
* immediately available and to avoid pena
On Mon, Apr 30, 2018, 12:41 Ryan Harper <1760...@bugs.launchpad.net>
wrote:
> On Mon, Apr 30, 2018 at 12:14 PM, Colin Ian King
> <1760...@bugs.launchpad.net> wrote:
> > The code actually polls /dev/zfs until it appears. The issue here is
> > that it does not appear after 10 seconds, and then it gi
If you're running zfs tools in a container setting the timeout to 0 will
likely be helpful. The device node will never appear in the containers /dev
since a) it's a tmpfs and b) even if it were a devtmpfs it wouldn't help
since devtmpfs isn't namespaced. (In fact udevd will even ignore any device
e
Debugging per [1], did not show anything new.
There just is no activity on the actual access of /home all I see is the
trigger for /home registering at startup.
Startup:
ubuntu@xenial-autofs-client:/$ sudo automount -f -v --debug
Starting automounter version 5.1.1, master map /etc/auto.master
usi
In the kernel
$ git log -p v4.4...v4.15 -- fs/autofs4
has a bunch of fixes, but none is clearly matching the case here just by
reading it.
Therefore I'll leave that evaluation to the kernel Team.
@Jason I hope that you can just use HWE kernels and be happy for now
since those seem to work for yo
I added a Bionic task since you asked for a Bionic verification
** Also affects: autofs (Ubuntu Bionic)
Importance: Undecided
Status: New
** Also affects: linux (Ubuntu Bionic)
Importance: Undecided
Status: New
** Changed in: linux (Ubuntu Bionic)
Status: New => Fix Co
In the proposed build [1] I see
-rw-r--r-- root/root 74830 2019-04-25 08:40
./lib/modules/4.15.0-49-generic/kernel/fs/autofs4/autofs4.ko
As part of:
linux-modules-4.15.0-49-generic_4.15.0-49.53_amd64.deb
That is what we wanted/needed.
Setting verification-done for Bionic.
[1]: https://launc
Hi,
I have not seen the kernel changes in 5.2 RCs - is there an update on their
progress?
Also any updates, links, commits on the related qemu contribution?
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.lau
The qemu commits have landed in 4.0 - so that part should work in Ubuntu
19.10
The kernel commits are in 5.1 as outlined by Paul above already (thanks).
@Paul - since the initial upstream target was "linux 5.3" are there things
missing or did this just work out faster than expected?
--
You rece
Again, this semes to be a Kernel/qemu bug that was only filed against xen.
Added bug tasks to not get lost.
** Also affects: qemu (Ubuntu)
Importance: Undecided
Status: New
** Also affects: linux (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notificatio
This is another bug filed against xen, but then mentioning qemu and kernel.
There was no feedback since my question a few months ago, but xen as the only
target package makes no sense it seems.
I added bug tasks accordingly.
** Also affects: qemu (Ubuntu)
Importance: Undecided
Status:
Are there updates and/or references to commits in those projects already
that we can use to track and integrate those features?
--
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/1782208
Title
@Quanxian - as usual let us know when you have mailing list posts or
even better commits in the kernel and qemu that we can use to track and
integrate this.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.laun
Feature request that does not need the kernel logs the bot asks for
** 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/1782
Feature request that does not need the kernel logs the bot asks for
** 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/1782
I have not seen/triggered the kernel issue mentioned in here (identified by
jdstrand).
But on request I'll try it at least.
Testing on Disco with Host Having:
5.0.0-13-generic
# Create container and trigger the issue:
lxc launch ubuntu-daily:d d-testapparmor
# update the container to not have th
Ordering was important:
$ modprobe shiftfs
$ sudo snap set lxd shiftfs.enable=true
$ sudo systemctl restart snap.lxd.daemon
Now it is enabled:
$ lxc info | grep shiftfs
shiftfs: "true"
$ lxc exec d-te
Thanks Tobias for the advise, adding a kernel Task to pull in the kernel
team as well (confirmed to stop the bot from asking for logs).
@bugproxy:
"configure the encryption with aes128gcm8 for IPsec" can probably be done in
more than one way. To avoid wasting effort could you just provide the con
Public bug reported:
Unprivileged users can already toggle whether a subvolume will be ro or
rw. Not having this working with shiftfs regresses various use-cases.
Issues have already been seen by Stéphane Graber (Cced here).
To enable this with shiftfs we need to whitelist BTRFS_IOC_FS_INFO,
BTRFS
@sfeole Thanks for the Dup hit that as well now - as all others I ask
you to please help to catch the data needed to finally recreate and
debug this.
>From IRC:
[07:00] sfeole: please attach your guest XML, and the used initrd
and kernel to the bug
[07:02] best would be also the pxeconfig that
Added to the description what we need from anyone affected.
@Maas Team see former comment for the requested guiding of users how to get
this data.
The Maas task is back from incomplete to confirmed for providing these howto's
** Changed in: maas
Status: Incomplete => Confirmed
--
You re
So I guess we should then file the bug against nvidia-driver-430 then?
** Also affects: nvidia-graphics-drivers-418 (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to nvidia-graphics-drive
Since 430 is still from a PPA https://launchpad.net/~graphics-
drivers/+archive/ubuntu/ I used 418 being the closest one.
Do you hit the same with 418?
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to nvidia-graphics-drivers-418 in Ubuntu.
The top three qemu patches are in qemu 4.0 which we plan as minimum for Ubuntu
19.10.
Tagging up to be part of the Qemu work in Ubuntu 19.10.
The rest of the qemu patches is already in qemu 3.1 which is in Ubuntu
19.04
** Tags added: qemu-19.10
** Changed in: qemu (Ubuntu)
Status: Confir
Sure you mean Disco and not Eoan?
... checking
--
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/1826410
Title:
Please package libbpf (which is done out of the kernel src) in Debian
[for
Hmm,
no libbpf-dev package in any -proposed just yet.
Neither die I find it in a new queue?
The one place I found it is in:
* Please package libbpf (which is done out of the kernel src) in Debian [for
19.10] (LP: #1826410)
- SAUCE: tools -- fix add ability to disable libbfd
of https://l
After some discussion, probably just a bad bug ref in changelog?
** Tags removed: verification-needed-disco
** Tags added: verification-failed-disco
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.n
TL;DR only occurs with HWE kernel - odd
Results of:
$ cat /sys/devices/system/cpu/vulnerabilities/mds
Host Bionic: 4.18.0-20-generic / 2.11+dfsg-1ubuntu7.13
Guest-lvl1: 3.13.0-170-generic / 2.0.0+dfsg-2ubuntu1.46
Vulnerable: Clear CPU buffers attempted, SMT Host state unknown
Guest-lvl2: 3.13.
E.g. in /proc/cpuinfo the whole section is missing:
bugs: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf
mds
^^ this is not there when "Not affected" is reported
Separating kernels:
3.13 on both: Works
4.4 on lvl1, 3.13 on lvl2: Fail
3.13 on lvl1, 4.4 on lvl2: Works
So i
Note: support on nested is and always was "best effort" as it is
famously known to work great until it doesn't. Recently upstreams stance
on this changed and in the last few versions nested x86 got some love
(due to some big players using it now), but I'm more looking to 20.04
than anything before
Further I realized that I can trigger this with T3.13/Q2.5/B4.15:
trusty-lvl1-mitaka kernel: [ 931.946357] kvm [2356]: vcpu0 unhandled rdmsr:
0x140
trusty-lvl1-mitaka kernel: [ 932.236914] kvm [2356]: vcpu0 unhandled rdmsr:
0x1c9
trusty-lvl1-mitaka kernel: [ 932.238337] kvm [2356]: vcpu0 unha
oO :-/, that crash also happens to the older qemu on trusty as soon as
you have more than 1 lvl1 or lvl2 guest it seems. Anyway - same
workaround to tets MDS applies
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://
Of course I spoke too soon, on T3.13/Q2.0/B4.15 I now hit an FPU issue.
That builds up to a kernel stack crash (recursive)
[2.394255] Bad FPU state detected at fpu__clear+0x6b/0xd0, reinitializing
FPU registers.
[...]
BUG: stack guard page was hit at (ptrval) (stack is (ptrval
Hmm with that workaround for 4.15 I get the md bug affects in the guest,
but not the md-clear feature.
$ uname -r; cat /sys/devices/system/cpu/vulnerabilities/mds; cat /proc/cpuinfo
| grep -e ^bug -e ^flags | grep md
4.15.0-50-generic
Vulnerable: Clear CPU buffers attempted, no microcode; SMT Hos
I re-checked all that you and I found, lets write a List with all that
we know if there are patterns.
Host (should not matter, but be rather new) - in my case B4.18 Q2.11
For new qemu I'm using Mitaka.
In this case being from
https://launchpad.net/~ubuntu-cloud-archive/+archive/ubuntu/mitaka-sta
My initial testcase will be 07 "T4.4 / Q2.0 T3.13"
Bisect is rather complex as we'd need the md-clear patches on top at each step.
Sorry that it took a while.
Adaptions:
- non ubuntu machine type (using 2.0 to work on all builds)
- remove VNC in xml as we built a reduced feature qemu
- place buil
Bisect result is
git bisect start
# good: [a9e8aeb3755bccb7b51174adcf4a3fc427e0d147] Update version for v2.0.0
release
git bisect good a9e8aeb3755bccb7b51174adcf4a3fc427e0d147
# bad: [a8c40fa2d667e585382080db36ac44e216b37a1c] Update version for v2.5.0
release
git bisect bad a8c40fa2d667e58538208
That finds us the fix as:
commit 120eee7d1fdb2eba15766cfff7b9bcdc902690b4
Author: Eduardo Habkost
Date: Tue Jun 17 17:31:53 2014 -0300
target-i386: Set migratable=yes by default on "host" CPU mooel
Having only migratable flags reported by default on the "host" CPU model
is saf
Theory given what we know so far:
- only fails if LVL1 is at 4.4
- not failing if LVL1 is at 3.13
- 4.4 might have more CPU features
- qemu 2.0 when using host-model is passing ALL features
- qemu 2.5 works, but we now know it filters some flags that 2.0 doesn't
=> one of these extra flags disturbs
Public bug reported:
Hello everybody. this is the first time i report a issue here. Sorry my
broken english :)
Recently i bought a a Acer Aspire A715-71G-54LH with NVIDIA graphic
card, by default after installation it runs nouveau driver. The graphics
looks fine but suddently strange things start
this log was when computer runs nouveau driver, after changing it to
nvidia propietary then everythings starts working fine.
** Attachment added: "this is the full journal log when nvdia driver was active
and causing the bad behavior."
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1779
** 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/1779678
Title:
deadlocks in copy_net_ns
Status in linux package in Ub
I've been running a 4.18 kernel for a long time now and I haven't been
able to reproduce the bug. Please note however, that this bug was a
race. Meaning, it is easily possible that the race has just gotten so
unlikely that it doesn't matter anymore. I doubt it however, since a)
there's a proper exp
://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1575779
[2]: https://github.com/systemd/systemd/issues/9493
Thanks!
Christian
** Affects: linux (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Kernel
Packages, which is
tchset is available here:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=80a17a5f501ea048d86f81d629c94062b76610d4
[1]: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1575779
[2]: https://github.com/systemd/systemd/issues/9493
Thanks!
Christi
git/commit/?id=80a17a5f501ea048d86f81d629c94062b76610d4
[1]: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1575779
[2]: https://github.com/systemd/systemd/issues/9493
Thanks!
Christian
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1780227/+subscriptions
--
Since at the time the problem occurs this is just host kernel/modules
behaving not as they should I'll move that over to the kernel.
You might want to share what kernel/modules you have, but until then
I'll just assume the default of 18.04.
** Package changed: qemu-kvm (Ubuntu) => linux (Ubuntu)
Trying to recreate this, I have a xhci Host controller (no extra card, but as
part of the chipset).
00:14.0 USB controller: Intel Corporation C610/X99 series chipset USB xHCI
Host Controller (rev 05)
00:14.0 USB controller: Intel Corporation C610/X99 series chipset USB xHCI Host
Controller (r
Hi John,
so you got the forwarding working, but then couldn't use it in the guest - sad
to hear after all the effort you did :-/
And to confirm: now you are trying to revert the to the former normal setup and
just forward e.g. the USB devices itself.
I agree - all the settings in /sys about unbi
"I try to steer clear of Windows wherever possible and therefore does
not know too much on what to expect when I am faced with a situation
where I have to look deeper"
Applies to me as well in this case, but LMGTFY would solve it, first hit
https://superuser.com/questions/1106247/how-can-i-get-the
ance: Undecided
Assignee: Christian Brauner (cbrauner)
Status: In Progress
** Changed in: linux (Ubuntu)
Assignee: (unassigned) => Christian Brauner (cbrauner)
** Changed in: linux (Ubuntu)
Status: New => In Progress
** Description changed:
- We currently keep a referenc
** Changed in: linux (Ubuntu)
Assignee: (unassigned) => Christian Brauner (cbrauner)
--
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/1824719
Title:
[shiftfs] Allow stack
** Summary changed:
- [shiftfs] Allow stacking overlayfs on top
+ shiftfs: Allow stacking overlayfs on top
--
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/1824719
Title:
shiftfs: Allow s
Thank you Timo!
--
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/1795857
Title:
enable CONFIG_DRM_BOCHS
Status in kmod package in Ubuntu:
Fix Released
Status in linux package in Ubuntu:
** Description changed:
SRU Justification
-
Impact: We currently keep a reference to the shiftfs mark mount's
shiftfs_super_info which was stashed in the superblock of the mark mount. The
problem is that we only take a reference to the mount of the underlay, i.e. the
filesystem that is
** Description changed:
SRU Justification
Impact: We currently keep a reference to the shiftfs mark mount's
shiftfs_super_info which was stashed in the superblock of the mark mount. The
problem is that we only take a reference to the mount of the underlay, i.e. the
filesystem that is *u
** Description changed:
SRU Justification
Impact: We currently keep a reference to the shiftfs mark mount's
shiftfs_super_info which was stashed in the superblock of the mark mount. The
problem is that we only take a reference to the mount of the underlay, i.e. the
filesystem that is *u
** Changed in: linux (Ubuntu)
Status: In Progress => 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/1824735
Title:
shiftfs: use after free when checking mount option
Okay, I have a fix for the shiftfs side I think. Attached here.
** Patch added: "UBUNTU: SAUCE: shiftfs: use correct llseek method for"
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1824812/+attachment/5256074/+files/0001-UBUNTU-SAUCE-shiftfs-use-correct-llseek-method-for-d.patch
--
@Dmitrii - we were at the "junk in ..." in comment #21 already.
The "broken padding" is interesting but might be the same issue with a
different message as the newer kernel understands slightly more about it.
That it does only occur with Xenial-HWE but on the same initrd not with
the base Xenial
Ran with:
- the cloud-image of Xenial of 20190419 [1]
- XML with a memory definition of:
2097152
2097152
- kernel&initrd are from the host
/var/lib/libvirt/images/bug-1797581-bionic-base
/var/lib/libvirt/images/bug-1797581-bad-initrd
- The attached broken initrd of comment #56
- Otherwise
Fro experimenting with sizes things can easily be padded with zeros:
$ truncate -s 8000 bug-1797581-bad-initrd-extended
$ truncate -s 900 bug-1797581-xenial-base-extended
Boots just as well afterwards.
--
You received this bug notification because you are a member of Kernel
Packages, whi
After a longer session on IRC this is now also for Dmitrii un-reproducible.
Lets summarize the current status for the next oen coming by:
Current ideas still are:
a) at 2G the placement of kernel/initrd is too close (as placed by pxelinux),
then when the kernel unpacks it overwrites the initrd
b)
Public bug reported:
Hi,
Debian packages libbpf and so far does so out of the kernel source [1].
There is some movement to separate that from the kernel source [2] but this
isn't ready yet. So far it is just a sync of the subtree out of the kernel
sources.
Since we do not share our kernel packa
apport-collect makes no sense for this which is more a feature/packaging
request, setting confirmed
** 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.
http
ubuntu@cosmic-autofs:~$ find /lib/modules -name '*autofs4*'
ubuntu@cosmic-autofs:~$ modinfo autofs4
modinfo: ERROR: Module autofs4 not found.
Installed linux-headers-4.18.0-19 from proposed
ubuntu@cosmic-autofs:~$ find /lib/modules -name '*autofs4*'
/lib/modules/4.18.0-19-generic/kernel/fs/autofs
After upgrade:
$ find /lib/modules -name '*autofs4*'
/lib/modules/5.0.0-14-generic/kernel/fs/autofs/autofs4.ko
That was missing before -> verified
** Tags removed: verification-needed-disco
** Tags added: verification-done-disco
--
You received this bug notification because you are a member of
** Description changed:
Hi,
Debian packages libbpf and so far does so out of the kernel source [1].
There is some movement to separate that from the kernel source [2] but this
isn't ready yet. So far it is just a sync of the subtree out of the kernel
sources.
Since we do not share our
s it possible to have
one?
I quickly attempted to have root do the shiftfs mounts for the users, but it
seems the shift is always for the root of the current userns, and can't be done
for another user."
** Affects: linux (Ubuntu)
Importance: Undecided
Assignee: Ch
** Patch added:
"0001-UBUNTU-SAUCE-shiftfs-lock-down-certain-superblock-fl.patch"
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1827122/+attachment/5260369/+files/0001-UBUNTU-SAUCE-shiftfs-lock-down-certain-superblock-fl.patch
--
You received this bug notification because you are a me
FYI here the package info from buster as of today
root@d10-buster:~# apt-cache show libbpf-dev libbpf4.19
Package: libbpf-dev
Source: linux
Version: 4.19.28-2
Installed-Size: 350
Maintainer: Debian Kernel Team
Architecture: amd64
Depends: libbpf4.19 (= 4.19.28-2)
Description-en: eBPF helper librar
101 - 200 of 1081 matches
Mail list logo
