PANIC: Ubuntu server VM down after upgrade

[PeterLinuxGeek]

Hi All,

I have a BAD situation and no reliable backup ...

One of my VM (KVM) was Ubuntu server Jaunty (9-04)
I did a upgrade from jaunty to karmic and everything went fine until the next reboot.

On screen I see
Boot from (hd0,0) ext3 48df...
Starting up ...
Gave up waiting for root device ...
...
ALERT /dev/disk/by-uuid/48df.... does not exist. Dropping to a shell


Looks like GRUB did not update in my Jaunty to Karmic move.

I get thrown into initramfs with ash

cd /dev/disk gives me 2 sub-dir: by-path & by-id

by-path
has 5 entries all starting with:
pci-0000:00:0...

by-id
has 4 entries
scsi-SQEMU_QEMU_HARDDISK
scsi-SQEMU_QEMU_HARDDISK-part1 (to 3)


I can (sometimes) interrupt the reboot and edit the GRUB start line

getting to GRUB I change the first 2 lines

uuid 48df...
kernel /boot/vmlinuz-2.6.28-17-server root=UUID=48df... ro quiet splash

into

root=(hd0,0)
root=/dev/sda1 ro quiet nosplash

This usually gets me out of trouble... but not this time

The systems start booting but reboots after 5-6 seconds without me being able to see a message.


The good news is that I can mount sda1 (and sda3 - sda2 being swap) when I am in the mini shell.
If I could find a way to boot the VM from a live CD and then mount the drives I might get out of trouble...
Changing the boot device to CDROM in the proxmox web interface did not work :-(


Can this be recovered?


Thanks


Peter

 

[PeterLinuxGeek]

Re: Progress: Ubuntu server VM down after upgrade

Almost 1 am...

But I booted into the VM using a CD-ROM (Karmic server) and selected the rescue option.

Had to ssh into the host and execute
qm cdrom 101 /dev/cdrom
to get that working

At least I can fully recover from this situation so the STRESS is gone

But rather than SCP'ing data etc over I would like to make the system bootable again.
And I am not sure if this is a plain Linux issue or a combination with the fact that it runs under KVM...

Anyway fstab shows
the / (root) partition with the exact UUID

blkid /dev/sda1 returns the same ID..

I did run the bootloader repair option but no luck.

fsck.ext3 /dev/sda1
ALL CLEAN

sda3 reported clean after a recovering journal.


Another reboot and UUID 48df47b3-b807-4fa0-a84f-7fc8a10a15ac is still causing grief.


Maybe it is to late and I don't see the obvious...
Will start a backup and work again tomorrow morning

Peter