On Tue, 2007-03-27 at 08:48 +0800, John Summerfield wrote: > Graham Jenkins wrote: > > .. > > The strategy goes something like: > > > > * losetup -o 32256 /dev/loop0 /XenGuests/Guest1 > > * mkfs -t ext3 /dev/loop0 > > * mount -t ext3 /dev/loop0 /mnt > > * cd /mnt && tar xjpf /tmp/Guest1.tbz > > * for i in console null zero; do /sbin/MAKEDEV -d /mnt -x $i; done > > * cd /tmp; umount /srv/vm1; losetup -d /dev/loop0 > > * xm create -c Guest1 > > > > And it always gets most of the way through .. then the guest dies. > What does "most of the way through" mean? Here's the last bit of what you see: -- Loading ext3.ko module Loading xenblk.ko module Registering block device major 202 xvda: xvda1 xvda2 Creating root device. Mounting root filesystem. mount: could not find filesystem '/dev/root' Setting up other filesystems. Setting up new root fs setuproot: moving /dev failed: No such file or directory no fstab.sys, mounting internal defaults setuproot: error mounting /proc: No such file or directory setuproot: error mounting /sys: No such file or directory Switching to new root and running init. unmounting old /dev unmounting old /proc unmounting old /sys switchroot: mount failed: No such file or directory Kernel panic - not syncing: Attempted to kill init! -- > Do those files have partition tables? Yes, you can do: fdisk /XenGuests/Guest1 .. just like a real disk. It was created by using virt-install to build a dummy guest before making the new filesystem. Just two partitions .. / on ext3, and swap. > Why not attach those volumes ro to another guest? The theory here is that we should be able to recover an entire guest to a new Xen host from a live tar backup done the previous night on another night. Or would could recover to a larger container file if we needed more room, etc. So recovering just part of a filesystem is useful, but doesn't really achieve what we want. I'm guessing that what we need to do is a 'chroot /mnt' then 'grub --batch' somehow .. but grub doesn't want to know about disks with names like /dev/xvda and partitions with names like /dev/xvda1 ? -- Graham Jenkins +61 3 9925 4909 Victorian Partnership for Advanced Computing http://www.vpac.org/ PO Box 201, Carlton South, Vic. 3053, Australia