On 07/29/2015 11:12 PM, Josh Boyer wrote:
On Wed, Jul 29, 2015 at 4:55 PM, Richard W.M. Jones <rjo...@redhat.com> wrote:
On Wed, Jul 29, 2015 at 10:36:07AM -0400, Josh Boyer wrote:
Secondly, it would be excellent if someone could commit to spinning
test ISOs when requested. Turn around time on bugs like this are
quite lengthy given that they often require building a new kernel
package, and then spinning a custom ISO with that package included.
Ideally the ISO content would not change from spin to spin other than
the kernel, to eliminate variables.
Could qemu-sanity-check[1] help here? It's designed so that you can
test if a kernel boots on qemu, in a very simple manner (it was
actually designed to be run from kernel.spec so we'd never build and
ship a non-working kernel again).
No, because the environment on the boot.iso/DVD image is what is
triggering the bug. You need a full compose with the kernel.
I already mentioned we autotest the kernel in VMs and it doesn't hit
this bug. Running it there (or even moreso from kernel.spec) cannot
possibly cover all scenarios, so claiming it would prevent shipping a
non-working kernel again is inaccurate given that setup didn't catch
this. More testing always helps, but nothing will provide the claim
you make.
FWIW: I locally rebuilt 4.2.0-0.rc4.git2.1 for fc22 and gave the
resulting kernel-4.2.0-0.rc4.git2.1.fc22.i686+PAE*rpm a real-world try
on my fc22 netbook (w/ Atom N270).
AFAICT, so far, it seems to boot (and work) without any apparent
immediate issues. So, my wild guess would be on an iso/boot-image
composition or tooling issue.
Ralf
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
