** Merge proposal unlinked:
https://code.launchpad.net/~paelzer/ubuntu/+source/chrony/+git/chrony/+merge/345498
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to ubuntu-fan in Ubuntu.
https://bugs.launchpad.net/bugs/1718227
Title:
** Merge proposal unlinked:
https://code.launchpad.net/~paelzer/ubuntu/+source/chrony/+git/chrony/+merge/345498
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to ubuntu-fan in Ubuntu.
https://bugs.launchpad.net/bugs/1718227
Title:
Odd, I don't remember where I had the -224 kernel from exactly - even in
proposed it isn't :-/.
The next one still is a bit out it seems per bug 1772960
I agree that the last you can currently get is linux-image-generic 4.4.0.127.133
But with that as well it just works fine for me.
I suffer
At least for the DPC protection it seems more a kernel issue in regard
to PCIe handling than anything else for now. Due to that I'm adding a
task for the kernel as well.
** Also affects: linux (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you
I implemented this in uvtool for Bionic, which is why it work.
It is clearly a feature - I don't think it is SRUable.
If you think it is, pull the changes out of the repo and ask to push it to
xenial and artful, but you'd need to convince rbasak twice that it is SRUable
(once for uvtool and
Thanks Alex for cross checking.
I got handed a seabios change that was mentioned to make this work.
I'll clean it up and build/test on my own.
Once I have a good feeling I'll submit an RFC upstream for review and
set you on CC.
--
You received this bug notification because you are a member of
I got access to such a machine and successfully added >32 cards via
hotplug as well as statically in the initial guest xml of libvirt.
I face maybe related issue around "accel/kvm/kvm-all.c:952:
kvm_irqchip_commit_routes: Assertion `ret == 0' failed." now but noting
seems like the old DPC issue.
Dropping server subscription as the remaining (xen) task is incomplete
still
** Tags removed: server-next
--
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/1739665
Title:
[FFE][Feature]
We handled chrony and ntp was demoted, so set ntp to Won't Fix in regard
to this bug.
** Changed in: ntp (Ubuntu)
Status: New => Won't Fix
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to ubuntu-fan in Ubuntu.
You also said this only applies to the full 32bit stack for you (32bit host +
guest) is that correct?
Had you the chance to try the same on 64bit host to know if this is a real
constraint to see this issue? It would at least explain why I didn't see it as
I had 32bit-Guest on 64-bit Host.
And given we have two reporters that point to the upgrade lets tag it a
regression due to that.
--
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/1767857
Title:
Kernel 4.4.0-122 Breaks
Hi,
the own website [1] still calls it "should be considered a work in progress. As
such it is not a complete product nor should it be considered one. Extra care
should be taken when testing and configuring a system to use the KVMGT project".
That said I'm not sure what is expected here. I
Setting qemu task to invalid per Colins explanation that the LP case
doesn't use it.
** Changed in: qemu (Ubuntu)
Status: Confirmed => Invalid
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
Ok, reading that your guests are customer systems I assume you'd need to
setup a test system somewhere to confirm if different host
qemu/libvirt/kernel versions would fix it.
The list of interesting checks:
16.04 Host as-is + 18.04 Guest + qemu from UCA Ocata
16.04 Host as-is + 18.04 Guest + qemu
Thanks, that makes sense.
So it really seems to be the newer virtio drivers in the guest that triggers it
- which is why the move to the HWE kernel
For test systems, I tried to grab a p8 but it failed to install three times in
a row. Not sure what is broken atm, so at least for a while I'll
I did not suggest to install the Cloud Archive code in the 18.04 Guest.
You said your host is 16.04 (Xenial) and there the different UCA's should be
tried to bring new qemu/libvirt code to your host and due to that check if
these newer versions already have a fix we would look for instead of
I got one P8 machine working but no second one that I could reach from there to
test the migratio.
My usual tricks around that with lxd containers didn't work atm so I rely on
people with more P8 HW.
I asked a few people to poll on P8 Devs to take a look as well.
--
You received this bug
> If there are incompatibilities between kernel 4.4 and 4.15, would I maybe
> risk that then I cannot migrate 16.04 guests any longer? Did anyone tests
> this case?
>
This way around (old guest/ new host) I cover migration tests before any
qemu/libvirt upload testin x86/s390/ppc64el (and a tiny
This issue is either in 16.04 qemu (not able to handle the new guests)
or in 18.04s virtio drivers, so I'm adding a linux task for the kernel
first.
** Also affects: linux (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of
Of the listed guests I assume Ubuntu 18.04 has the newest guest Kernel (read
virtio drivers).
Several questions to ensure this is right:
1. could you report the kernel version of each of your test guests
(assuming 4.4 and 4.15 for Ubuntu, but the exact version would be great
to know)
2. it
Also is this a thing that was triggered once, or reproducible every time you
run it.
In the latter case it might be very hard to track down.
I checked and as part of the qemu verification I do run older guests in
newer hipervisors.
I do not yet do vice versa in a lot of tests, so even if this
That implies that for you it is some other config than the current
kernel (or a combination thereof), so far multiple people including me
have not been able to reproduce this - so to further fix things we have
to spot what is different within your setup triggering the issue for
you.
Unfortunately
apport information
** Attachment added: "WifiSyslog.txt"
https://bugs.launchpad.net/bugs/1787328/+attachment/5176119/+files/WifiSyslog.txt
** Package changed: qemu (Ubuntu) => linux (Ubuntu)
--
You received this bug notification because you are a member of Kernel
Packages, which is
I can only umount with force+lazy, but not remount.
The remount hangs (no crash) in D+ state:
$ ps axlf
[...]
4 0 27379 27378 20 0 6628 808 - D+ pts/2 0:00 | |
\_ /sbin/mount.cifs
Mount/Umount from another system works at the same time.
Need to reboot to get
Public bug reported:
My FSTAB so far had this entry
//10.7.0.231/documents /mnt/nas/documents cifs
user,noauto,user=paelzer,vers=3.0 0 0
I found after a reboot (to free up of the crashes above) that I need to change
this.
I wondered why the logins won't work anymore until I realized it was
*** This bug is a duplicate of bug 1778854 ***
https://bugs.launchpad.net/bugs/1778854
This reminds me of a bug I filed actually - rereading history on the old
one ...
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
*** This bug is a duplicate of bug 1778854 ***
https://bugs.launchpad.net/bugs/1778854
Public bug reported:
Hi,
I have run into this and I'm not entirely sure if it is an error or just not
supported.
I'll file the bug and would ask for a check and answer by the kernel Team and
IBM about
*** This bug is a duplicate of bug 1778854 ***
https://bugs.launchpad.net/bugs/1778854
Yeah, dup'ing
** This bug has been marked a duplicate of bug 1778854
kvm_pr on power9 not loadable
--
You received this bug notification because you are a member of Kernel
Packages, which is
Hi Ante, being a Kernel introduced issue Jürg was testing it (not me as
I had no spare HW at the time anyway) - see comment #24.
--
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/1767857
Oh, I just realized while initially reported against qemu in bug 1781526
that this is a kernel, and not a qemu patch.
That spreads the timeline a bit:
- this should be in Cosmic before Release to avoid issues due to the fix of
1781526.
- since that is kind of short I'll bump priority there.
-
FYI: this is essentially an IBM request, reverse mirroring will happen
at some point, but I wanted to make you aware right now
--
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/1788098
For this particular case the log files are not needed and/or applicable.
After discussing in #stable-kernel I set it to confirmed.
** Changed in: linux (Ubuntu Bionic)
Status: New => Confirmed
** Changed in: linux (Ubuntu Cosmic)
Status: Incomplete => Confirmed
--
You received
** Description changed:
+ FYI: This blocks bug 1781526 - once this one here is resolved we can go
+ on with SRU considerations for 1781526
+
--- Comment From jhop...@us.ibm.com 2018-08-20 17:12 EDT---
- Hi, in some environments it was observed that this qemu patch to enable THP
made
Tested, confirmed wrapped in a libvirt upstream patch and submitted at
https://www.redhat.com/archives/libvir-list/2018-August/msg01532.html
Lets give the people a few days to read and ack as well then we can push
it to cosmic.
It came to my mind that due to HWE-Kernels we eventually also want
After discussion with SMB/Kleber accepting the Trusty nomination for now
having that kernel in Trusty as well.
** Also affects: linux-azure (Ubuntu Trusty)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Kernel
Packages, which is
Upstream accepted:
https://libvirt.org/git/?p=libvirt.git;a=commit;h=8741b9435108b1f0d87670e44e1ed75f806b7791
--
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/1788603
Title:
libvirt fails
Tested from PPA, also passed through some more checks and all look fine
- but that was expected given the change being "just" opening up
apparmor a little bit.
Uploading to Cosmic ...
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux
Tested against Kernel 4.18 from mainline builds:
http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.18/linux-image-unsigned-4.18.0-041800-generic_4.18.0-041800.201808122131_amd64.deb
For the latter SRU I summarized the testing procedure:
Note: This can but does not have to be tested in nested
Prepared in PPA: https://launchpad.net/~ci-train-ppa-
service/+archive/ubuntu/3381
--
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/1788603
Title:
libvirt fails with failure to open mount
** Description changed:
+ [Impact]
+
+ * Libvirt will no more be able to start guests with newer kernels
+(>=4.18)
+
+ * We brought a fix upstream that we want to backport to potentially
+affected releases (B+C)
+
+ [Test Case]
+
+ Note: This can but does not have to be tested in
FYI cosmic is slightly stalled by glibc migration, other than that it
looks good to me at the moment.
--
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/1788603
Title:
libvirt fails with
PPA for the Bionic SRU at
https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3386
Note: This not only waits for Cosmic to complete, but also for the former SRU
to complete as well.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed
Thanks John for having that already fixed.
I wanted to let everybody subscribed here know that as of today Cosmic has the
new systemd 239.
That said people (like me) who reboot rarely and still have a kernel before
that will from now on see this when booting a cosmic container:
# systemctl
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
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
"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
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)
Had another set of regression tests as I bundled another fix.
All good still.
Pushing for the SRU teams consideration ...
--
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/1788603
Title:
Ok, glibc was unblocked and we can take a look at pushing this for
Bionic as well.
--
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/1788603
Title:
libvirt fails with failure to open mount
Assigned the task on request by JFH
** Changed in: makedumpfile (Ubuntu)
Assignee: (unassigned) => Canonical Kernel Team (canonical-kernel-team)
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to makedumpfile in Ubuntu.
** Tags added: qemu-19.04
** Also affects: qemu (Ubuntu)
Importance: Undecided
Status: New
** Changed in: qemu (Ubuntu)
Status: New => Triaged
** Changed in: xen (Ubuntu)
Status: New => Invalid
** Also affects: linux (Ubuntu)
Importance: Undecided
Status: New
no need for the kernel bot, set to 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.
https://bugs.launchpad.net/bugs/1782205
Title:
KVM
Thanks for clarification Paul.
Being Kernel+Qemu changes I added bug tasks for these.
--
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/1782205
Title:
KVM SnowRidge enable new ISAs
Status
Ack to the report.
While I had some systems (lpar) which worked I was trivially able to confirm
that it doesn't work on KVM guests based on cloud images.
I see this on install of kdump-tools (default answers to debconf)
Setting up kdump-tools (1:1.6.4-2) ...
Using config file '/etc/zipl.conf'
Expected closest good/bad as git Builds:
Last 4.13 git tag Ubuntu-4.13.0-32.35 - working
First 4.14 git tag Ubuntu-4.14.0-11.13 -
$ git bisect start
$ git bisect good Ubuntu-4.13.0-32.35
$ git bisect bad Ubuntu-4.14.0-11.13
Build is slow, but it seems I can bisect from here ...
Arr shortly
Reproduced:
2018-09-06T08:25:22.816912Z qemu-system-ppc64: VQ 0 size 0x100 Guest index
0x8101 inconsistent with Host index 0xfd: delta 0x8004
2018-09-06T08:25:22.816963Z qemu-system-ppc64: error while loading state for
instance 0x0 of device 'pci@8002000:01.0/virtio-net'
I can also confirm that driving the same case on x86 is not affected.
I'd be glad to pull in PPC-Developers in case they know of any virtio
bugfix that was done in qemu and/or kernel that might be related.
--
You received this bug notification because you are a member of Kernel
Packages, which
4.15.0-33-generic Failed,
4.4.0-134-generic we know works.
I tested 4.13.0-46-generic and it worked (as expected after the positive 17.10
report in comment #23)
checking different builds from there
Bionic builds (so even the 4.13.0-32.35 being "before" the tested -46 it is the
Bionic build of
Note to myself:
Combine mainline kernel: git://kernel.ubuntu.com/ubuntu/linux.git
Ubuntu kernel: git://kernel.ubuntu.com/ubuntu/ubuntu-bionic.git
in one repo.
Get git://kernel.ubuntu.com/ubuntu/kteam-tools.git
Setup needed chroots (amd64 + arch you need)
sudo ./make_chroot bionic amd64
2a) is an upstream decision to have better disk integrity guarantees.
There is a release notes entry since 17.10 (which is also refrenced from the
18.04 release notes)
=> https://wiki.ubuntu.com/ArtfulAardvark/ReleaseNotes#qemu_2.10
2b) is I think an upstream change by the PPC devs actually.
Started a guest with Bionic and Kernel 4.18 - working due to the updated
apparmor profile.
We already had general regression tests on the identical PPA content, not
redoing the same.
Setting verified.
** Tags removed: verification-needed verification-needed-bionic
** Tags added:
For your testing here the default content of zipl.conf on a cloud-img
KVM guest
$ cat /etc/zipl.conf
# This has been modified by the cloud image build process
[defaultboot]
default=ubuntu
[ubuntu]
target = /boot
image = /boot/vmlinuz
parameters = root=LABEL=cloudimg-rootfs
ramdisk =
This is also the reason for all the fails in [1] which actually flags a
real issue as reported in this bug
[1]: http://autopkgtest.ubuntu.com/packages/m/makedumpfile/cosmic/s390x
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to
Hi Joseph,
neither me nor James have realized that this waited for a retest on our side.
The old kernel that you had linked is gone by now (together with Artful I
assume) :-/
Would you mind prepping a new test kernel of your choice (This still is
an issue in cosmic, so whatever works best for
TL;DR:
- a KVM guest with the kernel change as identified above
- works on Bionic host (kernel 4.15 / qemu 2.11 / libvirt 4.0)
- migrating on a Xenial host (kernel 4.4 / qemu 2.5 / libvirt 1.3.1) fails
VQ 0 size 0x100 Guest index 0x8101 inconsistent with Host index 0x81: delta
0x8080
error
PPA prepared at:
https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3412
MP:
https://code.launchpad.net/~paelzer/ubuntu/+source/qemu/+git/qemu/+merge/354695
Test of the case on the PPA is successful.
But I'll need a regression check on that before going on.
** Changed in: qemu
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
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
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
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
** 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:
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
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.
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
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
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
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
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
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
** 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:
** 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
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
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
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
Testes as-is (to confirm we hit the bug)
1.0.0 (12:53:43): MIGRATE: in-release migrations
1.1.0 (12:53:43): Clean testbeds
1.1.1 (12:53:43): stop containers
1.1.2 (12:53:43): orig: restore containers from snapshot: xenial
1.1.3 (12:53:43): Restore testkvm-xenial-from
1.1.4
Note to myself test instructions carried from my original bug
Update Kernel:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1712831/comments/12
and
sudo qemu-system-i386 -hda autopkgtest-bionic-i386.img -enable-kvm -nographic
-curses -m 4096
Test:
sudo autopkgtest --shell-fail
Hi Joseph, I'm back from my PTO, but have to ask you again for an update
- as in the past I'll need 32bit kernels for this test
--
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
Yes both are known to be flaky - thanks!
--
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/1783140
Title:
KVM live migration fails
Status in The Ubuntu-power-systems project:
In
Hi Joseph, due to some maas accident I got my test system destroyed by a
coworker.
I tested v4.19-rc3 as I wrote in comment #51 - do you mind accepting that as a
valid "test latest mainline" even thou it was not -rc4 as it would be now?
--
You received this bug notification because you are a
** Information type changed from Private Security to Public Security
--
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/1790457
Title:
kernel: improve spectre mitigation
Status in Ubuntu
To be clear - this relies on special HW to be present, so I can't validate it.
IBM was so kind to verify the PPAs in advance, it would be great if you could
do so again with the bits in proposed.
--
You received this bug notification because you are a member of Kernel
Packages, which is
Thanks for testing, setting tags accordingly.
** Tags removed: verification-needed verification-needed-bionic
** Tags added: verification-done verification-done-bionic
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
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
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
@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
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
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.
1 - 100 of 693 matches
Mail list logo
