Help needed: F23 32-bit kernel issue

Ralf Corsepius rc040203 at freenet.de
Thu Jul 30 07:43:46 UTC 2015


On 07/29/2015 11:12 PM, Josh Boyer wrote:
> On Wed, Jul 29, 2015 at 4:55 PM, Richard W.M. Jones <rjones at 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




More information about the devel mailing list