Comment 13 for bug 742967

As always, thanks for testing.

Populating /boot/grub when it isn't populated by an initial install is
untidy, and I suppose with some contortions it might be possible to do
something about it, but it shouldn't matter if everything else is
working properly. Actually, I might argue that the real bug there is
that an initial install of Wubi doesn't populate /boot/grub! It is
occasionally useful to have access to modules that aren't built into
wubildr, and ultimately it would be nice not to have to build a giant
monolithic wubildr; obviously things like ntfs.mod have to be built-in,
but much of it could perfectly well be loaded at run-time instead.

I don't think bug 610898 is truly fixed yet, although I still hope to
squeeze in a fix for that before the Natty release, once I construct a
test case for myself. The no-more-confusing-prompt change you mention
was for bug 581760, fixed in Maverick. If wubildr is not being
regenerated on upgrade then that is definitely a bug - I know it has
been problematic, but if we don't regenerate wubildr then running an
upgraded version of update-grub may well break things since there's no
guarantee of compatibility between old GRUB core images and modules and
new configuration files, so it has to be done if grub-pc and grub-common
are upgraded at all.

The fact that grub-install didn't work on your install to a non-Windows
partition is just the same as bug 610898. The prompt is a side issue;
the real underlying issue is that '/usr/share/lupin-support/grub-mkimage
--test' doesn't know how to detect that it's a Wubi system in that
environment, and that explains why grub-install is trying to do a real
install rather than regenerating wubildr.

In your installation where Wubi was on the same partition as Windows, is
the lupin-support package installed? What do these commands print:

  sudo /usr/share/lupin-support/grub-mkimage --test; echo $?
  sudo grub-probe --target=device /boot
  sudo losetup "$(sudo grub-probe --target=device /boot)"
  cat /proc/mounts