Progress
** Changed in: libvirt (Ubuntu Eoan)
Assignee: (unassigned) => Christian Ehrhardt (paelzer)
** No longer affects: libvirt (Ubuntu Cosmic)
** No longer affects: linux (Ubuntu Cosmic)
** No longer affects: qemu (Ubuntu Cosmic)
--
You received this bug notification because you
As already outlined in the report by Daniel, on the libvirt side there is
nothing to action on.
While one might wonder about a downstream only feature being upstream, I don't
see much benefit in adding a delta to Ubuntus libvirt to remove it. It is an
opt-in feature and does not affect users in
Thanks Rafael, I reviewed the MP, thanks for the fixup.
I sponsored it into bionic-unapproved.
It would be great if the SRU Team could evaluate and accept this minor update
to the Former upload.
--
You received this bug notification because you are a member of Kernel
Packages, which is
@Ai Lim, it would be great to get your testing on the PPA asap.
@Rafael - we already have the fixup. I have provided feedback on the MP,
I think we can quickly sponsor something new. That means we don't need
to go the full verification-failed, reject, new upload path - instead we
will ask to
Per [1] this means "In Progress" until such a seed/dependency change is
done.
[1]: https://wiki.ubuntu.com/MIRTeam#Process_states
** Changed in: thunderbolt-tools (Ubuntu)
Status: Confirmed => In Progress
--
You received this bug notification because you are a member of Kernel
Packages,
@cking - yes the comments by Seth and the later update of Doko a year ago are
clear.
This is ready to land just someone needs to add a dependency or seed change to
pull it in.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to
Also I wonder if this should be a dup to 1838751 and better track all three
changes in one bug?
But so far I keep that a suggestion for the reporter or the kernel Team
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
Changed to be a kernel bug, as this doesn't seem for bind9 (as reported
right now)
** Package changed: bind9 (Ubuntu) => linux (Ubuntu)
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
Changed to be a kernel bug, as this doesn't seem for bind9 (as reported
right now)
** Package changed: bind9 (Ubuntu) => linux (Ubuntu)
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
You can do so even per-size via e.g.
/sys/kernel/mm/hugepages/hugepages-1048576kB/nr_hugepages
As discussed the later the allocation the higher the chance to fail, so
re-check the sysfs file after each change if it actually got that much memory.
The default size is only a boot time parameter.
Summary:
As I mentioned before (on the other bug that I referred).
The problem is that with a PT device it needs to reset and map the VDIO devices.
So with >0 PT devices attached it needs an init that scales with memory size of
the guest (see my fast results with PT but small guest memory).
As I
Some updates to libvirt:
- we already have ssbd/md-clear through security updates
- rdctl-no, ibrs-all, skip-l1dfl-vmentry, mds-no are part of
c8ec678f cpu_map: Introduce IA32_ARCH_CAPABILITIES MSR features
- arch_capabilities itself comes in 511df17a
There are also updates to the
FYI - the related qemu changes have a PPA at
https://launchpad.net/~paelzer/+archive/ubuntu/bug-1836154-s390x-
hwmodels/+packages
--
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/1836153
Tags pushed and uploaded to B/D unapproved for the SRU Team to do a
final review and accept.
I also marked Cosmic as Won't Fix as it will be out of support before
this SRU completes.
Further I added libvirt Tasks where the next step is for rafaeldtinoco
to find if/what we'd need to make the
Due to some accident on bug 1826410 it was closed by scripts/automation every
now and then.
To avoid this APW recommended to create a new bug and make the old bug a dup.
This was done and this is the clone that from now on shall be worked on without
these stray updates.
--
You received this
apport-collect makes no sense for this which is more a feature/packaging
request, setting confirmed
** Changed in: linux (Ubuntu)
Status: New => Confirmed
** Changed in: linux (Ubuntu)
Status: Confirmed => Triaged
** Changed in: linux (Ubuntu)
Importance: Undecided => High
**
*** This bug is a duplicate of bug 1836708 ***
https://bugs.launchpad.net/bugs/1836708
This is now a dup of its own clone per our IRC discussion:
[10:12] cpaelzer, it sometimes is just easier to make a new bug and dup
the old against it :)
[10:18] to get rid of the stray tracking updates
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
Debian:
root@d10-sid:~# apt-cache show libbpf-dev libbpf4.19
Package: libbpf-dev
Source: linux
Version: 4.19.37-5
Installed-Size: 378
Maintainer: Debian Kernel Team
Architecture: amd64
Depends: libbpf4.19 (= 4.19.37-5)
Description-en: eBPF helper library (development files)
libbpf is a library
The Disco upload is in disco-unapproved waiting for the SRU Teams review
now.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to iproute2 in Ubuntu.
Matching subscriptions: iproute2
https://bugs.launchpad.net/bugs/1831775
Title:
ss seems
And qemu 4.0 is in Eoan, so this release is "fix released" (for the
scope of adding the features, not the just discussed versioned CPUs)
** Changed in: qemu (Ubuntu Eoan)
Status: In Progress => Fix Released
** Changed in: qemu (Ubuntu Eoan)
Assignee: Christian Ehrhar
Public bug reported:
One common case of facing a new dkms build error is on new uploads to the
Ubuntu archive.
Proposed migration will trigger the dkms install of a bunch of modules and e.g.
some of them will fail on a new kernel.
The default behavior has a local system & user in mind and will
The series was merged in 3a1acf5d47295d22ffdae0982a2fd808b802a7da as a prep to
qemu 4.1.
But the changes are rather invasive and after a review I think for the SRU we
will not add them.
For example the changes around:
"model runnability guarantees won't apply to unversioned CPU models
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
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:
@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
> 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.
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.
@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
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
-
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
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
** 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:
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
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
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
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
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
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
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
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
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.
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
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
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:
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.
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
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:
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
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
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
@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
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
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
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
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.
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.
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
@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.
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
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
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.
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]:
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
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
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
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
>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
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
** 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
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*'
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.
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
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
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,
Ran with:
- the cloud-image of Xenial of 20190419 [1]
- XML with a memory definition of:
2097152
2097152
- kernel 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 it is
@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
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
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
@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
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
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
** 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
** 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.
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
** 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.
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 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
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
401 - 500 of 693 matches
Mail list logo
