grub2-install fails on devices with minor numbers that exceed 8 bits. On large systems used for virtualization of large numbers of virtual machines, the boot drive for a new machine can end up with disks/partitions that have minor numbers > 255, in which case "chroot grub2-install ...." will fail.
Where are you experiencing the behavior? What environment?
In grub-core/osdep/devmapper/getroot.c, there is this function, which makes the erroneous assumption that minor numbers are still 8-bit. This assumption has not been true for quite some time:
grub_util_devmapper_part_to_disk (struct stat *st,
int *is_part, const char *path)
int major, minor;
if (grub_util_get_dm_node_linear_info (st->st_rdev,
&major, &minor, 0))
*is_part = 1;
return grub_find_device ("/dev",
(major << 8) | minor); <<<<< --------- ERROR!
*is_part = 0;
return xstrdup (path);
When does the behavior occur? Frequently? Repeatedly? At certain times?
Repeatable. Depends on how many other VMs have been deployed previously on a host.
I asked the customer what their environment was and how they are running into this issue.
In our particular case, we are using relatively large systems (HP DL380p Gen8s, for example) as virtual machine hosts. Each virtual machine has a boot drive that corresponds to a LUN on an IBM SVC array that is connected either via iSCSI or fibre channel. So, for example, running 100 virtual machines on a host means there are >100 disks attached to the host (many VMs have more than just a single drive), and when you account for partitions on top of the raw devices, it doesn't take too many VMs before the device mapper starts hitting minor numbers beyond 255. Each new VM is created by allocating a LUN, partitioning it, creating file systems, mounting them on the host, and then unpacking a template (which was originally build by installing from an ISO, but, rather than go through rebuilding from ISO every time, we create an archive of an install that has a certain level of our local configuration changes already made). The installation script then attempts to run the GRUB installer under chroot to set up GRUB for the VM. Many of our older VMs used RHEL or CentOS 5.x or 6.x, which were all based off "legacy GRUB", and this issue did not occur in the older code base. When we started deploying 7.x VMs, though, the switch in those releases to GRUB2 exposed this particular bug that has apparently been in the re-implemented code base for a while (according to git logs).
Reproduced in a virtual machine:
1) created 266 disk images and associated them with /dev/loop devices (loop0-loop265)
2) install the anaconda package
3) make sure the minor number of /dev/loop265 is higher than 255:
[root@localhost ~]# ls -l /dev/loop265
brw-rw----. 1 root disk 7, 265 Feb 4 21:46 /dev/loop265
4) proceed through installation to the disk image associated with /dev/loop265:
anaconda --repo <REPO_PATH> --text --image /dev/loop265
The installation fails at the end of the installation when installing boot loader.
21:35:21,881 INFO program: Running... grub2-install --no-floppy /dev/loop261
21:35:30,001 INFO program: Installing for i386-pc platform.
21:35:30,002 INFO program: grub2-install: error: cannot find a GRUB drive for /dev/mapper/loop265p1. Check your device.map.
21:35:30,002 DEBUG program: Return code: 1
Reproduced on RHEL-7.2 GA with anaconda-220.127.116.11-1.el7. Verified on RHEL-7.3-20160817.1 with anaconda-18.104.22.168-1.el7.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.