From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ian Campbell <ian.campbell@citrix.com>
Subject: pvgrub regression in xen.git 123c77937975
Date: Fri, 8 May 2015 17:16:49 +0100
Message-ID: <1431101809.2660.536.camel@citrix.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: xen-devel <xen-devel@lists.xen.org>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>
List-Id: xen-devel@lists.xenproject.org

There seems to be a pvgrub regression somewhere in the range
3a28f760508f..123c77937975 instead of booting the selected kernel I get:
        
        Booting 'Debian GNU/Linux, kernel 3.2.0-4-amd64'
        
        root  (hd0,0)
        
         Filesystem type is ext2fs, partition type 0x83
        
        kernel  /boot/vmlinuz-3.2.0-4-amd64 root=UUID=59fd4a5b-040d-4f59-8fc3-19324ddb4
        
        0b7 ro 
        
        initrd  /boot/initrd.img-3.2.0-4-amd64
        
        ============= Init TPM Front ================
        Tpmfront:Error Unable to read device/vtpm/0/backend-id during tpmfront initialization! error = ENOENT
        Tpmfront:Info Shutting down tpmfront
        xc_dom_build_image returned -1
        
        close(3)
        
        Error 9: Unknown boot failure
        
        Press any key to continue...
        
This was spotted in ad-hoc testing on the Cambridge osstest instance of
my distro testing series[0] (which adds pvgrub tests to the main flights
too). i386 guests fail in the same way.

I've attempted to convince osstest to have a stab at bisecting, but
glancing at the log over tools/libxc tools/stubdom I suspect either
Konrad's cleanups to libxc error handling or Wei's "libxc: add p2m_size
to xc_dom_image".

Anyway, just a heads up in case something springs to mind, otherwise
I'll let the bisector churn at it over the weekend. There's been a few
false starts but if you are within Citrix you can see the progress (I
hope) at http://osstest.xs.citrite.net/~ianc/summary2.html (so far it's
just trying to reproduce the basis cases, and has been tripping over the
xen.git:5d4c0952f issue, now hacked around I hope)

Ian.

[0] http://mid.gmane.org/<1430905605.2660.187.camel@citrix.com>