grub confused by named md raid arrays

[PMOverfield]

Am installing Trusty (AMD-64 Desktop), with /boot as a RAID-1 set (ext2fs) under mdadm on a GPT partition, with a separate, non-RAID, unformatted partition for BIOS-grub. At the stage of attempting to install GRUB it fails, reporting fatal error. I get the window offering the option (among others) to continue without installing GRUB anywhere. I select this option, but the "OK" button never becomes active and no further progress occurs. The installer shows signs of having "crashed" or "locked-up", so I cannot be confident that the remainder of the installation has been completed, otherwise I could assemble the RAID-sets at a mount-point, then chroot and complete the installation of GRUB that way. I know that this build isn't intended for RAID installations, but a clean failure would be helpful. Thank you.

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: ubiquity 2.18.7
ProcVersionSignature: Ubuntu 3.13.0-24.46-generic 3.13.9
Uname: Linux 3.13.0-24-generic x86_64
ApportVersion: 2.14.1-0ubuntu3
Architecture: amd64
CasperVersion: 1.340
Date: Fri Apr 18 17:38:08 2014
InstallCmdLine: file=/cdrom/preseed/ubuntu.seed boot=casper initrd=/casper/initrd.lz quiet splash --
LiveMediaBuild: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417)
ProcEnviron:
 LANGUAGE=en_GB.UTF-8
 PATH=(custom, no user)
 LANG=en_GB.UTF-8
 SHELL=/bin/bash
SourcePackage: grub-installer
UpgradeStatus: No upgrade log present (probably fresh install)

[Phillip Susi (psusi)]

Can you please try again, and when you get to the point of this failure, open a terminal and run the following commands and paste the output:

sudo chroot /target
grub-probe -vv /

[PMOverfield (peter-overfield)]

Thank you, Philip. After the "AskUbuntu" editing mechanism de-formatted my response there I feared you might abandon this one in disgust at the garbage. I've attached "grubprobe.out" with the response you requested. I'm puzzled by the conflict beteen lines 116 and 392: md/root and /dev/md5 are the same item ~ the RAID-pair assigned to "/"!

[Phillip Susi (psusi)]

It looks like the problem is that your arrays are named rather than numbered, so they are detected as md/root, and so on, but /proc/mounts shows them being mounted by their numerical name ( /dev/md0 ). It seems that grub needs to sort out the fact that they can be referred to by either name.

[PMOverfield (peter-overfield)]

Thank you for this insight, Philip.
I know you didn't ask for it, but I've wiped the HDs (DBAN) and rebuilt the system from scratch, but OMITTING the "-N" option from mdadm, so that the RAID sets don't get the confusing optional names. Unfortunately GRUB still fails to install, producing exactly the same error message as before. I'm going to forward the syslog and grub-probe outputs in case you wish to check them for clues. Previous attempts to comment suggest that I might need a separate comment for each. Here goes!

[PMOverfield (peter-overfield)]

As suspected, so here's the second attachment

[Phillip Susi (psusi)]

Looks like a different problem now. Do you have a /boot partition? What does grub-probe /target/boot show?

[PMOverfield (peter-overfield)]

Yes, I do. FYI the setup is:
GPT, 1st partition starts at sector 2048
1MiB NOT RAID, NOT formatted, BIOS-grub
200MiB RAID-1, ext2, /boot
2GiB RAID-1, swapfs
5GiB RAID-1, ext4, /var
5GiB RAID-1, ext4, /tmp
6GiB RAID-1, ext4, /
22GiB RAID-1, ext4, /usr
>900GiB RAID-1, ext4, /home (remainder of 1TB HDD)

Report as requested attached, boot.report.tgz including boot.grub-probe.out & boot.syslog

[PMOverfield (peter-overfield)]

Philip, I apologise: I didn't do exactly what you asked. I chrooted to /target, then executed sudo grub-probe /boot. I've now found that if I stay at /, and execute grub-probe /target/boot, I get different output. So herewith target.boot.grub-probe.out to give you that information. Sorry!

[Phillip Susi (psusi)]

Odd, everything seems fine there.

[PMOverfield (peter-overfield)]

Well, the rig is still set up: feel free to ask for any further investigations.

[Launchpad Janitor (janitor)]

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

[Mathieu Trudel-Lapierre (cyphermox)]

I think for this we should simply figure out a way to reproduce this issue in the smallest; more reduced way possible in virtual machines, and test it carefully.

@PMOverfield; what kind of system are you using? Are there only two disks being mirrored, or are you using a different kind of setup?

[PMOverfield (peter-overfield)]

     Wow! This is going back somewhat. My recollection is as follows:

Home-built PC:
     PROBABLY based on Asus M4A89TD PRO MoBo, with 8GB Kingston RAM,
nVidia Graphics with Quadro NVS285 GPU, AMD Phenom II X4 960T CPU, and
TWO-off Western Digital 1TB HDDs in RAID-1 configuration for most of the
installation partitions. Unfortunately this system is now my principal
computer, and unlikely to be available for further experimentation. I'm
trying to get another, simpler, build to operate as an alternative
experimental vehicle, with two-off WD 512GB HDDs, and could make this
available for trials if necessary.

                 Regards

                         Peter

On 07/05/15 22:20, Mathieu Trudel-Lapierre wrote:
> I think for this we should simply figure out a way to reproduce this
> issue in the smallest; more reduced way possible in virtual machines,
> and test it carefully.
>
> @PMOverfield; what kind of system are you using? Are there only two
> disks being mirrored, or are you using a different kind of setup?
>
> ** Changed in: grub2 (Ubuntu)
> Status: Confirmed => Incomplete
>
> ** Changed in: grub2 (Ubuntu)
> Importance: Undecided => Medium
>

[Launchpad Janitor (janitor)]

[Expired for grub2 (Ubuntu) because there has been no activity for 60 days.]