[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] arm64, laxton[01] (was Re: [xen-unstable-smoke test] 133030: trouble: blocked/broken/pass)

Julien Grall writes ("Re: [Xen-devel] arm64, laxton[01] (was Re: 
[xen-unstable-smoke test] 133030: trouble: blocked/broken/pass)"):
> On Tue, Feb 12, 2019 at 12:26 PM Ian Jackson <ian.jackson@xxxxxxxxxx> wrote:
> > I don't have a good plan about what to do next.  I guess one thing we
> > could do would be to ask Yogesh to reflash the firmware on laxton0 and
> > see if that helps.
> >
> > I think this issue is likely to be a protracted problem.  Any helpful
> > suggestions from people with more experience of these particular boxes
> > would be very welcome...
> Looking at the first failure log [1], it seems we are trying to boot
> Linux 3.16.  So the failure seems legit to me as I don't think 3.16
> supports Seattle.

This is odd.  You have definitely spotted something wrong.

we see that the failing step started at 15:13:32.  In the log
  > [1] 
I see this:

  Feb 7 15:14:49.374771 [ 0.000000] Linux version 4.9.0-0.bpo.2-arm64
  (debian-kernel@xxxxxxxxxxxxxxxx) (gcc version 4.9.2 (Debian/Linaro
  4.9.2-10) ) #1 SMP Debian 4.9.18-1~bpo8+1 (2017-04-10)

And that part works.  It runs through d-i and thinks it has succeeded.
But then when the host reboots it reboots into 3.16, not the backports

Looking at the installer log:

  2019-02-07 15:18:34 Z <13>Feb  7 15:18:34
  base-installer: info: kernel linux-image-arm64 usable on arm64 

which is kind of weird.

> So I think we can rule out a firmware bug.  Now, I am struggling to
> understand why osstest is suddenly using 3.16.
> Was there any change in osstest or the configuration?

No.  I think something may be wrong with the way Debian is publishing
the backports kernels.  I will ask...


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.