** Changed in: linux (Ubuntu)
Status: Expired => Fix Released
** 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.
Per [1] this symbol is present in: firejail, elogind, valgrind, glibc,
musl, linux, systemd, strace, stress-ng, libseccomp, qemu
At least for qemu I checked and those are only references in the
embedded linux headers. No rebuild needed for that, most of the others
seem safe as well - maybe someone
It is yet unclear if there is an issue in the userspace tools, hence I
made the sibling bug a dup and added the tools as a task here marked as
incomplete for now.
As I mentioned providing the extra kernel data might help to get the
triaging by the kernel team started.
** Also affects: bcache-tool
@rafael - One more question about Stepping 5/6.
I have formerly read your explanation that stepping 6 would be
required to be able to enable arch_capabilities.
And we planned to add all SRUs with stepping 6 right away and keep the
Delta to consider all versions to be stepping 6.
But then I have se
> ssbd
> md-clear
> bpb
> ibrs-all
> rdctl-no
> rsba
> skip-l1dfl-vmentry
>
> I guess that we will have to backport this support in libvirt, in order
> to allow QEMU to pick specific CPU mitigation flags.
Those are not all missing at least. I have seen ssbd and md-clear for
sure in Bionic e.g. for
Thanks Kellen,
I took your kernel/initrd and IPXE booted it fine via http from qemu's IPXE on
a 2G guest.
In the past we tried more (use squash, use tftp instead of http, use the same
parmlines as maas, ...), but it all comes down to the same thing every time -
only occurs inside Maas.
Therefor
@rafaeldtinoco: I found some forther more ugly detail for the stepping change
from 5 to 6.
Qemu 3.1 as in Disco had Cascade lake with the stepping 5.
So for Disco the SRU will change the definition.
Which is different to Bionic/Cosmic where we can say "our Cascade definition
will just always have
This also affects "Cascadelake-Server" defined guests migrating from
patched Bionic to unpatched Disco - that will fail. But requiring
updates being applied is fine, only the enforced guest restart (which
doesn't apply to the just mentioned use-case) is the thing that is
really bad.
Overall maybe
Hi pragyansri,
If you track the progress on the merge proposal that is linked this looks good
atm and will soon be in a PPA [2] with proposed changes for pre-evaluation with
Bionic/Cosmic/Disco/Eoan.
>From there the next steps are:
- test the new feature from the PPA on cascade lake machines
- g
Yeah, it seems to only occur with the TFTP setup that maas creates - and in all
former cases it resolved a few days later - most likely by size of images
changing.
That is the reason we need the files from an affected case.
@Reto - please see in the bug description above, there is a section "If
Sent patch:
https://lists.ubuntu.com/archives/kernel-team/2019-June/101305.html
--
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/1832316
Title:
shiftfs: allow changing ro/rw for subvolumes
** Changed in: linux (Ubuntu)
Status: Incomplete => Confirmed
** Changed in: linux (Ubuntu)
Status: Confirmed => In Progress
** Changed in: linux (Ubuntu)
Assignee: (unassigned) => Christian Brauner (cbrauner)
--
You received this bug notification because you are a
FYI things resurfaced with monitors of higher resolution.
But it was so bad that I sent them back, so no testbed available atm.
--
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/1823618
Title
Public bug reported:
SRU Justification
Impact: Stéphane reported regression for btrfs workloads employing shiftfs.
Unprivileged users can already toggle whether a subvolume will be ro or
rw. This is broken on current shiftfs as we haven't whitelisted these
ioctls().
Fix: To enable this with shif
See
https://git.launchpad.net/~cbrauner/ubuntu/+source/linux/+git/disco/log/?h=2019-05-07/shiftfs_btrfs_ioctls
--
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/1832316
Title:
shiftfs: allo
** Tags added: qemu-19.10
--
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/1812822
Title:
Guest crashed when detaching the ovs interface device
Status in Ubuntu on IBM z Systems:
Incomp
Hi Sean,
for >1TB due to the defaults being for safety you need to set a different
machine type.
The suffix is "-hpb" like "pc-i440fx-bionic-hpb" in your case.
I have written about it here:
https://cpaelzer.github.io/blogs/005-guests-bigger-than-1tb/
Changing the default is an upstream decisio
Now that this is released, can we set it back to open again to reflect
the real state in the archive?
--
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
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
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
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
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
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
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
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
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://
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
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
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
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.
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
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
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
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
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.
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
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
@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
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
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
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
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
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
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
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:
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
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
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
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
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 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
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
Since this works (using disable_radix thanks leonardo) in Cosmic and
also through the HWE kernel on Bionic I think there is no more work
needed. The trigger was P9 HW which is fine for this specific (and
uncommon) function to define the HWE kernel as requirement.
** Changed in: qemu (Ubuntu Cosmic
>From our IRC discussion who might work on it (as it is yet untriaged):
[09:50] cpaelzer, there was a tendency to do things like debian does. It
is on apw's list, however that is an ever changing territory
[09:52] if that is the case that is fine, could you or apw tell me
that on the bug and i
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
** 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
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
** 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
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
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
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
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
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)
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
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
@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
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
--
** 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
** 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
** 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
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:
** 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
** 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
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
Hi Robert,
I haven't found the reason.
For my limited kernel knowledge I have checked and discussed a bit.
in [1] I found
$ grep -Hrn autofs debian.master/contro*
debian.master/control.d/generic.inclusion-list:181:fs/autofs4/autofs4.ko
But then was made aware that with 4.18 ther kernel started to
@Timo - Ack, this should be enabled again. And if really still an issue
for PPC then a different solution than to disable it should be evaluated
(can we do arch specific blakclisting?).
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux
This is in all newer versions of iproute2 (newer than Xenial), setting
the general task to Fix Released
** Changed in: iproute2 (Ubuntu)
Status: Invalid => Fix Released
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to iproute2 in Ub
As usual - thanks bug - with a proper ssh set up and logged in it just doesn't
trigger anymore :-/
I tried multiple reboots and we can keep the bug if others are affected to join
forces, but for now it is incomplete as I can no more reproduce it :-/
** Changed in: linux-hwe (Ubuntu Bionic)
We discussed if just the Graphics output might be dead, I'll set up SSH
and try to retrigger.
** Description changed:
On 2019-04-03 I updated to the latest linux-image-generic-
hwe-18.04:amd64 and then I got on a trip where things worked fine at
first. Back home I realized that the new vers
** Description changed:
On 2019-04-03 I updated to the latest linux-image-generic-
hwe-18.04:amd64 and then I got on a trip where things worked fine at
first. Back home I realized that the new version 4.18.0-17-generic has
issues initializing gnome with multiple monitors.
Steps to rep
** Attachment added: "lspci.log"
https://bugs.launchpad.net/ubuntu/+source/linux-hwe/+bug/1823618/+attachment/5254001/+files/lspci.log
--
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/182
Apport still refuses to attach data :-/
But I since I have the journal with the crash attached that should be ok.
** Changed in: linux-hwe (Ubuntu Bionic)
Status: New => Confirmed
** Changed in: linux (Ubuntu Bionic)
Status: New => Confirmed
** Changed in: linux-hwe (Ubuntu)
Setting linux-hwe per discussion
** Package changed: linux-signed-hwe (Ubuntu) => linux-hwe (Ubuntu)
** Also affects: linux (Ubuntu Bionic)
Importance: Undecided
Status: New
** Also affects: linux-hwe (Ubuntu Bionic)
Importance: Undecided
Status: New
** Changed in: linux (Ub
** Attachment added: "dmidecode.log"
https://bugs.launchpad.net/ubuntu/+source/linux-hwe/+bug/1823618/+attachment/5254000/+files/dmidecode.log
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/
Confirmed to silence the bot, attaching a few logs on my own since
apport refuses to do so
--
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/1823618
Title:
4.18.0-17 crashes on i915 driver
Apport seems to collect and send stuff, but it does not show up here - I'll
stop hitting send for now to not have 50 attachments in 10 minutes :-/
Just let me know what you need and I'll make it available.
--
You received this bug notification because you are a member of Kernel
Packages, which i
I was unsure which package to file it against as it is hwe, please feel
free to adapt the bug tasks accordingly.
--
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/1823618
Title:
4.18.0-17 c
FYI: The system becomes unresponsive after the crash so I can only
report the bug while rebooted into the former HWE kernel version.
--
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/1823618
** Attachment added: "journal of the boot including the crash"
https://bugs.launchpad.net/ubuntu/+source/linux-signed-hwe/+bug/1823618/+attachment/5253943/+files/GPU-crash.1.log
** Also affects: linux (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification
Thanks cascardo for testing power8 already.
This came up in bug 1823152 as well and made me aware of this.
If qemu is not run in commandline most frontends set something else than "-vga
std" therefore I wasn't aware. But I can confirm seeing the issue.
I think I can test x86 quite easily, is the
See lightdm and gpu-manager services in
http://paste.ubuntu.com/p/5QyzgMKhmr/ for an example how that looks like
from a guests POV.
--
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
T
After a weekend using the wireless (on Bionic) I have got no new
"kernel: iwlwifi :04:00.0: Microcode SW error detected. Restarting
0x200."
entries and I'm still connected (also before it hit really fast).
Therefore I'd think this firmware in proposed is as good as the PPA I used int
h
@Jarek: Thank you for sharing the workaround, it also works for me 100%
of the time!
I tried the 5.0.1 Kernel with the patches - in the beginning I was
hopeful because the touchpad and trackpoint survived a few sleep/wakeup
cycles, but starting from day 2 the issues returned (sometimes the
touchpa
I have had no issues anymore since I switched to my self built
1.177~ppa0f22c85 (PPA) - while before they were rather common.
Thanks for accepting that into Bionic-Proposed.
I have switched to 1.173.5 from Proposed and unplugged the cables.
The install (a downgrade for me as outlined) itself work
src:linux-firmware is only accepted into cosmic-proposed but still waiting in
Bionic-unapproved.
AFAIK the current status of "Fix committed" will make it not to be seen by the
SRU Team (at least for similar cases I had in the past).
Therefore to increase the chance to get also the Bionic portion
*** This bug is a duplicate of bug 1808389 ***
https://bugs.launchpad.net/bugs/1808389
Yep, the changes accepted to B/C-unapproved as part of an SRU should be what we
need.
Marking as a Duplicate so that we can test that SRU as well to hopefully
resolve it for all of us.
** This bug has bee
Ok, thanks Jason.
That is great info, but about as much as we had so far :-/
Can you set your deployment up in a way that if that happens again you
can collect these binaries?
If it right now still triggers if you (re)deploy a 2G guest use the
chance to finally give us the bits that we will need
701 - 800 of 1353 matches
Mail list logo
