Bug 928938

Summary: Installing to a multipathed device on the most recent version of grub causes grub to be unreadable
Product: Red Hat Enterprise Linux 6 Reporter: BJ Walker <bwalker>
Component: grubAssignee: Václav Pavlín <vpavlin>
Status: CLOSED ERRATA QA Contact: Pavel Holica <pholica>
Severity: urgent Docs Contact:
Priority: urgent    
Version: 6.4CC: borgan, bwalker, jrieden, pbokoc, pholica
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: grub-0.97-82.el6 Doc Type: Bug Fix
Doc Text:
Cause: Two causes - regular expression matching device in device.map were not able to match multipath device and grub-install didn't get the information about the device because command stat doesn't work with simlinks Consequence: Grub wasn't able to boot from multipath device after installation Fix: Correct regexps to match multipath devices, resolve symlink prior to getting stats Result: Grub now boots as expected after the installation
Story Points: ---
Clone Of:
: 1022395 (view as bug list) Environment:
Last Closed: 2013-11-21 20:47:39 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 835616, 960054, 1022395    
Description Flags
Fix regexps for mathing devices in device.map, resolve symlinks for getting block device stats none

Description BJ Walker 2013-03-28 18:57:48 UTC
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
(hd0)     /dev/mapper/mpatha

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:
# grub
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
find /grub/menu.lst
grub> root (hd1,0)
root (hd1,0)
 Filesystem type is ext2fs, partition type 0x83
grub> setup (hd1)
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):

How reproducible:
Every time

Steps to Reproduce:
See description for full steps regarding the install to a multipathed device.
Actual results:
System is unbootable and results in error reading GRUB

Expected results:
System succesfully boots after install and update

Additional info:
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.

Comment 1 Václav Pavlín 2013-03-29 12:17:54 UTC
Could you please provide output of multipath -ll?

Comment 3 BJ Walker 2013-04-11 17:15:59 UTC
# 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

Comment 4 Václav Pavlín 2013-04-12 12:06:09 UTC
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.

Comment 8 Václav Pavlín 2013-05-31 13:11:44 UTC
Could you please add "set -x" at the beginning of the grub-install script and provide the printed output?

Comment 11 Pavel Holica 2013-06-06 10:08:37 UTC
I've been able to reproduce this bug on system with iBFT boot with two paths to iSCSI target.

Comment 12 Václav Pavlín 2013-06-06 11:33:43 UTC
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.

Comment 15 Pavel Holica 2013-10-23 08:24:16 UTC
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

Comment 17 errata-xmlrpc 2013-11-21 20:47:39 UTC
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.