Bug 461760 - Unable to boot after mpath installation
Unable to boot after mpath installation
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: anaconda (Show other bugs)
x86_64 Linux
medium Severity medium
: rc
: ---
Assigned To: Peter Jones
Depends On:
  Show dependency treegraph
Reported: 2008-09-10 09:00 EDT by Tryggvi Farestveit
Modified: 2011-08-03 08:04 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-07-01 17:25:05 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Tryggvi Farestveit 2008-09-10 09:00:49 EDT
Description of problem:
When installing RHEL 5.2 (and 5.1) x86-64 using mpath installation option (linux text mpath) and booting from san the node does not boot normally after install.

I´ve tried this with both RHEL 5.1 and 5.2. While booting the following error occurs:

Checking filesysetms
/dev/VolGroup00/LogVol00: clean, 123426/7325696 files, 9917773/7323648 blocks
fsck.ext3: no such file or directory while trying to open /dev/mapper/mpath0p1
The superblock could not be read or does not describe a correct ext2 filesystem.
If the device is valid and it really contains an ext2 fileystem (and not swap or
ufs or something else), then the superblock is corrupt, and you might try running e2fsck with an alternate
    e2fsck - b8193

How reproducible:
I´ve tried this three times on the same node using 5.1 once and 5.2 twice. I have a IBM blade connected to HP EVA thru brocade switch and I am using qlogic "ISP2422-based".

Steps to Reproduce:
1. During booting to the install enter "linux text mpath"
2. Following packages were installed according to anaconda-ks.cfg:
@cluster-storage, @admin-tools, @editors, @development-tools, @gnome-software-development, @text-internet, @x-software-development
@virtualization, @gnome-desktop, @dialup, @core, @base
@java, @base-x, @development-libs, @graphical-internet
emacs, imake, mesa-libGLU-devel, kexec-tools, bridge-utils
device-mapper-multipath, xorg-x11-utils, xorg-x11-server-Xnest
xorg-x11-server-Xvfb, perl-XML-SAX, perl-XML-NamespaceSupport

3.Boot into the newly installed system
I´ve changed to single path to the SAN disk

remount: mount -o rw,remount /dev/root

edit /etc/fstab

/dev/mapper/mpath0p1	/boot	ext3	defaults	1 2
LABEL=/boot	/boot	ext3	defaults	1 2


This is not clean enough workaround, but it seems that mpath is not loaded when booting so we are unable to talk to /dev/mapper/mpath*. The LVM finds it disks and are using /dev/sdX, by changeing to label the /dev/sdX is used.
Comment 1 Denise Dumas 2009-06-30 16:35:00 EDT
Moving to RHEL 5.5 so it doesn't get mistakenly closed by the bot
Comment 2 David Cantrell 2010-07-01 17:08:02 EDT
Please retest with a more recent release of RHEL 5.  If the problem is still occurring, feel free to reopen the bug.
Comment 3 RHEL Product and Program Management 2010-07-01 17:25:05 EDT
Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request.
Comment 4 kpaden1 2010-09-14 14:57:26 EDT
I am running RHEL 5.5. The multipath boot fails for me also.

Note You need to log in before you can comment on or make changes to this bug.