On 22/12/16 10:45, Jan Beulich wrote:
On 22.12.16 at 11:28, <ian.jack...@eu.citrix.com> wrote:
osstest service owner writes ("[xen-unstable test] 103788: regressions -
trouble: broken/fail/pass"):
flight 103788 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103788/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-xsm 3 host-install(3) broken REGR. vs. 103466
elbling1 had forgotten its boot order. I found it at an initramfs
prompt, unable to find its own hard disk. I think this was after
http://logs.test-lab.xenproject.org/osstest/logs/103764/test-amd64-amd64-xl-x
sm/info.html
(the last xen-boot failure before it started giving host-install
failures).
Hmm, that one has a bunch of
Dec 20 13:30:00.237953 Begin: Running /scripts/local-block ... Volume group
"elbling1-vg" not found
Dec 20 13:30:00.397968 Skipping volume group elbling1-vg
Dec 20 13:30:00.398003 Unable to find LVM volume elbling1-vg/root
which I would suspect were the cause of the xen-boot failure.
As I'm unaware of systems outside the osstest pool having this
"forgets its boot order" problem (does e.g. XenRT know similar
problems?)
No. No similar problems I am aware of anywhere in XenRT (which haven't
ended up being down to human intervention in the firmware)
, I wonder whether either the physical machine setup
is (somewhat) unusual for some or all of the machines, or
whether there's something being run which with not too small a
likelihood causes the problem (and it being run often enough
simply guarantees the problem to surface every once in a while).
Is anything playing with EFI variables? This seems like the most likely
option.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
