bugGNU GRUB - Bugs: bug #62756, grub-install fails with...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #62756: grub-install fails with /dev/md_NAME style device names

Submitter:  Hunor Csordás <hunor>
Submitted:  Tue 12 Jul 2022 05:36:30 PM UTC
   
 
Category:  Installation Severity:  Major
Priority:  5 - Normal Item Group:  None
Status:  None Privacy:  Public
Assigned to:  None Originator Name: 
Open/Closed:  Open Release:  Git master
Release:  Reproducibility:  Every Time
Planned Release:  None

Tue 12 Jul 2022 05:38:53 PM UTC, comment #1: 

Possible patch attached. This maps all the "numbered" device filenames that were previously recognized to the same grub device as before:

  • /dev/md_dNN -> mdNN
  • /dev/md_dNNpMM -> mdNN,MM
  • /dev/md/dNN -> mdNN
  • /dev/md/dNNpMM -> mdNN,MM
  • /dev/md/NN -> mdNN
  • /dev/md/NNpMM -> mdNNpMM
  • /dev/mdNN -> mdNN
  • /dev/mdNNpMM -> mdNN,MM


And it allows the following "named" device filenames:

  • /dev/md/NAME -> md/NAME (this is unchanged)
  • /dev/md_NAME -> md/NAME (this is new)


In addition, the entire device filename is checked, instead of relying only on the prefix, allowing the name in the "named" filenames to begin with a 'd' or a number. This is still not perfect -- naming an array "d1" will still give md1 instead of md/d1, but giving an array such a misleading name is probably a bad idea anyway.

The device is still rejected even if an mduuid/UUID style device could be found. This is unchanged behavior.

Finally, named devices are now always treated as unpartitioned. This is because it's pretty much impossible to figure out the layout from the name alone: /dev/md/ap1p2 could refer to either

  1. an array named ap1p2,
  2. partition 2 of an array named ap1p, or
  3. partition 2 of an array named ap1.


This patch always chooses option 1. The previous behavior was inconsistent:

  • if the UUID could be obtained:
    • /dev/md/a2 was mapped to mduuid/UUID
    • /dev/md/a1p2 was mapped to mduuid/UUID,2
    • /dev/md/ap1p2 was mapped to mduuid/UUID,2
  • if the UUID could not be obtained:
    • /dev/md/a2 was mapped to md/a2
    • /dev/md/a1p2 was mapped to md/a1,2
    • /dev/md/ap1p2 was mapped to md/a,1p2



(file #53423)

Hunor Csordás <hunor>
Tue 12 Jul 2022 05:36:30 PM UTC, original submission:  

I get the following error from grub-install on Linux with named md devices:


# grub-install --no-nvram
Installing for x86_64-efi platform.
grub-install: error: unknown kind of RAID device `/dev/md_efi'.


The reason is that grub_util_get_raid_grub_dev in grub-core/osdep/linux/getroot.c doesn't support this device name format, and fails before even trying to figure out the mduuid/* one.

The device name is not arbitary - the mdadm utility creates device names like this in /dev if the "CREATE names=yes" option is present in its configuration file. Incidentally, mdadm (because of a bug) requires this option to allow the creation of the usual /dev/md/NAME symlinks since Linux 5.18 (unless the kernel is configured with the "new" CONFIG_BLOCK_LEGACY_AUTOLOAD config option).

Hunor Csordás <hunor>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files
file #53423:  named-md-device.patch added by hunor (4KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by hunor (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-07-12 hunor Attached File- Added named-md-device.patch, #53423

    Back to the top

    Powered by Savane 3.13.
    Corresponding source code