* [xen-unstable test] 103788: regressions - trouble: broken/fail/pass
@ 2016-12-22 9:01 osstest service owner
2016-12-22 10:28 ` elbling1 (was Re: [xen-unstable test] 103788: regressions - trouble: broken/fail/pass) Ian Jackson
0 siblings, 1 reply; 9+ messages in thread
From: osstest service owner @ 2016-12-22 9:01 UTC (permalink / raw)
To: xen-devel, osstest-admin
[-- Attachment #1: Type: text/plain, Size: 12409 bytes --]
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
test-amd64-i386-libvirt 3 host-install(3) broken REGR. vs. 103466
test-armhf-armhf-xl-xsm 15 guest-start/debian.repeat fail REGR. vs. 103466
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt-raw 12 saverestore-support-check fail like 103394
test-armhf-armhf-libvirt-xsm 13 saverestore-support-check fail like 103466
test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check fail like 103466
test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 103466
test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 103466
test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 103466
test-armhf-armhf-libvirt 13 saverestore-support-check fail like 103466
test-amd64-amd64-xl-rtds 9 debian-install fail like 103466
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 103466
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass
test-amd64-amd64-libvirt 12 migrate-support-check fail never pass
test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass
test-amd64-i386-libvirt-xsm 12 migrate-support-check fail never pass
test-amd64-amd64-libvirt-vhd 11 migrate-support-check fail never pass
test-armhf-armhf-libvirt-xsm 12 migrate-support-check fail never pass
test-armhf-armhf-xl-xsm 12 migrate-support-check fail never pass
test-armhf-armhf-xl-xsm 13 saverestore-support-check fail never pass
test-armhf-armhf-xl 12 migrate-support-check fail never pass
test-armhf-armhf-xl 13 saverestore-support-check fail never pass
test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass
test-armhf-armhf-xl-credit2 12 migrate-support-check fail never pass
test-armhf-armhf-xl-credit2 13 saverestore-support-check fail never pass
test-armhf-armhf-xl-cubietruck 12 migrate-support-check fail never pass
test-armhf-armhf-xl-cubietruck 13 saverestore-support-check fail never pass
test-armhf-armhf-xl-multivcpu 12 migrate-support-check fail never pass
test-armhf-armhf-xl-multivcpu 13 saverestore-support-check fail never pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass
test-armhf-armhf-libvirt-qcow2 11 migrate-support-check fail never pass
test-armhf-armhf-libvirt-raw 11 migrate-support-check fail never pass
test-armhf-armhf-xl-arndale 12 migrate-support-check fail never pass
test-armhf-armhf-libvirt 12 migrate-support-check fail never pass
test-armhf-armhf-xl-arndale 13 saverestore-support-check fail never pass
test-armhf-armhf-xl-rtds 12 migrate-support-check fail never pass
test-armhf-armhf-xl-rtds 13 saverestore-support-check fail never pass
test-armhf-armhf-xl-vhd 11 migrate-support-check fail never pass
test-armhf-armhf-xl-vhd 12 saverestore-support-check fail never pass
version targeted for testing:
xen d6ac8e22c7c5525db1da79fd1d1f03ee6b557f0d
baseline version:
xen fc9229c4bb35c5474fbc67f78e628dcbcc90afc5
Last test of basis 103466 2016-12-16 13:24:29 Z 5 days
Failing since 103540 2016-12-17 16:30:58 Z 4 days 7 attempts
Testing same since 103788 2016-12-21 12:19:10 Z 0 days 1 attempts
------------------------------------------------------------
People who touched revisions under test:
Andrew Cooper <andrew.cooper3@citrix.com>
Anshul Makkar <anshul.makkar@citrix.com>
Bhupinder Thakur <bhupinder.thakur@linaro.org>
Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cédric Bosdonnat <cbosdonnat@suse.com>
Daniel De Graaf <dgdegra@tycho.nsa.gov>
Edgar E. Iglesias <edgar.iglesias@xilinx.com>
Haozhong Zhang <haozhong.zhang@intel.com>
Ian Jackson <ian.jackson@eu.citrix.com>
Jan Beulich <jbeulich@suse.com>
Juergen Gross <jgross@suse.com>
Julien Grall <julien.grall@arm.com>
Kevin Tian <kevin.tian@intel.com>
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Razvan Cojocaru <rcojocaru@bitdefender.com>
Ross Lagerwall <ross.lagerwall@citrix.com>
Stefano Stabellini <sstabellini@kernel.org>
Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Tamas K Lengyel <tamas@tklengyel.com>
Tim Deegan <tim@xen.org>
Wei Liu <wei.liu2@citrix.com>
jobs:
build-amd64-xsm pass
build-armhf-xsm pass
build-i386-xsm pass
build-amd64-xtf pass
build-amd64 pass
build-armhf pass
build-i386 pass
build-amd64-libvirt pass
build-armhf-libvirt pass
build-i386-libvirt pass
build-amd64-oldkern pass
build-i386-oldkern pass
build-amd64-prev pass
build-i386-prev pass
build-amd64-pvops pass
build-armhf-pvops pass
build-i386-pvops pass
build-amd64-rumprun pass
build-i386-rumprun pass
test-xtf-amd64-amd64-1 pass
test-xtf-amd64-amd64-2 pass
test-xtf-amd64-amd64-3 pass
test-xtf-amd64-amd64-4 pass
test-xtf-amd64-amd64-5 pass
test-amd64-amd64-xl pass
test-armhf-armhf-xl pass
test-amd64-i386-xl pass
test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm pass
test-amd64-i386-xl-qemut-debianhvm-amd64-xsm pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass
test-amd64-amd64-libvirt-xsm broken
test-armhf-armhf-libvirt-xsm pass
test-amd64-i386-libvirt-xsm pass
test-amd64-amd64-xl-xsm pass
test-armhf-armhf-xl-xsm fail
test-amd64-i386-xl-xsm pass
test-amd64-amd64-qemuu-nested-amd fail
test-amd64-amd64-xl-pvh-amd fail
test-amd64-i386-qemut-rhel6hvm-amd pass
test-amd64-i386-qemuu-rhel6hvm-amd pass
test-amd64-amd64-xl-qemut-debianhvm-amd64 pass
test-amd64-i386-xl-qemut-debianhvm-amd64 pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass
test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
test-amd64-i386-freebsd10-amd64 pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
test-amd64-i386-xl-qemuu-ovmf-amd64 pass
test-amd64-amd64-rumprun-amd64 pass
test-amd64-amd64-xl-qemut-win7-amd64 fail
test-amd64-i386-xl-qemut-win7-amd64 fail
test-amd64-amd64-xl-qemuu-win7-amd64 fail
test-amd64-i386-xl-qemuu-win7-amd64 fail
test-armhf-armhf-xl-arndale pass
test-amd64-amd64-xl-credit2 pass
test-armhf-armhf-xl-credit2 pass
test-armhf-armhf-xl-cubietruck pass
test-amd64-i386-freebsd10-i386 pass
test-amd64-i386-rumprun-i386 pass
test-amd64-amd64-qemuu-nested-intel pass
test-amd64-amd64-xl-pvh-intel fail
test-amd64-i386-qemut-rhel6hvm-intel pass
test-amd64-i386-qemuu-rhel6hvm-intel pass
test-amd64-amd64-libvirt pass
test-armhf-armhf-libvirt pass
test-amd64-i386-libvirt broken
test-amd64-amd64-migrupgrade pass
test-amd64-i386-migrupgrade pass
test-amd64-amd64-xl-multivcpu pass
test-armhf-armhf-xl-multivcpu pass
test-amd64-amd64-pair pass
test-amd64-i386-pair pass
test-amd64-amd64-libvirt-pair pass
test-amd64-i386-libvirt-pair pass
test-amd64-amd64-amd64-pvgrub pass
test-amd64-amd64-i386-pvgrub pass
test-amd64-amd64-pygrub pass
test-armhf-armhf-libvirt-qcow2 pass
test-amd64-amd64-xl-qcow2 pass
test-armhf-armhf-libvirt-raw pass
test-amd64-i386-xl-raw pass
test-amd64-amd64-xl-rtds fail
test-armhf-armhf-xl-rtds pass
test-amd64-i386-xl-qemut-winxpsp3-vcpus1 pass
test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass
test-amd64-amd64-libvirt-vhd pass
test-armhf-armhf-xl-vhd pass
test-amd64-amd64-xl-qemut-winxpsp3 pass
test-amd64-i386-xl-qemut-winxpsp3 pass
test-amd64-amd64-xl-qemuu-winxpsp3 pass
test-amd64-i386-xl-qemuu-winxpsp3 pass
------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
broken-step test-amd64-amd64-libvirt-xsm host-install(3)
broken-step test-amd64-i386-libvirt host-install(3)
Not pushing.
(No revision log; it would be 950 lines long.)
[-- Attachment #2: Type: text/plain, Size: 127 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 9+ messages in thread
* elbling1 (was Re: [xen-unstable test] 103788: regressions - trouble: broken/fail/pass)
2016-12-22 9:01 [xen-unstable test] 103788: regressions - trouble: broken/fail/pass osstest service owner
@ 2016-12-22 10:28 ` Ian Jackson
2016-12-22 10:45 ` Jan Beulich
0 siblings, 1 reply; 9+ messages in thread
From: Ian Jackson @ 2016-12-22 10:28 UTC (permalink / raw)
To: xen-devel
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-xsm/info.html
(the last xen-boot failure before it started giving host-install
failures).
I have reconfigured the BIOS boot order. Now the d-i setup left by
the most recent failed job is running, as expected.
Also, while I was there, I noticed that the iDRAC had its network
enabled, so I disabled that.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 9+ messages in thread
* elbling1 (was Re: [xen-unstable test] 103788: regressions - trouble: broken/fail/pass)
2016-12-22 10:28 ` elbling1 (was Re: [xen-unstable test] 103788: regressions - trouble: broken/fail/pass) Ian Jackson
@ 2016-12-22 10:45 ` Jan Beulich
2016-12-22 11:49 ` Andrew Cooper
0 siblings, 1 reply; 9+ messages in thread
From: Jan Beulich @ 2016-12-22 10:45 UTC (permalink / raw)
To: Ian Jackson; +Cc: xen-devel
>>> On 22.12.16 at 11:28, <ian.jackson@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?), 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).
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: elbling1 (was Re: [xen-unstable test] 103788: regressions - trouble: broken/fail/pass)
2016-12-22 10:45 ` Jan Beulich
@ 2016-12-22 11:49 ` Andrew Cooper
2016-12-22 12:19 ` Ian Jackson
0 siblings, 1 reply; 9+ messages in thread
From: Andrew Cooper @ 2016-12-22 11:49 UTC (permalink / raw)
To: Jan Beulich, Ian Jackson; +Cc: xen-devel
On 22/12/16 10:45, Jan Beulich wrote:
>>>> On 22.12.16 at 11:28, <ian.jackson@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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: elbling1 (was Re: [xen-unstable test] 103788: regressions - trouble: broken/fail/pass)
2016-12-22 11:49 ` Andrew Cooper
@ 2016-12-22 12:19 ` Ian Jackson
2016-12-22 12:26 ` Jan Beulich
2016-12-22 12:36 ` Andrew Cooper
0 siblings, 2 replies; 9+ messages in thread
From: Ian Jackson @ 2016-12-22 12:19 UTC (permalink / raw)
To: Andrew Cooper; +Cc: xen-devel, Jan Beulich
Andrew Cooper writes ("Re: [Xen-devel] elbling1 (was Re: [xen-unstable test] 103788: regressions - trouble: broken/fail/pass)"):
> No. No similar problems I am aware of anywhere in XenRT (which haven't
> ended up being down to human intervention in the firmware)
Indeed. I asked some XenRT folks about a while ago and they said they
hadn't seen it.
> > , 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.
We're basically using entirely BIOS booting, not EFI.
I have two theories:
* Wild accesses do something weird. (Why would it preferentially
affect the boot order? Other things sometimes change too but less
frequently. I can't remember ever losing the serial console setup,
so it's not just "corrupted, reset to defaults".)
* Something somewhere (in the firmware?) spots that the host is
"failing to boot" and deliberately messes with the boot order "in
the hope that it will help". This is a bit odd because in the
"Xen crashes on boot" case, a sequence of failing Xen boots (after
a Xen crash, Xen will reboot) will normally be followed by poweroff
and then a netboot of a working d-i image.
Perhaps it would be worth telling Xen not to reboot on crash...
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: elbling1 (was Re: [xen-unstable test] 103788: regressions - trouble: broken/fail/pass)
2016-12-22 12:19 ` Ian Jackson
@ 2016-12-22 12:26 ` Jan Beulich
2016-12-22 13:47 ` Ian Jackson
2016-12-22 12:36 ` Andrew Cooper
1 sibling, 1 reply; 9+ messages in thread
From: Jan Beulich @ 2016-12-22 12:26 UTC (permalink / raw)
To: Ian Jackson; +Cc: Andrew Cooper, xen-devel
>>> On 22.12.16 at 13:19, <ian.jackson@eu.citrix.com> wrote:
> Perhaps it would be worth telling Xen not to reboot on crash...
I think that's worth giving a try (I assume that some timeout will cause
the machine to get rebooted at some point anyway, to make it available
again).
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: elbling1 (was Re: [xen-unstable test] 103788: regressions - trouble: broken/fail/pass)
2016-12-22 12:19 ` Ian Jackson
2016-12-22 12:26 ` Jan Beulich
@ 2016-12-22 12:36 ` Andrew Cooper
1 sibling, 0 replies; 9+ messages in thread
From: Andrew Cooper @ 2016-12-22 12:36 UTC (permalink / raw)
To: Ian Jackson; +Cc: xen-devel, Jan Beulich
On 22/12/16 12:19, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [Xen-devel] elbling1 (was Re: [xen-unstable test] 103788: regressions - trouble: broken/fail/pass)"):
>> No. No similar problems I am aware of anywhere in XenRT (which haven't
>> ended up being down to human intervention in the firmware)
> Indeed. I asked some XenRT folks about a while ago and they said they
> hadn't seen it.
>
>>> , 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.
> We're basically using entirely BIOS booting, not EFI.
If the hardware supports EFI, then legacy BIOS will most likely be
implemented by CSM, meaning that the EFI variables in NVRAM are probably
still present in an E820 reserved region.
Another alternative is via IPMI. Lots of IPMI controllers these days
support a one-time setting of the next-boot device. This can be either
externally on the iDRAC/iLO/other interface, or internally via the
impi_* kernel modules.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: elbling1 (was Re: [xen-unstable test] 103788: regressions - trouble: broken/fail/pass)
2016-12-22 12:26 ` Jan Beulich
@ 2016-12-22 13:47 ` Ian Jackson
2016-12-22 14:51 ` Jan Beulich
0 siblings, 1 reply; 9+ messages in thread
From: Ian Jackson @ 2016-12-22 13:47 UTC (permalink / raw)
To: Jan Beulich; +Cc: Andrew Cooper, xen-devel
Jan Beulich writes ("Re: [Xen-devel] elbling1 (was Re: [xen-unstable test] 103788: regressions - trouble: broken/fail/pass)"):
> On 22.12.16 at 13:19, <ian.jackson@eu.citrix.com> wrote:
> > Perhaps it would be worth telling Xen not to reboot on crash...
>
> I think that's worth giving a try (I assume that some timeout will cause
> the machine to get rebooted at some point anyway, to make it available
> again).
Like this, then, AFAICT from the docs. FAOD, this shouldn't affect
deliberate attempts by the dom0 to reboot the host ? I found the docs
not quite clear on this point.
Ian.
From acdf52770bbec07680bf4e61ad3984a1d0156af3 Mon Sep 17 00:00:00 2001
From: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Thu, 22 Dec 2016 13:43:01 +0000
Subject: [OSSTEST PATCH] ts-xen-install: Pass `noreboot' to Xen
This prevents Xen from rebooting the host, if Xen crashes.
This reboot serves no function in osstest, since a crashed host will
be automatically power cycled to recover it. (Firstly, during log
collection, a renewed attempt to boot from the hard disk; then, during
the next test, netboot to wipe the machine to reinstall it.)
But the reboot does make logs more confusing, and we suspect that the
reboot loops which can occur (eg if the version of Xen and Linux being
tested always crashes on boot) might be implicated in our test boxes
occasionally forgetting their boot order.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
ts-xen-install | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ts-xen-install b/ts-xen-install
index 2a1784d..c921e69 100755
--- a/ts-xen-install
+++ b/ts-xen-install
@@ -142,7 +142,7 @@ sub adjustconfig () {
}
sub setupboot () {
- my $xenhopt= "conswitch=x watchdog";
+ my $xenhopt= "conswitch=x watchdog noreboot";
my $cons= get_host_property($ho, 'XenSerialConsole', 'com1');
--
2.1.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: elbling1 (was Re: [xen-unstable test] 103788: regressions - trouble: broken/fail/pass)
2016-12-22 13:47 ` Ian Jackson
@ 2016-12-22 14:51 ` Jan Beulich
0 siblings, 0 replies; 9+ messages in thread
From: Jan Beulich @ 2016-12-22 14:51 UTC (permalink / raw)
To: Ian Jackson; +Cc: Andrew Cooper, xen-devel
>>> On 22.12.16 at 14:47, <ian.jackson@eu.citrix.com> wrote:
> Jan Beulich writes ("Re: [Xen-devel] elbling1 (was Re: [xen-unstable test]
> 103788: regressions - trouble: broken/fail/pass)"):
>> On 22.12.16 at 13:19, <ian.jackson@eu.citrix.com> wrote:
>> > Perhaps it would be worth telling Xen not to reboot on crash...
>>
>> I think that's worth giving a try (I assume that some timeout will cause
>> the machine to get rebooted at some point anyway, to make it available
>> again).
>
> Like this, then, AFAICT from the docs.
Yes.
> FAOD, this shouldn't affect
> deliberate attempts by the dom0 to reboot the host ?
Correct. (I use "noreboot" or its more modern "reboot=no"
equivalent everywhere, and can confirm deliberate reboots
work fine.)
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2016-12-22 14:51 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-12-22 9:01 [xen-unstable test] 103788: regressions - trouble: broken/fail/pass osstest service owner
2016-12-22 10:28 ` elbling1 (was Re: [xen-unstable test] 103788: regressions - trouble: broken/fail/pass) Ian Jackson
2016-12-22 10:45 ` Jan Beulich
2016-12-22 11:49 ` Andrew Cooper
2016-12-22 12:19 ` Ian Jackson
2016-12-22 12:26 ` Jan Beulich
2016-12-22 13:47 ` Ian Jackson
2016-12-22 14:51 ` Jan Beulich
2016-12-22 12:36 ` Andrew Cooper
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).