WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-users

Re: [Xen-users] I upgraded, now vms won't start

Quoting "Fajar A. Nugraha" <list@xxxxxxxxx>:

On Sun, Nov 13, 2011 at 9:38 AM, Chris <cjdl01@xxxxxxxxxxxxxxxxxx> wrote:
dom0box:/etc/xen/configs# xm console domubox

[    0.000000] Command line: root=/dev/xvda2 ro

So your root is /dev/xvda2?
Yep.


[    0.047112] XENBUS: Device with no driver: device/vbd/51713
[    0.047119] XENBUS: Device with no driver: device/vbd/51714

those are the disks. If you see those lines, it means at that time the
frontend drivers (xen-blkfront) is not loaded. Load it.

Yes!!!! That is is it. I knew it had to be a driver or something... I didn't realize that xen-blkfront was an actual kernel module... Sorry if that sounds dumb, but it always just worked. I thought it was a module or a class or something, I didn't get that it was a module (or maybe I did 5 years ago when I set this server up, but since forgot...), now I get it.



Begin: Assembling all MD arrays ... mdadm: No devices listed in  conf
file were found.
Failure: failed to assemble all arrays.

this one should be irrelevant. You're using /dev/xvda2 as root, not
/dev/md*, remember?

I agree.  I never understood why it was trying to assemble a raid...


Begin: Waiting for root file system ... done.
Gave up waiting for root device.  Common problems:
- Boot args (cat /proc/cmdline)
 - Check rootdelay= (did the system wait long enough?)
 - Check root= (did the system wait for the right device?)
- Missing modules (cat /proc/modules; ls /dev)
ALERT!  /dev/xvda2 does not exist.  Dropping to a shell!

well, do what it tells you to.
- cat /proc/cmdline
- cat /proc/modules
- ls /dev/?da*

Yep, did that, didn't see much helpful in it...


I have read some on pygrub, I understand what it is supposed to accomplish,
but I am very confused on how it is supposed to work.  I am running Squeeze,
which uses grub 2, which does NOT use a menu.lst.

pygrub (at least newer versions of it) can read grub2's grub.cfg just fine.

Or you can just create a dummy menu.lst.

but I really think that we are barking up the
wrong tree...

No, you don't.

Using pygrub of pvgrub means you're using domU's kernel, which might
contain the necessary drivers (e.g. xen-blkfront) while dom0's kernel
doesn't. It also means you can treat domU just like any other machine,
upgrading packages (including kernel) on the domU, and you can have
different versions of kernel between dom0 and domU.


I get it. I'm confused on how it should be used with grub2. All the references I found refer to menu.lst -- which grub2 doesn't use... so I'm not sure how to use pygrub (I'm not used to grub2 yet...). I'll be happy to try it sometime when I'm not under the gun...

 even if I get it running under pygrub, I don't know what that
would prove.  I need it running normally through xen.

pygrub IS part of xen.

Thinking that you HAVE to use a kernel on dom0 to boot domU is simply wrong.


Then I'm wrong... I'll take your word for it here :) I have to get pygrub working before I can really say anything about it... All I know is I needed to get my machine up asap... Again I'll mess with pygrub when I have time.



Why the heck is it trying to rebuild the array anyway?

possibly because you use dom0's kernel and initrd. Are you using md in dom0?

--
Fajar


Thank you for your help, Fajar.  I can sleep now...





_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users