cloudstack-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Mackey <>
Subject Re: Access root disk after botched upgrade
Date Sun, 21 Jun 2015 14:49:42 GMT
If that process didn't work, here's another (using XenCenter)

1. Stop the original VM (the one you want to fix).  Note it's VM name and
find it in your XenServer resource pool.
2. Create a new VM within CS and start it. Note the VM name and find it
within your XenServer resource pool
3. On the original VM, give the root disk a readily identifiable
description (it'll help in this process)
4. Detach the root disk from the original VM
5. Find the original root disk and attach it to your second VM and note the
device id assigned to it
6. Login to the second VM and mount the original root disk
7. Fix grub
8. Unmount the original root disk
9. Detach original root disk from the second VM
10. Reattach the original root disk to the original VM
11. Start the original VM.

At this point everything should be working (provided grub was the issue).

While I've given the process using XenCenter, it can be done with CLI.
It's just a bit harder to keep track of the correct uuids using the CLI.
Note that in all of this, if you need to move VMs from one host to another,
that's fine, just make certain they are back on their original hosts when
you're done lest CS get confused.


On Sun, Jun 21, 2015 at 7:14 AM, Stephan Seitz <> wrote:

> Hi,
> on XenServer I'ld expect your SR containing *.vhd files. You could use
> the cli "xe" command to determine which file is attached. Maybe this
> info can also be seen in the gui.
> Here's a short walkthrough, how to access vhd files:
> If your vhd file contains partitions, you could do a
> kpartx -a /dev/xen/....
> to get
> /dev/mapper/blktap0p[0....n]
> Depending on your guest OS, e.g. If there's LVM or dm-crypt etc...
> inside the following steps vary.
> Just use standard linux tools to mount / pvscan / cryptsetup / ...
> the /dev/mapper/blktap... partitions.
> With additional bind-mounts of /sys, /proc, /run, /dev, /dev/pts you
> should be able to chroot into the filesystem and perform the necessary
> tasks.
> Just as a note: Be careful, to do this only exclusively, say with the
> respective VMs powered-off. Also, double check to umount / pvchange
> -n / ... every layer you've built. Also kpartx -d the partitions and
> unmap the blktap before trying to boot the VM.
> Good luck!
> - Stephan
> Am Sonntag, den 21.06.2015, 12:43 +0200 schrieb France:
> > Hi,
> >
> > after upgrading Ubuntu Linux, the system does not boot, probably because
> of wrong grub config format:
> > (           errorInfo: [Traceback (most recent call last):,   File
> "/usr/bin/pygrub", line 808, in ?,     fs =,
> part_offs[0], bootfsoptions), IndexError: list index out of range, ])
> >
> > How can I get access to disk of this VM, to fix the grub file by hand
> and try to restart it?
> > I have CS 4.3 on XS 6.0.2 with ISCSI disk for virtual instances.
> >
> > Tnx.
> > France.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message