Comment 69 for bug 477169

Mark Abene posted in https://bugs.lauchpad.net/ubuntu/+source/grub/+bug/477104 #60 with a workaround that allowed me to boot and get past kernel panic with VFS. So far I only booted by using the grub> prompt and entering commands, but I was finally able to boot. basically what I did was:

boot from a live usb stick

# create some mount points
mkdir /win /vdisk /vdisk.boot

#mount the windows filesystem
mount /dev/sda1 /win

create a new /ubuntu/disks/boot.disk file, and put an ext2 filesystem on it (I made my 200MB, it probably doesn't need to be this big.)

#mount both the ubuntu / and the new boot.disk filesystems
mount -o loop /win/ubuntu/disks/root.disk /vdisk
mount -o loop /win/ubuntu/disks/boot.disk /vdisk.boot

#copy /vdisk/boot/vmlinuz-2.6.31-14-generic and /vdisk/boot/initrd.img-2.6.31-14-generic to /vdisk.boot, i just put them in the root of the new filesystem
cp /vdisk/boot/vmlinuz-2.6.31-14-generic /vdisk/boot/initrd.img-2.6.31-14-generic /vdisk.boot

#create a fstab entry for this new filesystem
/host/ubuntu/disks/boot.disk /boot_initrd ext2 loop,errors=remount-ro 0 1

reboot

got a grub> prompt and ran these commands:

root (hd0,1)
loopback loop0 /ubuntu/disks/root.disk
loopback loop1 /ubunut/disks/boot.disk
root (loop1)
# note: get the kernel and ramdisk from the boot.disk filesystem
linux /vmlinuz-2.6.31-14-generic root=/dev/sda1 loop=/ubuntu/disks/root.disk ro
initrd /initrd.img-2.6.31-14-generic

boot

now I just need to edit the appropriate files to make this automatic. ought to be interesting.

Thanks to Mark Abene for figuring out this workaround. He speculates that there is a problem with grub seeking into large filesystems, maybe in combination with being a loopback device.