I used to have these entries in my dedicated GRUB legacy menu.lst file:
title Ubuntu 8.04.3
This works fine as long as the Grub that´s installed in the target partiton is grub legacy. One modern systems this chainloading works fine. Older machines sometimes report error 13 or 15.
Some googling finally gave me two solutions. The first works, but needs manually updates when Ubuntu updates it's kernel. It´s booting the Ubuntu kernell directly without using the grub2 bootloader that is installed on the partition Ubuntu is in.
title Ubuntu 10.4
kernel /boot/vmlinuz-2.6.32-21-generic root=UUID=ad518371-1bcc-43c1-994c-54cb14751bbb ro quiet splash
The second just works.
title Ubuntu Linux 10.4 NL
I didn´t test any kernelupdate yet, but I see the Grub2 boot menu. We´ll see.
Finally found some actual information on the grub 2 failure to install to proper partition boot sector:
google search: how to determine which boot sector grub2 installs to partition boot sector
debian bug: [link]
:: Code ::$ sudo mount /dev/sda7 /1
$ sudo grub-install --root-directory=/1 /dev/sda7
:: Code ::$ sudo mkdir /mnt/linux
$ sudo mount -t ext4 /dev/sda1 /mnt/linux
$ sudo mount -t proc proc /mnt/linux/proc
$ sudo mount -t sysfs sys /mnt/linux/sys
$ sudo mount -o bind /dev /mnt/linux/dev
$ sudo chroot /mnt/linux
If /boot is on a separate partition, this partition must also be mounted:
$ sudo mount -t ext4 /dev/sdaX /boot
Then, the following command should resolve the issue. :
$ sudo grub-install --recheck /dev/sda5
these are just debugging tools.
:: Code ::In the report you only said grub-install /dev/sda6 and grub-setup "(hd0,6)"
but you can even use grub-install "(hd0,6)"
NOTE: none of these methods fixes the bug. This system has 3 sata hard drives, and the grub 1.5 is in mbr, chainloading to /dev/sda9 / (hd0,8).
Tests show that grub 1.5 in partition /dev/sda9 is chainloaded fine, grub2 from ubuntu does not work at all, always results in the error 13 message.
More on this grub 2 bug on bugs.launchpad.net/: [link]
ubuntu grub 2 docs: [link]
note that these are not very useful since they contradict themselves.
This thread: [link]
seems to show the same issues with grub 2.
Clearly grub 2 was put into production use FAR too early, and is not at all robust enough yet to actually be trusted for mainstream desktop/server use. Why they feel the need to rush out core tools in this way is absolutely beyond me.
here's an interesting method, but doesn't help this case since grub2 doesn't seem to install to /dev/sda9 in the first place: [link]
:: Code ::title Chainload to grub2
find --set-root /boot/grub/core.img
and finally I got in with this added to grub 1.5 menu.lst master in mbr, after running the above:
:: Code ::root (hd0,8)
in other words, instead of using the failed install of grub2 img to partition boot sector, I'm getting it directly from /boot/grub/core.img