Comment 60 for bug 477104

It isn't the kernel update that broke anything, it's grub2 losing the ability to see the new kernel file. In all my tests (I've been able to reproduce every single error everyone has gotten), grub2 was always the root cause.

As a test, I created a complete duplicate of my Wubi install as ext3 instead of ext4 root.disk. Grub2 suffers from the same problem of being able to read some files fine, others as garbage, and some not at all (freezing). I can't say if the problem is being triggered by the filesystem being on a loopback device, or if grub2 is perhaps having serious problems seeking into extremely large disk partitions (or a combination of the two), since /boot isn't a separate filesystem in Wubi.

Currently I was able to restore my install by creating a simple 200MB ext2 "boot.disk" as a separate loopback device mounted as /boot, and keeping the original root.disk as ext4. I made a very small change to /usr/share/lupin-support/grub-mkimage so that grub-install writes a correct wubildr to /host (C:\)pointing to the new boot.disk, as well as adding a "/boot" entry to /etc/fstab.

So far my system has been running just fine, including having compiled and installed a custom kernel and initrd to my new /boot filesystem.

At some point I intend to test having /boot as ext3 or ext4.

What I can include from all this is that something is seriously BROKEN with grub2, though I personally haven't had the time to investigate this in the grub2 source.

I recommend the Wubi maintainers perform similar tests as I've outlined above, i.e. small, separate /boot filesystem on it's own loopback-mounted file, as it's a successful workaround until grub2 gets fixed.