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

[Alexandre Kouznetsov <alk@xxxxxxxxxx>]

Hello.

El 27/03/13 14:11, Mike escribió:
> > Please post your boot loader configuration.
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=703586#25
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"
EOF
update-grub

> > The next thing to try would be hardware debugging. Memtest
> For the record, memtest86+ (Debian 4.20-1.1) doesn't work with UEFI:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=695246
> 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
> logic.
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
> it.
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.
Greetings.

--
Alexandre Kouznetsov


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