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

AW: [Xen-users] debian Lenny -> Squeeze domU mdX software raidmigration - failed to assemble arrays



Hi,

to make transitions more convenient, I've done this by using uuid instead of 
device names.
If you ls -l /dev/disk/by-uuid inside your domU, you'll see something like

lrwxrwxrwx 1 root root 10  5. Mai 07:38 39a2a64b-0716-47ad-92f4-a7437cac54ee -> 
../../sda2
lrwxrwxrwx 1 root root 10  5. Mai 07:38 e8b97b59-a790-417c-8231-fe8da8b6e6ee -> 
../../sda1

In /etc/fstab inside the domU, '/dev/sda2' would be replaced by 
'UUID=39a2a64b-0716-47ad-92f4-a7437cac54ee' and '/dev/sda1' by 
'UUID=e8b97b59-a790-417c-8231-fe8da8b6e6ee'

If pvgrub or pygrub is used, the devicename needs to be replaced inside the 
domU in /boot/grub/menu.lst from e.g. 'root=/dev/sda2' to 
'root=UUID=39a2a64b-0716-47ad-92f4-a7437cac54ee'

If, like in your case, the domU kernel is directly booted by a cfg statement, 
the root statement needs to be changed in the cfg file by using the the same 
formatting as in the menu.lst above.

Now, it doesn't matter any longer if the device is called xvda or sda or 
(ancient but possible) hda.

Indeed, there are xenified kernels out in the wild which doesn't respect the 
UUID... but I've never seen problems with recent kernels.

Cheers,
Stephan

Btw. Maybe someone knows if a similar abstraction is possible for tty0 vs tty1 
vs hvc0 vs xvc0 ?


> Von: xen-users-bounces@xxxxxxxxxxxxxxxxxxx [mailto:xen-users-
> bounces@xxxxxxxxxxxxxxxxxxx] Im Auftrag von Cameron Camp
> Gesendet: Dienstag, 3. Mai 2011 20:08
> An: Joseph Glanville
> Cc: xen-users@xxxxxxxxxxxxxxxxxxx
> Betreff: Re: [Xen-users] debian Lenny -> Squeeze domU mdX software
> raidmigration - failed to assemble arrays
> 
> Yes, my whatever.domain.cfg was insane, I fixed it by leaving:
> 
> root = /dev/xvda2
> 
> but had to update:
> 
> #kernel      = '/boot/vmlinuz-2.6.26-1-xen-amd64'
> #ramdisk     = '/boot/initrd.img-2.6.26-1-xen-amd64'
> kernel      = '/boot/vmlinuz-2.6.32-5-xen-amd64'
> ramdisk     = '/boot/initrd.img-2.6.32-5-xen-amd64'
> 
> after that it booted with errors, but allowed me to
> vi /etc/apt/sources.lists in DomU and change lenny to squeeze and then
> update/upgrade, and now my DomU Debian Lenny is Squeeze :)
> 
> No idea why the kernel mismatch would result in an md/sd/xvd error, but
> hope this helps someone else!
> 
> Thx,
> Cameron
> 
> 
> On Wed, 2011-05-04 at 03:11 +1000, Joseph Glanville wrote:
> > Hi Cameron
> >
> >
> > Can you please post your domU xen configuration file, also at the
> > initramfs prompt can you type and post output of:
> > cat /proc/cmdline
> >
> >
> > I think you have incorrectly configured the target of the root disk.
> >
> >
> > Kind regards.
> > Joseph.
> >
> > On 3 May 2011 03:12, Cameron Camp <cameron@xxxxxxxxxxxxx> wrote:
> >         I got the previous migration with standard /dev/sdX Dom0 to
> >         work by
> >         changing
> >
> >         /dev/sda2
> >
> >         to
> >
> >         /dev/xvda2
> >
> >         in /etc/xen/whatever.domain.com.cfg
> >
> >         but now I'm migrating Lenny DomU VM to a Squeeze Dom0 which
> >         uses
> >         software raid filesystem like:
> >
> >         /dev/md2
> >
> >         but DomU
> >         uses /dev/sda2 /home/xen/domains/whatever.domain.com/disk.img
> >         still, and won't see the proper hdd, I get:
> >
> >         mount: mounting none on /dev failed: No such device
> >         W: devtmpfs not available, falling back to tmpfs for /dev
> >         Couldnt get a file descriptor referring to the console
> >         KDGKBMODE: Bad file descriptor
> >         loadkeys: error reading keyboard mode
> >         Begin: Loading essential drivers ... done.
> >         Begin: Running /scripts/init-premount ... done.
> >         Begin: Mounting root file system ... Begin:
> >         Running /scripts/local-top ... Begin: Loading[    1.304655]
> >         md: raid1
> >         personality registered for level 1
> >         Success: loaded module raid1.
> >         done.
> >         Begin: Assembling all MD arrays ... Failure: failed to
> >         assemble all
> >         arrays.
> >         done.
> >         done.
> >         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!
> >
> >
> >         BusyBox v1.17.1 (Debian 1:1.17.1-8) built-in shell (ash)
> >         Enter 'help' for a list of built-in commands.
> >
> >         /bin/sh: can't access tty; job control turned off
> >         (initramfs)
> >         =================================
> >         it seems like I somehow don't have the right "driver" loading
> >         in DomU to
> >         see Dom0 md2 filesystem, but couldn't find anything
> >         in /boot/whatever
> >         (or even /boot) in DomU where I could pass an argument to
> load
> >         whatever,
> >         is there something in the whatever.domain.com.cfg I can set
> to
> >         specify
> >         md2 on Dom0 filesystem to be recognized by DomU?
> >
> >         Thanks,
> >         Cameron
> >
> >
> >         _______________________________________________
> >         Xen-users mailing list
> >         Xen-users@xxxxxxxxxxxxxxxxxxx
> >         http://lists.xensource.com/xen-users
> >
> >
> >
> > --
> > Kind regards,
> > Joseph.
> >
> >
> > Founder | Director
> >
> > Orion Virtualisation Solutions | www.orionvm.com.au | Phone: 1300 56
> > 99 52 | Mobile: 0428 754 846
> >
> 
> 
> 
> _______________________________________________
> Xen-users mailing list
> Xen-users@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-users


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

 


Rackspace

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