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

[Jason Conti]

When running update-grub in Precise to add entries for a freshly installed Quantal system on another partition, linux-boot-prober outputs five entries:

/dev/sda5:/dev/sda5::/vmlinuz:/initrd.img:root=/dev/sda5·
/dev/sda5:/dev/sda5::/vmlinuz:/initrd.img:root=/dev/sda5
/dev/sda5:/dev/sda5::/boot/vmlinuz-3.5.0-1-generic:/boot/initrd.img-3.5.0-1-generic:root=/dev/sda5
/dev/sda5:/dev/sda5::/vmlinuz:/initrd.img:root=/dev/sda5
/dev/sda5:/dev/sda5::/vmlinuz:/initrd.img:root=/dev/sda5

which results in at least three unnecessary entries in the menu. I believe this is caused by /usr/lib/linux-boot-probes/mounted/90fallback, the first for loop explains it at least partially, since both /vmlinuz and /vmlinuz* match. I am not sure why we get two results for each though.

As a workaround, in /etc/grub.d/30_os-prober, updating the LINUXPROBED line to include 'sort | uniq |':

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

at least gets rid of the duplicates. Checking that /vmlinuz is just a symbolic link to /boot/vmlinuz-3.5.0-1-generic would get rid of the other one, but I'm not sure of a nice way to implement that with the existing code.

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: os-prober 1.51ubuntu3
ProcVersionSignature: Ubuntu 3.2.0-25.40-generic 3.2.18
Uname: Linux 3.2.0-25-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 2.0.1-0ubuntu8
Architecture: amd64
Date: Mon Jun 25 15:53:59 2012
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Beta amd64 (20120411.1)
ProcEnviron:
 TERM=xterm
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: os-prober
UpgradeStatus: No upgrade log present (probably fresh install)

[Jason Conti (jconti)]

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.

[Launchpad Janitor (janitor)]

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

[Dimitri John Ledkov (xnox)]

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.

[Launchpad Janitor (janitor)]

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

[linuxar (linuxar)]

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

[linuxar (linuxar)]

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)

[Emerson1000 (rfh1000)]

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)!