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.jack...@citrix.com> 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.
In
http://logs.test-lab.xenproject.org/osstest/logs/132973/test-arm64-arm64-xl/info.html
we see that the failing step started at 15:13:32. In the log
> [1]
http://logs.test-lab.xenproject.org/osstest/logs/132973/test-arm64-arm64-xl/serial-laxton0.log
I see this:
Feb 7 15:14:49.374771 [ 0.000000] Linux version 4.9.0-0.bpo.2-arm64
(debian-ker...@lists.debian.org) (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
kernel.
Looking at the installer log:
2019-02-07 15:18:34 Z 172.16.144.52:39843 <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...
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
