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
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
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
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
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
Jason,
thanks for chiming in - so far this was non-reproducible every time we looked
at it. We had plenty of approaches with the MAAS team to this and later on with
Thiago, but still miss the right data to continue.
Last time I asked - I think it was still Mike - that I'd really like to
get the
My questions in comment #1 where no answered directly yet, but this
still is using only kernel patches so far, I think it is time to add at
least a kernel task.
Furthermore it isn't upstream yet and the target being 5.2 is a bit out
still, so I'd think you should target 19.10
** Also affects:
Just the plain Disco kernel environment as you get it when spawning a
new guest - data provided changing state of both bug tasks back.
** Changed in: xorg-server (Ubuntu)
Status: Incomplete => New
** Changed in: linux (Ubuntu)
Status: Incomplete => Confirmed
--
You received this
apport information
** Attachment added: "ProcEnviron.txt"
https://bugs.launchpad.net/bugs/1818879/+attachment/5244320/+files/ProcEnviron.txt
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
apport information
** Attachment added: "UdevDb.txt"
https://bugs.launchpad.net/bugs/1818879/+attachment/5244323/+files/UdevDb.txt
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
apport information
** Attachment added: "WifiSyslog.txt"
https://bugs.launchpad.net/bugs/1818879/+attachment/5244324/+files/WifiSyslog.txt
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
apport information
** Attachment added: "ProcInterrupts.txt"
https://bugs.launchpad.net/bugs/1818879/+attachment/5244321/+files/ProcInterrupts.txt
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
apport information
** Attachment added: "ProcModules.txt"
https://bugs.launchpad.net/bugs/1818879/+attachment/5244322/+files/ProcModules.txt
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
apport information
** Attachment added: "ProcCpuinfoMinimal.txt"
https://bugs.launchpad.net/bugs/1818879/+attachment/5244319/+files/ProcCpuinfoMinimal.txt
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
ProblemType: Bug
AlsaDevices:
total 0
crw-rw 1 root audio 116, 1 Mar 7 08:12 seq
crw-rw 1 root audio 116, 33 Mar 7 08:12 timer
AplayDevices: Error: [Errno 2] No such file or directory: 'aplay': 'aplay'
ApportVersion: 2.20.10-0ubuntu23
Architecture: amd64
ArecordDevices: Error: [Errno
apport information
** Attachment added: "ProcCpuinfo.txt"
https://bugs.launchpad.net/bugs/1818879/+attachment/5244318/+files/ProcCpuinfo.txt
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
apport information
** Attachment added: "CurrentDmesg.txt"
https://bugs.launchpad.net/bugs/1818879/+attachment/5244316/+files/CurrentDmesg.txt
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
apport information
** Attachment added: "Lspci.txt"
https://bugs.launchpad.net/bugs/1818879/+attachment/5244317/+files/Lspci.txt
--
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/1818879
@Daniel - on one hand it is also a change in xorg that makes the driver missing
now - so an FYI for that.
But in an IRC discussion there were two potential paths to resolve this issue
overall:
- make the cirrus.ko available in the non -extra package so that it works out
of the box using this
TBH this isn't about "a warning/error message to be missing" - it is a request
to add the feature to be able to "Allow creating max number of VCPUs on POWER9"
and should be declared like that.
@JFH/@Manjo - I leave it to you to discuss that and make the change.
Furthermore the patches referred
Thanks for all your effort Leonardo,
that seems to make the bug valid again, but I'll leave that to JFH/Manoj to
resurrect it and make it a proper kernel bug as it seems there now is a way to
test it (at least you can do so) and a set of patches. I can not speak for the
ack/nack of those
@Vern - ping please test to unblock this from bionic-/cosmic-proposed
--
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/1805920
Title:
iPXE ignores vlan 0 traffic
Status in MAAS:
Ok, now we finally know it is about qemu patches - I'll add tasks for
that.
Still haven't seen any xen references, setting that to incomplete.
But given how new it is I'd punt this from 19.04 to 19.10 where things
in kernel will have matured and be safer to use.
If you are not ok with this
Oh I can tell what it was, I still use the most up-to-date-from-git
version of the firmware from [1]. The testing back then wasn't
successful, but I'm reluctant to go back to the base version as I'm
afraid the error strikes me at some odd point when I really need
wireless.
If anyone else is
Thanks Arie for providing your configuration fix to the issue for anyone
else being affected - that will be really helpful.
In that sense it is much more like bug 1346917 which was about KSM.
Since the fix for that old bug they at least stopped being migrated around, but
I can see how a lot of
Hi Arie,
I saw you also posting on some other old bugs with the same symptom (e.g.
1346917).
And that exactly is the problem with this issue - the message only represents
the symptom but not the root cause. Fixing the symptom makes no sense, because
if your IRQ delivery is stalled then it is
At least for me the error stopped showing up since 11th January up to now.
So whatever I did when experimenting/reporting that bug has resolved it.
Unfortunately I can't clearly tell anyone else affected what exactly that would
be :-/
--
You received this bug notification because you are a
To some extend this feels a bit like:
- https://bugzilla.redhat.com/show_bug.cgi?id=1242383
- https://bugzilla.redhat.com/show_bug.cgi?id=1151306
All those got closed as "invalid host config -> won't fix" so we can't find the
fix there.
But something happened to let it work fine in my case, we
I used a recent version of the softwrae stack from Disco
- qemu 3.1
- libvirt 5.0
- openvswitch 2.11
With that I had a guest with an OVS device like that:
Not too different to your's I'd think.
The OVS is trivial
We now need to find out what the difference is:
a) your test case is slightly different and you can trigger it on the same SW
levels it works for me, then we need to report that to upstream as those are
the very latest versions
b) your test is good once you use the more recent SW levels, in that
** Package changed: qemu-kvm (Ubuntu) => qemu (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/1812822
Title:
Guest crashed when detaching the ovs interface device
Status in
Thanks for your continuous efforts on this Leonardo, I have no further
suggestion.
I think to stay on the safe side we will keep everything as-is for now.
I'd say it is IBMs call to decide between this now:
a) Speed: Call 1781526 unblocked by the evaluation here. We'd re-consider
SRUing that
@Vern - if there is any ETA when you will get to the real SRU
verifications that were requested by Brian a week ago let us know
--
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/1805920
Hmm, so are we giving up on this?
--
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/1736390
Title:
openvswitch: kernel oops destroying interfaces on i386
Status in linux package in
Just to be sure, since Ubuntu's gcc has "--enable-default-pie" I wanted to
check.
Do "the others" set pie by default as well?
Just want to make sure that their execution without explicit pie is -no-pie
while ours would then be -pie.
For your kernel thoughts - even though the first idea was
Thanks for the heads up, sounds very interesting!
I know you said you are still analyzing, so I'll wait ... so many
questions in my mind already :-)
But one thing to check up front - which gcc version are you using on
this test on Ubuntu and which one on the systems you compare?
** Also
After all my tries with different Firmware versions I went back and
since then the error didn't show up anymore. If anything it might be
only (or more likely) showing up when the laptop is docked - but I don#t
see how that would happen.
Anyway, for now it seems I'm good.
I'll check my logs in a
Ok, thanks for the precheck Vern.
Now that we know that you will be able to SRU-verify this I have uploaded it to
the SRU queue.
Once accepted by the SRU Team there will be updates here asking for
verification. Please do that for Bionic and Cosmic then - if you need any help
let us know.
Hi Seth,
to answer at least for me - it never worked on my system.
No "degradation on upgrade" at least for me, just never worked.
I'm considering filing a bug with Intel and or Lenovo (for a remote chance to
get their FW developers to look at it) - if only I knew where.
If someone did that in
Since some similar issues in the past were reported to be related to
kernel updates lets add a task
** Changed in: linux-firmware (Ubuntu)
Status: Incomplete => Confirmed
** Also affects: linux (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification
This is actually about two bugs in one and related to bug 1804841
Lets disambiguate them.
One can be avoided by a config in network-manager as mentioned in comment #19
Lets handle this bug here as "that one" - at least in Bionic and later - fixed
by being set by default.
This was initially
Note: the workaround of
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1710390 is in place
by default in Bionic - this needs some other fix.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-firmware in Ubuntu.
I thought it might be worth to try the other versions of the FW.
So I renamed the files like:
sudo mv /lib/firmware/iwlwifi-8265-36.ucode
/lib/firmware/DONOTLOAD-iwlwifi-8265-36.ucode
Eventually I ended up with:
-rw-r--r-- 1 root root 1811984 Apr 24 2018
I created a PPA for Bionic with the latest firmware (git of today) merged into
the Package version we have in Disco. That can be found at [1].
But even that didn't help - which means even the very latest upstream will not
fix the issue for us auto-magically.
[1]:
/lib/firmware/iwlwifi-8265-36.ucode is the newest even in the linux-
firmware package of Ubuntu Disco
linux-firmware | 1.173.2 | bionic-updates | source, all
linux-firmware | 1.175.1 | cosmic-updates | source, all
linux-firmware | 1.176| disco| source, all
$ dpkg -L
Hi I'm affected as well.
I had hoped that the HWE kernel would somehow magically make things better but
it doesn't.
System is a Lenovo T580 with Dual Band Wireless AC 8265
Attaching dmesg section where the wifi crashes
Interesting lines:
529 [293336.199635] iwlwifi :04:00.0: loaded
Interesting, thanks Leonardo!
Tested on Bionic (4.15) and Disco (4.18).
Default:
sudo modprobe kvm_pr
modprobe: ERROR: could not insert 'kvm_pr': Input/output error
Added "disable_radix" to the guest kernel commandline and retried loading the
module again.
Bionic: Malformed early option
Ok, once you know you'll be able to verify it on Cosmic as well (by
successfully testing from the PPA) let me know.
We will then upload it as a real SRU which needs verification per [1].
[1]: https://wiki.ubuntu.com/StableReleaseUpdates
--
You received this bug notification because you are a
NO response yet, we really want to fix it but need some way to verify it.
Sorry to ask once again, but we need to get this unblocked.
@Vern - can you use the setup to verify the two planned uploads for Bionic and
Cosmic?
--
You received this bug notification because you are a member of Kernel
Hi Leonardo,
thanks for your efforts trying to verify that.
Given that you couldn't trigger it I wonder what to do.
Currently it is incomplete waiting for such a test, but as it seems to elude
you I'd suggest we call the bug invalid until we would know otherwise.
For the related bug 1781526 I
I'll upload once I get a confirmation that it will be tested on both
releases on the affected HW.
** Description changed:
[Impact]
* VLAN 0 is special (for QoS actually, not a real VLAN)
* Some components in the stack accidentally strip it, so does ipxe in
this case.
* Fix by
@Ryan - the resource and other bits being different is because in the
bad case the domain was up and in the good case down. That in itself is
not a problem.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
Again it seems to break on initramfs being bad:
[0.840153] Initramfs unpacking failed: no cpio magic
@Mike/Andres - can you reproduce it on your own test env this time?
@Vladimir - could you internally share exactly your kernel and initrd
that is tried to be booted in this case? Last time we
Thanks for the Details, but that means that even the MAAS Team might
have enough systems, but not the right special HW.
Therefore @Vern could you do the pre-checks with your associated
customer that you can verify the bug on their setup before we push it
as SRU?
As I said, you only need to have
TL;DR:
- I really really tried, but failed to recreate yout case on a single system
- I need your real setup as the VLAN-Tag-0 addition in your case seems to be
different
- That makes my request to one of you committing (and checking to be able to)
to verify this even more important - see
virt stack tests are successful on 1.0.0+git-20180124.fbe8c52d-0ubuntu2.2 and
1.0.0+git-20180124.fbe8c52d-0ubuntu4.1 from the PPA.
Including various others tests, but mostly related migrations and upgrades
between those versions.
Everything fine on that end ...
--
You received this bug
Thank Vern for outlining your testcase.
@Vern
Doesn't that also have to include some component that does QoS management
adding the VLAN-0 tag?
I don't have the systems to verify this case on Bionic and Cosmic.
As I read it from Vern he can only test Bionic at the Customer and is unsure he
can
FYI: virt stack regression tests started but will still take a while.
To make it very very clear, this is incomplete until some path to test was
provided.
Marking the bug that way, waiting on that.
Worst case (and only then) describe the test setup that you have on the
customer site and
Prepped for Bionic and Cosmic in a PPA [1] for Bileto ticket [2]
Depending autopkgtests queued.
I'll run usual virtualization regression checks on that over night and
into tomorrow.
MPs are up for review at [3][4], but since Andeas change applies on all
these as-is there isn't much difference.
To keep potential regressions even lower I'd for now only consider that for
>=Bionic.
That also helps as if someone intentionally spawns an old type KVM machine (pre
Bionic) on a >=Bionic host we don#t have to care about this too much (machine
type, not release runnin IN the guest). That makes
Thanks for accepting that follow-on fix.
With that it now fully works on cosmic as well following the howto on comment
#66
** Tags removed: verification-needed verification-needed-cosmic
** Tags added: verification-done verification-done-cosmic
--
You received this bug notification because you
FYI: We also resolved the systemd test issues in Bionic (unrelated, but needed
a fix).
Lets see how they will look like in Cosmic after the tests on the new upload
complete.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in
[1] seems reasonable, I'll give it a try with and without the PPA of Andres.
It needs a slight modification, to not conflict with the default portal.
Install libvirt with all else it usually brings (for the bridge and dhcp on the
bridge):
$ sudo install libvirt-daemon-system
So use these
On Fri, Dec 7, 2018 at 8:21 PM Mike Pontillo
wrote:
...
> So iPXE's iSCSI functionality wouldn't be exercised in this case.
So MAAS itself is no good test for that, thanks Mike for the
clarification!
So the question is does anyone have a iscsi IPXE case for the last bit
of confidence for
Uploaded libvirt_4.6.0-2ubuntu3.2_source.changes @SRU Team please accept
that into C-proposed over the one we currently have. Then I can re-
confirm it there.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
The mini-fox on top for disco was delayed by some openstack/nova/sqlite tests.
I debugged and fixed them together with coreycb, uploading the Cosmic fix on
top of the current one in proposed.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed
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)
> 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
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
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
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
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
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
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
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
** 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
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 =>
@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
Public bug reported:
Hi,
currently if one wants most common FS tools to be able to mount them to e.g.
mount them "just in case" or when considering a more capable base image or
install CD then there is the problem that installing "zfsutils-linux" pulls in
"zfs-zed" as a recommends.
Having it
Nothing yet happened here.
I also declared the related qemu fix that is blocked by this as incomplete.
@manoj/jfh - maybe time for triage-r here?
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
I found some more things that I'd want for the opengl changes and decided to
unbundle it from this SRU.
That said the qemu and libvirt code for this bug here is now uploaded to
bionic-/cosmic-unapproved for review by the SRU Team.
--
You received this bug notification because you are a member
The migration into 19.04 is complete and the CVE fixes completed as well.
I updated all related repositories and the content 100% matches what we have
pre-tested.
Just a small delay to make sure the bundled opengl enablement works as
well (or to unbundle it).
--
You received this bug
Used the Kernel from Proposed:
apt-cache policy linux-image-4.15.0-42-generic
linux-image-4.15.0-42-generic:
Installed: 4.15.0-42.45
Candidate: 4.15.0-42.45
Libvirt/Qemu from PPA [1]
Having one device assigned to my LPAR atm:
$ ll /sys/bus/ap/devices/
total 0
drwxr-xr-x 2 root root 0 Nov 23
** Description changed:
+ [Impact]
+
+ * The ability to pass through more cryptographic capabilities is a very
+important feature for users of s390x as virtualization platform.
+Its availability upstream now and its backport in this bug allows to
+exploit the crypto cards as new
** Changed in: libvirt (Ubuntu Bionic)
Status: New => Triaged
** Changed in: libvirt (Ubuntu Cosmic)
Status: New => Triaged
** Changed in: qemu (Ubuntu Bionic)
Status: New => Triaged
** Changed in: qemu (Ubuntu Cosmic)
Status: New => Triaged
--
You received this
Integrated the upcoming qemu CVE fixes as well as another SRU fix going
on currently into the builds of our PPA. Also I forked a branch for
18.10 for the same changes.
With that I started the cross arch regression check (still ongoing - and
will for a while)
--
You received this bug
On Thu, Nov 22, 2018 at 6:35 PM bugproxy wrote:
> --- Comment From boris_fiuczyn...@de.ibm.com 2018-11-22 12:21
> EDT---
> @Christian E.:
> You listed two libvirt commit IDs
>
> https://libvirt.org/git/?p=libvirt.git;a=commit;h=faab373b53e1a4eacf0d6f524eb47df243f21fac
>
>
In preparation I did prepare the series for Disco/Cosmic:
For libvirt 4.6 compared to our series to 4.0:
- drop three being upstream in 4.4 and 4.6
2b9690b62d01bb0b8555764e2365976b98fe4d47 v4.4.0
21442874cf61ce61c7e0f8bcd616641f35adda2b v4.4.0
d54e45b6edd7623e488a19e30bc4148a21fa8b03 v4.6.0
Actually Eric beat me, so while I rebased here the patch for lbivirt
vfio MDEV for virt-aa-helper was merged.
That said I can finalize the branches for Disco tomorrow and run a round
of regression tests before an upload to Disco.
In the meantime I got a few cards to my lpar, maybe I can also
FYI: https://www.redhat.com/archives/libvir-list/2018-November/msg00827.html
for the MDEV-vfio apparmor fix upstreaming.
--
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:
Arr, thanks chrome :-/
Such a nice update lost, well let me rewrite it in a shorter fashion:
1. the patches seem good, thanks for the effort to help backporting
2. the extra changes seem safe to me
3. I added a patch on top to get it working with virt-aa-helper
That is essentially an extension
@cborntra: done for you - tags updated - thanks for testing.
On the libvirt side I wait for a series by Boris atm, let me know if the
expectations are otherwise.
** Tags removed: verification-needed-bionic
** Tags added: verification-done-bionic
--
You received this bug notification because
FYI: build log of the current incomplete backport:
https://launchpadlibrarian.net/397706595/buildlog_ubuntu-bionic-s390x.libvirt_4.0.0-1ubuntu8.6~ppa1_BUILDING.txt.gz
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
Some noise in libvirt, I'm not entirely sure if VIR_ENUM_IMPL would need
all the bumps up to 415 or if inserting it at 282 (next) is safe. I
thnik as long as it is the same enum at virQEMUCapsFlags in the header
it should be ok right?
Some more missing bits since vfio-ccw isn't available in
hanged in: libvirt (Ubuntu)
Assignee: (unassigned) => Christian Ehrhardt (paelzer)
** Changed in: qemu (Ubuntu)
Assignee: (unassigned) => Christian Ehrhardt (paelzer)
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to lin
Hi,
we can certainly help trying to make a test PPA available for your testing
backporting what you provided here.
I wonder about the git tree at [1]. It is already further than what was
reported a few days before. It is based on qemu v3.1.0-rc0 at the moment and
has 11 patches . Some of the
** Changed in: libvirt (Ubuntu)
Status: Confirmed => Triaged
** Changed in: qemu (Ubuntu)
Status: Incomplete => Triaged
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
While the target is 18.04 SRU Policy implies this has to be available in all
later releases to avoid upgrade regressions.
OTOH we planned libvirt 5.0 and qemu 3.1 which both are released in late
December/early January for 19.04 instead of starting now (partially on your
request for those
** 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:
501 - 600 of 693 matches
Mail list logo
