Description of problem:
Using RHEL 6.4 and GRUB version 0.97.81 when installing to a /dev/mapper/mpath device the following error occurs:
# grub-install /dev/mapper/mpatha
/dev/mapper/../dm-1 does not have any corresponding BIOS drive.
When checking the device.map:
# cat /boot/grub/device.map
# this device map was generated by anaconda
And the fdisk output (where /dev/sdb is a part of mpath):
# fdisk -l
Disk /dev/sdb: 53.7 GB, 53687091200 bytes
64 heads, 32 sectors/track, 51200 cylinders
Units = cylinders of 2048 * 512 = 1048576 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000b6bc1
After rebooting and attempting to run a GRUB setup the following timeline occurs:
Probing devices to guess BIOS drives. This may take a long time.
Unknown partition table signature
GNU GRUB version 0.97 (640K lower / 3072K upper memory)
[ Minimal BASH-like line editing is supported. For the first word, TAB
lists possible command completions. Anywhere else TAB lists the possible
completions of a device/filename.]
grub> find /grub/menu.lst
grub> root (hd1,0)
Filesystem type is ext2fs, partition type 0x83
grub> setup (hd1)
Checking if "/boot/grub/stage1" exists... no
Checking if "/grub/stage1" exists... yes
Checking if "/grub/stage2" exists... yes
Checking if "/grub/e2fs_stage1_5" exists... yes
Running "embed /grub/e2fs_stage1_5 (hd1)"... 27 sectors are embedded.
Running "install /grub/stage1 (hd1) (hd1)1+27 p (hd1,0)/grub/stage2 /grub/grub.conf"... failed
Error 22t: No such partition
After this is a `yum upgrade` done and a reboot, which causes the same inability for GRUB to be read (and on HP device an Illegal Opcode message).
From here going to a rescue CD and running the same GRUB setups succeeds:
"install /grub/stage1 (hd4) (hd4)1+27 p (hd4,0)/grub/stage2 /grub/grub.conf"... succeeded
After this system boots fine with no other issues.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
See description for full steps regarding the install to a multipathed device.
System is unbootable and results in error reading GRUB
System succesfully boots after install and update
There was a previous bug that appears to be related: https://bugzilla.redhat.com/show_bug.cgi?id=870420 however that was closed as 'errata' for this version of GRUB giving the same error again.
Could you please provide output of multipath -ll?
# multipath -ll
mpatha (360060e8005bf80000000bf8000000866) dm-0 HP,OPEN-V
size=50G features='1 queue_if_no_path' hwhandler='0' wp=rw
`-+- policy='round-robin 0' prio=1 status=active
|- 1:0:0:0 sdb 8:16 active ready running
`- 2:0:0:0 sde 8:64 active ready running
There are few strange things. The first is that grub-install resolves the symlink - it really should not happen with this version. Is this code present in your grub-install?
echo $install_device | grep -q "^/dev/mapper"
if [ "x$?" != "x0" ]; then
install_device=`resolve_symlink "$install_device"` || exit 1
Second one is that grub sees mpatha as dm-1, but multipath as dm-0.
Could you please add "set -x" at the beginning of the grub-install script and provide the printed output?
I've been able to reproduce this bug on system with iBFT boot with two paths to iSCSI target.
Created attachment 757629 [details]
Fix regexps for mathing devices in device.map, resolve symlinks for getting block device stats
With Pavel's help we found what causes this issue. First problem was that symlinks (obviously) won't provide major:minor device type, so grub-install was not able to match /dev/mapper symlink to the right block device.
Second one goes to matching devices representing partition to the path stated in device.map - grub-install could not then handle the mpath device properly.
So this will be fixed in the next grub release.
Reproduced on RHEL 6.4 x86_64 Server
Verified fix of grub-install on RHEL6.5-20131019.1 x86_64 Server
Main issue with grub-install /dev/mpatha is fixed, but setup (hd1) issue still persists, I've filed new bug for this: bug 1022395
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.