cloudstack-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From France <mailingli...@isg.si>
Subject Re: Access root disk after botched upgrade
Date Mon, 22 Jun 2015 13:48:22 GMT
Hi guys.

Thank you both for your suggestion.

I did not know one can attach root disk from offline instance to another running instance
using CS.
If I were to choose, i would go with the XenCenter method, because I really do not feel comfortable
with playing on live clustered LVM over ISCSI setup.
Actually it turned out, that it was easier just rolling a new instance and import data from
offsite backup.
The owner installed grub to /dev/xvda, where filesystem resides (no partitions). I guess it
could be fixed, but one would have to fsck FS first.

Tnx again and Regards,
F.

On 21 Jun 2015, at 16:49, Tim Mackey <tmackey@gmail.com> wrote:

> 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.
> 
> -tim
> 
> On Sun, Jun 21, 2015 at 7:14 AM, Stephan Seitz <
> s.seitz@secretresearchfacility.com> 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:
>> http://wiki.xen.org/wiki/Mounting_a_.vhd_disk_image_using_blktap/tapdisk
>> 
>> 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 = fsimage.open(file,
>> 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.
>> 
>> 


Mime
View raw message