update-grub fails to detect other md OS

[Paul Crawford]

I have a system with two main HDD configured as several md RAID-1 devices and I installed the 32-bit version of 12.04.2 on to one of these partitions (using the "alternate installer" ISO), with most of the others being user data (e.g. one for /home, another for virtual machines, etc). I had one md partition free and then installed the 64-bit version (12.04.3) on to that, again using the alternate installer.
However, after the installation it is unaware of the 1st system, so running update-grub fails to add that to the boot menu and I am not able to dual-boot 32 & 64 bit systems. This worked OK previously with a hardware RAID card, but that was true hardware RAID and presented the disks as a single SCSI device.

$ lsb_release -rd
Description: Ubuntu 12.04.3 LTS
Release: 12.04

$ apt-cache policy multipath-tools
multipath-tools:
  Installed: (none)
  Candidate: 0.4.9-3ubuntu5
  Version table:
     0.4.9-3ubuntu5 0
        500 http://gb.archive.ubuntu.com/ubuntu/ precise/main amd64 Packages

I expect the OS probing to detect other operating systems, in particular to detect another instance of Ubuntu.

Additional information:
$ more /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : active raid1 sda3[0] sdb3[1]
      72427392 blocks super 1.2 [2/2] [UU]

md2 : active raid1 sda6[0] sdb6[1]
      51167104 blocks super 1.2 [2/2] [UU]

md0 : active raid1 sda1[0] sdb1[1]
      2046912 blocks super 1.2 [2/2] [UU]

md4 : active raid1 sda8[0] sdb8[2]
      307068736 blocks super 1.2 [2/2] [UU]

md3 : active raid1 sda7[0] sdb7[1]
      1023868736 blocks super 1.2 [2/2] [UU]

$ mount | grep '^/dev/' | sort
/dev/md1 on / type ext4 (rw,errors=remount-ro)
/dev/md3 on /home type ext4 (rw)
/dev/md4 on /vm type ext4 (rw,nobarrier)
/dev/sdc5 on /scratch type ext4 (rw,nobarrier)

NOTE: sda & sdb form the md devices but sdc is not part of any RAID, md0 is unused (was planned for /boot but not used), and md2 has the 32-bit '/' partition which can still be mounted and accessed.

[Peter Petrakis (peter-petrakis)]

Why do you think this is a multipath problem and not an mdadm problem?

[Paul Crawford (psc-sat)]

Why might it be a mdadm problem?
All of the md devices are up and accessible from the 64-bit OS, and the /etc/mdadm/mdadm.conf file appears to match the output of the command ' mdadm --detail --scan' suggesting it is correct. Even if I mount the previous 32-bit systems root partition (that just works if I click on the device in nautilus) there is still no sign of update-grub recognising that has an OS installed on it.

[Peter Petrakis (peter-petrakis)]

Right. multipath is for SANs, not RAIDs. Seeing that both of your arrays are up and running however implies a grub configuration problem. Moving...

[Peter Petrakis (peter-petrakis)]

not a multipath issue

[Paul Crawford (psc-sat)]

Ah - my apologies for not having this logged under 'grub2' as I had just accepted the launchpad suggestion which, I'm guessing, was based on the bug title.

[Peter Petrakis (peter-petrakis)]

That's what humans are for :)

[Paul Crawford (psc-sat)]

:)

For the record:

$ apt-cache policy grub2
grub2:
  Installed: (none)
  Candidate: 1.99-21ubuntu3.10
  Version table:
     1.99-21ubuntu3.10 0
        500 http://gb.archive.ubuntu.com/ubuntu/ precise-updates/universe amd64 Packages
     1.99-21ubuntu3 0
        500 http://gb.archive.ubuntu.com/ubuntu/ precise/universe amd64 Packages

[Paul Crawford (psc-sat)]

Noticed that syslog has various messages about the os-prober generated during update-grub but tellingly NO reference to and md device, just the constituent partitions.

[Paul Crawford (psc-sat)]

See also my question #234837 for the os-prober, as it appears to only know about dmarid and not about mdadm RAID.

[Paul Crawford (psc-sat)]

I think I have a patch that fixes this, basically adding another step to generate the 'partitions' that include the md arrays, and to drop the md arrays themselves as being part of any array obtained from /proc/mdstat

If this is OK, can it be made available for 12.04 support?

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "Update for os-prober to detect mdadm RAID" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

[Paul Crawford (psc-sat)]

I think this applies to the following versions since I first tested the 1.61 version of os-prober to see if it was already fixed (was not) and my patach should work for all of them, though I have only tested on 1.51 & 1.61:
Saucy (1.61ubuntu1)
Raring (1.57ubuntu1)
Quantal (1.56ubuntu1)
Precise (1.51ubuntu3)
The patch is not ideal, for example, it has not fixed the on_sataraid() function to avoid probing components of a mdadm array (as it does for dmraid arrays), though later they are skipped if found in /proc/mdstat
It also presumes the md arrays are up to be probed. This last point is not unreasonable as activating potential arrays for probing may be hazardous if they had been stopped for other maintenance reasons.

[Paul Crawford (psc-sat)]

Seems this bug still is present with the latest grub update, as had to patch /usr/bin/os-prober again to allow dual-boot from MD array.

$ apt-cache policy grub2
grub2:
  Installed: (none)
  Candidate: 1.99-21ubuntu3.14
  Version table:
     1.99-21ubuntu3.14 0
        500 http://gb.archive.ubuntu.com/ubuntu/ precise-updates/universe i386 Packages
     1.99-21ubuntu3 0
        500 http://gb.archive.ubuntu.com/ubuntu/ precise/universe i386 Packages

[Paul Crawford (psc-sat)]

This is still broken with 14.04 and the same patch seems to work:

$ lsb_release -rd
Description: Ubuntu 14.04.2 LTS
Release: 14.04

$ apt-cache policy grub2
grub2:
  Installed: (none)
  Candidate: 2.02~beta2-9ubuntu1
  Version table:
     2.02~beta2-9ubuntu1 0
        500 http://gb.archive.ubuntu.com/ubuntu/ trusty-updates/universe amd64 Packages
     2.02~beta2-9 0
        500 http://gb.archive.ubuntu.com/ubuntu/ trusty/universe amd64 Packages

[mpw (matthiaspeterw)]

The problem still exists in 16.04.3 and unfortunately the patch doesn't work anymore. One hunk fails and the outcome is unchanged.

[Burkhard Obergöker (glimfindel)]

I stumbled into the same issue though using Ubuntu 20.04. The reason why the given patch cannot be applied is the slightly changed script /usr/bin/os-prober.
I was able to adopt it to the current version and hope it can be also applied to the upcoming versions.

[Launchpad Janitor (janitor)]

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