This works fine for me now, see attached. bug 1765668 is a different
issue, unrelated to the kernel.
** Attachment added: "xenial-guest-in-bionic.log"
https://bugs.launchpad.net/ubuntu/+source/edk2/+bug/1744754/+attachment/5123982/+files/xenial-guest-in-bionic.log
--
You received this bug no
I can reproduce this in Bionic ARM64, bug 1765668
--
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/1744754
Title:
qemu-efi-aarch64 in >= artful can't boot xenial cloud images
Status in cl
This bug was fixed in the package linux - 4.4.0-119.143
---
linux (4.4.0-119.143) xenial; urgency=medium
* linux: 4.4.0-119.143 -proposed tracker (LP: #1760327)
* Dell XPS 13 9360 bluetooth scan can not detect any device (LP: #1759821)
- Revert "Bluetooth: btusb: fix QCA Rome
** Attachment added: "dmesg-bionic-host.txt"
https://bugs.launchpad.net/ubuntu/+source/edk2/+bug/1744754/+attachment/5084479/+files/dmesg-bionic-host.txt
** Tags removed: verification-needed-xenial
** Tags added: verification-done-xenial
--
You received this bug notification because you are
After updating to the proposed kernel, I was able to boot a xenial cloud
image with qemu-efi from both xenial (DTB mode) and bionic (ACPI mode).
** Attachment added: "dmesg-xenial-host.txt"
https://bugs.launchpad.net/ubuntu/+source/edk2/+bug/1744754/+attachment/5084478/+files/dmesg-xenial-host
This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
xenial' to 'verification-done-xenial'. If the problem still exists,
change the tag 'verifica
My backport for option #3 has been merged, so no need for a change in
the cloud images or edk2.
** Changed in: cloud-images
Status: New => Invalid
** Changed in: edk2 (Ubuntu)
Status: Confirmed => Invalid
--
You received this bug notification because you are a member of Kernel
Pac
** Changed in: linux (Ubuntu Xenial)
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/1744754
Title:
qemu-efi-aarch64 in >= artful can't boot xe
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: edk2 (Ubuntu)
Status: New => 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/1744754
T
** Tags added: id-5a674ab10c375ca04060ea9a
--
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/1744754
Title:
qemu-efi-aarch64 in >= artful can't boot xenial cloud images
Status in cloud-ima
** Description changed:
[Impact]
After upgrading an Ubuntu/arm64 KVM host past xenial, your xenial-based
guests will fail to boot.
[Test Case]
Boot a xenial cloud image with qemu-efi-aarch64 from artful/bionic.
[Regression Risk]
I've tested booting a xenial cloud image in bionic
** Description changed:
[Impact]
After upgrading your KVM hypervisor past xenial, your xenial-based guests
will fail to boot.
[Test Case]
Boot a xenial cloud image with qemu-efi-aarch64 from artful/bionic.
[Regression Risk]
- TBD
+ I've tested booting a xenial cloud image in bioni
@Robert: Actually, X-Gene is supported on trusty, which is non-GICv3,
but your point is taken. I personally think option #3 would be the best
option, but wasn't sure of the feasibility. However, I've been working
on the necessary kernel backports in the background over the past week,
and I now have
Dann,
Regarding the 2nd option you listed: "Switch the xenial cloud-images to
use the HWE kernel. There's precedent for this (we did it for trusty to
add support for GICv3 systems). Existing VMs using 4.4 will still break
after upgrading qemu-efi past xenial."
As you know, the prior change to a T
Here are the 3 options for dealing with this I've come up with:
1) Disable ACPI in edk2 builds. That'd be an easy fix - but switching
away from upstream defaults isn't very future-proof. It also seems like
a pretty big regression risk for existing artful/bionic users who may be
depending on ACPI.
I bisected this down to the following edk2 commit:
commit 78c41ff519b187d8979cda7074f007a6323f9acd (refs/bisect/bad)
Author: Ard Biesheuvel
Date: Thu Mar 9 16:59:34 2017 +0100
ArmVirtPkg/FdtClientDxe: make DT table installation !ACPI dependent
Instead of having a build time switch
16 matches
Mail list logo