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

Re: [Xen-users] Xen 4.1.4 fails to boot Linux in wheezy

  • To: xen-users@xxxxxxxxxxxxx
  • From: Alexandre Kouznetsov <alk@xxxxxxxxxx>
  • Date: Wed, 27 Mar 2013 15:39:46 -0600
  • Delivery-date: Wed, 27 Mar 2013 21:40:55 +0000
  • List-id: Xen user discussion <xen-users.lists.xen.org>


El 27/03/13 14:11, Mike escribió:
Please post your boot loader configuration.

Looks good.

My own serial console's setup for Xen omits the IO address and IRQ, but if the numbers are correct, should not harm. I usually remove "quite" option from kernel boot line. Although, in this case your system clearly don't reach the kernel booting.

When you say "no output from the Xen boot process", do you mean no output at all? Even "Loading Xen 4.1-amd64 ..." legend?
While debugging this stage, maybe Grub's output give some clue:
cat >> /etc/default/grub << EOF
GRUB_TERMINAL="console serial"
GRUB_SERIAL_COMMAND="serial --unit=0 --speed=115200 --word=8"

The next thing to try would be hardware debugging. Memtest

For the record, memtest86+ (Debian 4.20-1.1) doesn't work with UEFI:
Looks like memtest86 has the same issue, since it also uses linux16.
Oh, that's new for me.

I'd have to prepare a BIOS-bootable USB stick to use this.  It's not
clear how to do this.  Simply copying the included ISO to a USB stick
doesn't boot.
No need for that. Memtest86 can be launched from any boot loader, even Grub. "apt-get install memtest86+" would create the needed Grub menu entry.

I also question the value of running a BIOS-booted test
to solve a UEFI-booted software problem.  Perhaps you can explain your
I'm not familiar with UEFI. My logic is very primitive. If some piece of software generally works, but under some system it does not, the key for solution is to find out what makes this system different. Hardware defect, for example. Or incompatible characteristic (google:"model+xen" often throws something useful).

This is a new machine, and I ran the HP ROM-based memory test when I got
I guess that is as good as Memtest to make sure the RAM is fine.

set BIOS into fail-safe settings.

I don't know what you mean.  Reset the BIOS settings to the factory
defaults?  I have no reason to do that.  In fact, I already did that
once, because I lost track of the settings that I had changed.  But now
I know precisely what changes I've made, so resetting and rechanging the
settings would simply put me where I am now.
You where out of debugging ideas, wasn't you?
Some BIOSes have a literal option "fail-safe settings". Some does not, but using common sense it's possible to disable most of "fancy" and "exotic" options. They still might be needed in production, but it's useful to make sure it's not BIOS configuration what triggers the failure.

BTW, have you tried to remove part of RAM? How much RAM does the machine have?

A good reference would be to test Squeeze's Xen and kernel, if they
show the same behavior.

Yeah, that's the fallback.
You can just give it a try without making a full installation:
Copy xen, kernel and initrd images to your testing system and make Grub to boot them. It's unlikely it would finish booting (mainly because of the kernel modules), but that could be a good proof of concept test. If it behaves in the same way, than probably the problem is not about Xen or OS version.

 I've have Xen on squeeze on another system,
but I'm not confident that it will work here: I suspect that Xen is
having an issue with my dm-crypt root.
AFAIK, it just works. I have a production system since a couple of years ago, with Squeeze, Xen 4.0 and crypted root. It is not rebooted often and not under heavy use, but so far I had no issues related to dm-crypt.


Alexandre Kouznetsov

Xen-users mailing list



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