FS#69564 - grub-install failed on raid devices

Attached to Project: Arch Linux
Opened by Anonymous Submitter - Saturday, 06 February 2021, 15:06 GMT
Last edited by Doug Newgard (Scimmia) - Saturday, 06 February 2021, 15:13 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To No-one
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
  • Anonymous Submitter (2021-02-06)
Private No

Details

Description:

I was installing Archlinux with software raid (raid1), and during the grub instalation efibootmgr failed.

I found some cross referencing:
https://bugs.launchpad.net/ubuntu/+source/grub-installer/+bug/1765484
https://bugzilla.suse.com/show_bug.cgi?id=1179981

Additional info:
* package version(s): 2:2.04-8
* config and/or log files etc.

lsblk:
```
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 931.5G 0 disk
├─sda1 8:1 0 512M 0 part
│ └─md127 9:127 0 511.9M 0 raid1 /efi
└─sda2 8:2 0 931G 0 part
└─md126 9:126 0 1.8T 0 raid0
└─cryptroot 253:0 0 1.8T 0 crypt /
sdb 8:16 0 931.5G 0 disk
├─sdb1 8:17 0 512M 0 part
│ └─md127 9:127 0 511.9M 0 raid1 /efi
└─sdb2 8:18 0 931G 0 part
└─md126 9:126 0 1.8T 0 raid0
└─cryptroot 253:0 0 1.8T 0 crypt /
sdc 8:32 0 931.5G 0 disk
└─sdc1 8:33 0 931.5G 0 part
└─md125 9:125 0 931.4G 0 raid1
└─cryptdata 253:1 0 931.4G 0 crypt /data
sdd 8:48 0 931.5G 0 disk
└─sdd1 8:49 0 931.5G 0 part
└─md125 9:125 0 931.4G 0 raid1
└─cryptdata 253:1 0 931.4G 0 crypt /data
```

grub-install --target=x86_64-efi --efi-directory=/efi --bootloader-id=GRUB --verbose
```
...
grub-install: info: executing efibootmgr --version </dev/null >/dev/null.
grub-install: info: executing modprobe -q efivars.
grub-install: info: executing efibootmgr -c -d.
efibootmgr: option requires an argument -- 'd'
efibootmgr version 17
usage: efibootmgr [options]
-a | --active sets bootnum active
-A | --inactive sets bootnum inactive
-b | --bootnum XXXX modify BootXXXX (hex)
-B | --delete-bootnum delete bootnum
-c | --create create new variable bootnum and add to bootorder
-C | --create-only create new variable bootnum and do not add to bootorder
-D | --remove-dups remove duplicate values from BootOrder
-d | --disk disk (defaults to /dev/sda) containing loader
-r | --driver Operate on Driver variables, not Boot Variables.
-e | --edd [1|3|-1] force EDD 1.0 or 3.0 creation variables, or guess
-E | --device num EDD 1.0 device number (defaults to 0x80)
-g | --gpt force disk with invalid PMBR to be treated as GPT
-i | --iface name create a netboot entry for the named interface
-l | --loader name (defaults to "\EFI\arch\grub.efi")
-L | --label label Boot manager display label (defaults to "Linux")
-m | --mirror-below-4G t|f mirror memory below 4GB
-M | --mirror-above-4G X percentage memory to mirror above 4GB
-n | --bootnext XXXX set BootNext to XXXX (hex)
-N | --delete-bootnext delete BootNext
-o | --bootorder XXXX,YYYY,ZZZZ,... explicitly set BootOrder (hex)
-O | --delete-bootorder delete BootOrder
-p | --part part partition containing loader (defaults to 1 on partitioned devices)
-q | --quiet be quiet
-t | --timeout seconds set boot manager timeout waiting for user input.
-T | --delete-timeout delete Timeout.
-u | --unicode | --UCS-2 handle extra args as UCS-2 (default is ASCII)
-v | --verbose print additional information
-V | --version return version and exit
-w | --write-signature write unique sig to MBR if needed
-y | --sysprep Operate on SysPrep variables, not Boot Variables.
-@ | --append-binary-args file append extra args from file (use "-" for stdin)
-h | --help show help/usage
grub-install: error: efibootmgr failed to register the boot entry: Operation not permitted.
```

* link to upstream bug report, if any

Steps to reproduce:

https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system#LUKS_on_software_RAID
For the step "Configuring GRUB" execute the third cmd (grub-install --target=x86_64-efi --efi-directory=/efi --bootloader-id=GRUB)
   mdadm.conf (0.5 KiB)
   fstab (0.5 KiB)
   grub (1.8 KiB)
   log.txt (611.6 KiB)
This task depends upon

Closed by  Doug Newgard (Scimmia)
Saturday, 06 February 2021, 15:13 GMT
Reason for closing:  Not a bug
Additional comments about closing:  The ESP can't be on RAID. That's normal.

Loading...