The Real Problem is discussed at the bottom of this message:
On Tue, Dec 11, 2012 at 11:38 AM, Ian Campbell <Ian.Campbell@citrix.com>
wrote:> On Tue, 2012-12-11 at 16:30 +0000, Terry Phelps wrote:
>> I am trying to develop a procedure for backup and restore of a Xen
>> PVM. I am having a problem with booting the restored machine.
I''ll
>> tell you the symptom, and then what I''m doing to get to that
symptom.
>>
>> When I boot the VM, it panics with a message that says:
>>
>> "According to mtab, /dev/xvda2 is already mounted on
/sysroot"
>
> On the face of it this doesn''t look especially like a Xen specific
> issue, google comes up with a bunch of instances of people having this
> sort of problem without Xen. Probably your best bet is OVM support.
>
> /etc/mtab is the place where mount stores what it has done (i.e. the
> current set of mounted filesystems). A lot of distros link this
> to /proc/mounts these days. Sounds as if you have backed up whatever the
> state was at the time and restoring it has confused something.
>
> Really I''d have said OVM ought to cope by clearing mtab at an
> appropriate time during boot.
>
>> Note that did NOT do anything to the MBR, nor did I install grub on
>> the disk. DO I NEED TO?
>
> Not for a PV VM, only HVM guests need an MBR.
>
>> Can some smart Xen Person please assist me?
>
> One thing I did spot on google was make sure your root= is the UUID of
> the / not the /boot filesystem.
>
After some debugging with the dracut scripts, I found that the problem
was that certain directories MUST exist on the root filesystem he''s
trying to mount. I had tried to be efficient in my backup/restore
process, and not backup or restore things like /proc and /sys and such
things. It turns out that the init scripts were checking to make sure
that /proc existed on the filesystem he was trying to mount as /.
My fix was to simply create the (empty) directories (boot, dev, proc,
sys, and tmp) on my restored disk.
So, this has nothing to do with Xen.
