[bug #56312] grub-probe fails to find parent of /dev/md0 (RAID)

[Lars Kruse]

URL:
  <https://savannah.gnu.org/bugs/?56312>

                 Summary: grub-probe fails to find parent of /dev/md0 (RAID)
                 Project: GNU GRUB
            Submitted by: sumpfralle
            Submitted on: Sun 12 May 2019 05:12:26 PM UTC
                Category: None
                Severity: Major
                Priority: 5 - Normal
              Item Group: None
                  Status: None
                 Privacy: Public
             Assigned to: None
         Originator Name: 
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
                 Release: 
                 Release: 2.02
         Reproducibility: None
         Planned Release: None

    _______________________________________________________

Details:

I observed the following on a Debian Stretch host (the same applies to Debian
Buster):

* "update-grub" produces a grub.cfg that lacks the following lines:
  insmod part_gpt
  insmod mdraid1x
* this prevents the system from booting
* the missing modules can be enforced by adding the following line to
/etc/default/grub:
  GRUB_PRELOAD_MODULES="part_gpt mdraid1x"
* after another run of "update-grub" the system boots successfully

I expected, that grub will detect the necessity for "part_gpt" and "mdraid1x"
on its own.

The host is an amd64 architecture with the following versions of grub
installed:
* Debian Stretch: grub-efi-amd64 2.02~beta3-5+deb9u1
* Debian Buster: grub-efi-amd64 2.02+dfsg1-18

The relevant pieces of the setup (seen by "lsblk") are the following:


sda                                        8:0    0  1,7T  0 disk  
├─sda1                                     8:1    0  487M  0 part 
/boot/efi
├─sda2                                     8:2    0  488M  0 part  
└─sda3                                     8:3    0  1,7T  0 part  
  └─md0                                    9:0    0  1,7T  0 raid1 
    ├─lvm--foo-root                      253:0    0    5G  0 lvm   /



I think, the following run of "grub-probe" indicates the direction of the
problem:


address@hidden:~# grub-probe -v --device /dev/md0 --target=partmap
grub-probe: Info: adding `hd0' -> `/dev/md0' from device.map.
grub-probe: Info: adding `hd1' -> `/dev/sda' from device.map.
grub-probe: Info: adding `hd2' -> `/dev/sdb' from device.map.
grub-probe: Info: /dev/md0 is present.
grub-probe: Info: Looking for /dev/md0.
grub-probe: Info: /dev/md0 is a parent of /dev/md0.
grub-probe: Info: /dev/md0 is present.
grub-probe: Info: Looking for /dev/md0.
grub-probe: Info: /dev/md0 is a parent of /dev/md0.
grub-probe: Info: /dev/md0 is present.
grub-probe: Info: Looking for /dev/md0.
grub-probe: Info: /dev/md0 is a parent of /dev/md0.
grub-probe: Info: opening hd0.
grub-probe: Info: drive = 0.
grub-probe: Info: the size of hd0 is 439258368.
grub-probe: Info: no partition map found for hd0.


I guess, "/dev/md0 is a parent of /dev/md0" is the crucial problem in the
output above.

The partition of the device looks like this:


address@hidden:~# fdisk -l /dev/sda
Disk /dev/sda: 1,7 TiB, 1800360124416 bytes, 439541046 sectors
Disk model: AL14SEB18EP     
Units: sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: BE28F95A-76BD-4803-86CA-2BBB13EE804F

Device      Start       End   Sectors  Size Type
/dev/sda1     256    124927    124672  487M EFI System
/dev/sda2  124928    249855    124928  488M BIOS boot
/dev/sda3  249856 439540991 439291136  1,7T Linux LVM


The setup of the RAID is the following:


address@hidden:~# mdadm --detail /dev/md0
/dev/md0:
           Version : 1.2
     Creation Time : Thu Jan 11 00:11:09 2018
        Raid Level : raid1
        Array Size : 1757033472 (1675.64 GiB 1799.20 GB)
     Used Dev Size : 1757033472 (1675.64 GiB 1799.20 GB)
      Raid Devices : 2
     Total Devices : 2
       Persistence : Superblock is persistent

     Intent Bitmap : Internal

       Update Time : Sun May 12 18:58:20 2019
             State : clean 
    Active Devices : 2
   Working Devices : 2
    Failed Devices : 0
     Spare Devices : 0

Consistency Policy : bitmap

              Name : foo:0  (local to host foo)
              UUID : d369b142:f2a0a6b5:2010ad2b:a5841e5e
            Events : 56001

    Number   Major   Minor   RaidDevice State
       0       8       19        0      active sync   /dev/sdb3
       2       8        3        1      active sync   /dev/sda3


The RAID members look like this:


address@hidden:~# mdadm --examine /dev/sda3
/dev/sda3:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x1
     Array UUID : d369b142:f2a0a6b5:2010ad2b:a5841e5e
           Name : foo:0  (local to host foo)
  Creation Time : Thu Jan 11 00:11:09 2018
     Raid Level : raid1
   Raid Devices : 2

 Avail Dev Size : 3514066944 (1675.64 GiB 1799.20 GB)
     Array Size : 1757033472 (1675.64 GiB 1799.20 GB)
    Data Offset : 262144 sectors
   Super Offset : 8 sectors
   Unused Space : before=262056 sectors, after=0 sectors
          State : active
    Device UUID : fd2d1822:1a76270f:e2d4a333:a7880c4a

Internal Bitmap : 8 sectors from superblock
    Update Time : Sun May 12 18:59:49 2019
  Bad Block Log : 512 entries available at offset 72 sectors
       Checksum : a0013e42 - correct
         Events : 56002


   Device Role : Active device 1
   Array State : AA ('A' == active, '.' == missing, 'R' == replacing)


Maybe someone has an idea, why the RAID device (/dev/md0) is not properly
handled?




    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?56312>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/