On 5/28/2019 12:41 AM, Roger Pau Monné
wrote:
On Mon, May 27, 2019 at 03:35:21PM -0700, John L. Poole wrote:
On 5/27/2019 9:18 AM, Roger Pau Monné wrote:
On Mon, Apr 29, 2019 at 05:27:34PM +0200, Roger Pau Monné wrote:
IMO it would be better if you can build directly from the upstream git
repository [0], that way you could use git-bisect(1) in order to figure
out which commit broke your system. For example:
# git clone git://xenbits.xen.org/xen.git
# cd xen
# git checkout RELEASE-4.7.0
# make xen -j8
That should give you a set of Xen binaries in the xen/ directory, IIRC
you are booting from EFI so you likely need xen/xen.efi.
If that works, then you can test RELEASE-4.8.0 and if that fails to
boot you should have a range of commits that you can bisect in order
to find the culprit.
FWIW, I've been unable to find a box with the same CPU model (C2750)
that you are using. I've found a couple of old Atom boxes using
different CPUs but they all seem to boot fine using latest
xen-unstable. I've looked on eBay for that CPU but everything
containing it is server-grade and >200$ which I'm sadly not going to
pay.
Unless you are able to bisect the tree and give us the bad commit
that's causing your issues I'm afraid at least myself I won't be able
to progress this any further, sorry.
Roger.
I attempted to work backwards and ran into a nightmare with Gentoo. I kept
getting compiler errors which I suspect was a result of having a newer
version
of GCC and other things. It's not an easy thing to travel
back in time in Gentoo because everything keeps getting upgraded. I just
cannot make the time now to unravel this as I have some demands on my time
and will be engaged for the next four to six weeks.
IMO your best bet is to build Xen using Debian stretch, that's used by
the Xen test system, and is likely to be able to build the different
Xen versions, stable-* branches tested by osstest should build on
stretch.
What I've done in the past if that also triggers compiler errors is to
build a chroot with an older version of Debian and then build Xen
inside of it. You can do this in a box different from the one you are
testing, ie: you could create a Debian VM and build Xen from there.
Note that in order to bisect this issue you only need to build the Xen
kernel (make xen, no need to run ./configure), there's no need to
build the tools, hence you need almost no dependencies installed on
the builder.
I've done a build of the stable-4.7 branch myself and uploaded the
hypervisor binaries to:
http://xenbits.xen.org/people/royger/stable-4.7/
Could you give those a try (I wasn't sure whether you need xen.gz or
xen.efi so I've uploaded both) and see if you still have issues
booting?
Testing those binaries should be as simple as placing them in /boot/
and fixing your bootloader configuration to boot from those. Please
send the serial log when booting from the provided binaries.
How much would it cost for you to obtain the machine you need? I may
consider paying for it. I bought this Atom server just to economically run
Xen so the machine has marginal value to me if I cannot run Xen on it.
Even if we go that route, there's no guarantee that I would be able to
fix the issue, and there's also the possibility that the hardware you
have is somehow broken, and that the new one won't exhibit this issue.
Roger.
Roger,
You
have given me an idea. I have several VMs on my hard disk
that are not
backed
up. So, I think what I'll do is remove the current hard disk
and place
a
fresh hard disk in and then try to install a Debian based Xen
anew so I
do
not risk altering my Gentoo-based hard disk. This approach
should free
me
from the entanglement of a bleeding edge distribution, e.g.
Gentoo.
I was
looking back at my notes. I acquired this Atom-based server
in November
of
2016 and installed the Debian Xen to test and it worked. So I
then installed
Gentoo
and ran into problems with GRUB. I learned that GRUB was not
yet ready
to
support EFI and Xen, so I used the manual method to drop into
an EFI shell
and
launch my DOM0 instance. I later tried to upgrade the kernel
and ran into
problems
and aborted an upgrade, I just kept what I had working since I
had
already
created some Gentoo-based VMs. During my build process, I had
run
into an issue "coff-x86-64 pe-x86-64" which Jan Beulich had assisted
on and
determined
was something worth of the attention of the "binutils folks."
I'll
attempt the hard disk swap in a few days after I receive a
shipment of the new disk.
Thank
you,
