[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-users] HVM help please



On Tue, 2012-06-26 at 00:41 +0100, Shane Johnson wrote:
> On Mon, Jun 25, 2012 at 5:03 PM, Alexandre Kouznetsov <alk@xxxxxxxxxx> wrote:
> > Hello.
> >
> > El 25/06/12 17:54, Shane Johnson escribiÃ:
> >
> >> It would seem that for some reason with this setup it can't use
> >> vmlinuz files that compressed with bzip2.   Therefore I followed these
> >> instructions :
> >>
> >> http://old-list-archives.xen.org/archives/html/xen-users/2010-09/msg00586.html
> >> and now it is working fine.
> >
> > What's so special in your setup?
> > Home-complied kernel or hypervisor image?
> >
> > Debian stock Xen boots bzip2-compressed Dom0 kernels just fine, :
> > # file /boot/vmlinuz-2.6.32-5-xen-amd64
> > /boot/vmlinuz-2.6.32-5-xen-amd64: Linux kernel x86 boot executable bzImage,
> > version 2.6.32-5-xen-amd64 (unknown@Deb, RO-rootFS, swap_dev 0x2, Normal VGA
> >
> > Your experience is valuable, it's just unclear, what configuration does it
> > apply to.
> >
> >
> > --
> > Alexandre Kouznetsov
> >
> > _______________________________________________
> > Xen-users mailing list
> > Xen-users@xxxxxxxxxxxxx
> > http://lists.xen.org/xen-users
> 
> Besides what I posted in the OP I don't see anything different.  Here
> is what I observed:
> Kernels installed on server:
> 1 - linux-image-3.2.0-0.bpo-amd64
> 2 - linux-image-3.2.18 (recompiled)
> 3 - linux-image-3.2.0-0.bpo-amd64 with Xen
> 4 - linux-image-3.2.18 with Xen
> 5 - (all of the above with failsafe)
> 
> All kernels would boot and run fine before xen-qemu-dm-4.0 installed.
> After - with Xen kernels would only boot after reinstalling package
> and full power down of server

I'm hard pressed to think of a reason that installing xen-qemu-dm-4.0
should effect the boot of the host. This package contains a binary
application which is only run when starting an HVM guest and has nothing
at all to do with host kernels etc.

I've checked the package content and the maintainer scripts and can't
see anything untoward.

Perhaps it is just a coincidence and something else which is happening
around the same time as installing this package during host setup is the
culprit?

It might be interesting to take copies of /boot/grub/*.cfg and record
md5sums of everything under /boot before installing the package so as to
see what has actually changed.

> No With Xen kernel would run with xen-pciback.hide line in /boot/grub/grub.cfg

This sounds like an unrelated issue?

You mentioned Squeeze backports -- you shouldn't need xen-qemu-dm-4.0
with anything newer than the 4.0 version of Xen in Squeeze itself.
Although I still can't think of a way this would cause host boot
failures.

Hrm, perhaps xen-qemu-dm-4.0 is causing an older (4.0) Xen to get pulled
in and replace the newer backports one? Can you provide a transcript of
the full "apt-get install xen-qemu-dm-4.0"?

A full boot log of a failing system would also be useful.

Can you also confirm which precise hypervisor packages you are
installing (versions and where they come from). You only mentioned
backports but not the specifics.

> All non with Xen options would boot fine.
> 
> After 3.2.18 was extracted and made a raw image - no problems with
> booting and xen-pciback.hide.
> Same behavior on two MB.  (See OP) so I don't think it is a hardware
> problem, but I have two other Xen servers running and they don't have
> this problem but they are not actual server components.  I thought it
> might be a problem with the ECC so I turned it off with no change.  At
> that point I remembered the instructions I posted earlier today so I
> didn't do any other tests, just got it working.  I am more than
> willing to do more tests, I just need to know what you would like me
> to run.
> 
> Thanks
> 



_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.