Duplicate entries in grub2 menu for second ubuntu installed on another partition

With the update to 3.5.0-2-generic in quantal, /boot/grub/grub.cfg was generated. When running update-grub from the precise partition, the grub2 menu is now correct without duplicates (plus additional recovery mode entries).

So I guess this is only an issue after an initial install using: ubiquity -b; to skip installing the boot loader. Once grub.cfg is generated, os-prober doesn't have to guess with 90fallback and we don't get duplicates.

Status changed to 'Confirmed' because the bug affects multiple users.

Ha =) sort | uniq made me smile this morning =) one would think you can boot without that =)

I will check ubiquity code, but I don't think we run `update-grub` in a normal way, due to having a weird environment (root from the squashfs on the cd, instead of the target one). I think we only use 90fallback directly.

Status changed to 'Confirmed' because the bug affects multiple users.

I strongly believe that the root cause is in the linux-boot-prober as it returns a strange result when launched (from my Xubuntu Precise) against a Xubuntu Quantal partition:

(verbatim copy)
$ sudo linux-boot-prober /dev/sda7 2> /dev/null
/dev/sda7:/dev/sda7:Ubuntu' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-7205122a-da09-4f1f-97ef-67d3f70df317:/boot/vmlinuz-3.5.0-15-generic:/boot/initrd.img-3.5.0-15-generic:root=UUID=7205122a-da09-4f1f-97ef-67d3f70df317 ro quiet splash $vt_handoff
/dev/sda7:/dev/sda7:Ubuntu, with Linux 3.5.0-15-generic' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-3.5.0-15-generic-advanced-7205122a-da09-4f1f-97ef-67d3f70df317:/boot/vmlinuz-3.5.0-15-generic:/boot/initrd.img-3.5.0-15-generic:root=UUID=7205122a-da09-4f1f-97ef-67d3f70df317 ro quiet splash $vt_handoff
(/verbatim copy)

More, this strange result also likely causes the following code in 30_os-prober to misbehave (returning two entries with strange names)

      LINUXPROBED="`linux-boot-prober ${DEVICE} 2> /dev/null | tr ' ' '^' | paste -s -d ' '`"
      prepare_boot_cache=

      for LINUX in ${LINUXPROBED} ; do

      (etc)

      done

I hope this helps

Sorry, I have to step back. In my particular case, the problem was that I also have launched sudo update-grub on my Quantal installation. And this created a /boot/grub/grub.cfg file on my Quantal partition.

For some reasons, existing grub.cfg files on other partitions seem to completely fool the update-grub scripts on other partitions (more precise, the linux-boot-order script).

In my case, the problem was solved by removing the grub.cfg file on the Quantal partition (I still launch update-grub on my Precise partition).

I find abnormally that the mere existence of grub.cfg files on other partitions completely fool the update-grub scripts (actually, the linux-boot-prober scripts)

Confirming the behaviour stated by axeoth on 2012-09-26.

For some reasons, existing grub.cfg files on other partitions seem to completely fool the update-grub scripts on other partitions (more precise, the linux-boot-order script).

The problem still exists with Xenial Mate uname -a:

Linux xxxxx12 4.4.0-47-generic #68-Ubuntu SMP Wed Oct 26 19:39:52 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

Even confirmed, that os-prober gets fooled by a grub.cfg file on a non-system partition that contains a partial backup of a system partition (here: complete directory /boot)!