Bug 250631 - [RHEL5.1 Beta] booty: not using LABEL for non-dm devices causes boot failure
Summary: [RHEL5.1 Beta] booty: not using LABEL for non-dm devices causes boot failure
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: booty   
(Show other bugs)
Version: 5.1
Hardware: All
OS: Linux
Target Milestone: ---
: ---
Assignee: David Cantrell
QA Contact:
Keywords: OtherQA, Regression
Depends On:
Blocks: 228988
TreeView+ depends on / blocked
Reported: 2007-08-02 16:00 UTC by Kiyoshi Ueda
Modified: 2018-10-19 23:15 UTC (History)
7 users (show)

Fixed In Version: RHBA-2007-0748
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-11-07 17:59:27 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
booty from SEG (89.06 KB, application/x-rpm)
2007-08-07 03:42 UTC, Takuma Umeya
no flags Details
booty from SEG (44.80 KB, application/x-rpm)
2007-08-07 03:42 UTC, Takuma Umeya
no flags Details

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2007:0748 normal SHIPPED_LIVE booty bug fix update 2007-10-30 18:28:44 UTC

Description Kiyoshi Ueda 2007-08-02 16:00:50 UTC
Description of problem:
booty doesn't use filesystem label (e.g. LABEL=) for non-dm devices neither.
This causes boot failure when the system has some different type of
SCSI HBAs, because anaconda and mkinitrd have a module load ordering
problem which causes device name change.
Related bugzillas for the ordering problem: BZ#210548, BZ#218957, BZ#223938.

This problem is a regression from RHEL5.0 and the change was included
in booty-0.80.4-2 for multipath root fix.
* Tue Jun 19 2007 David Cantrell <dcantrell@redhat.com> - 0.80.4-2
- Do not use filesystem label (e.g., LABEL=) for multipath devices
  Related: rhbz#185852

Version-Release number of selected component:
RHEL5.1 Beta (RHEL5.1-Server-20070725.0)

How reproducible:

Steps to Reproduce:
 1. Prepare a system with different types of SCSI HBAs, each having
    one or more SCSI disk(s).
    For example, qla1280 with 1 disk and aic7xxx with 1 disk,
    and assume anaconda detects qla1280 first, then aic7xxx.
 2. Install OS into the disk of aic7xxx which is seen as /dev/sdb
    from anaconda.
 3. Reboot

Actual results:
booty doesn't use filesystem label:
        append="console=ttyS1,115200n8 rhgb quiet"
On the other hand, mkinitrd creates an initrd which insmod
aic7xxx first, then qla1280.
Note that it inverts the device naming order.
As a result, "/dev/sdb4" will be seen as "/dev/sda4" after reboot.
So the system can't boot.

Expected results:
booty doesn't use filesystem label for dm devices like multipath devices
and LVM volumes, but uses filesystem label for other devices.

Additional info:

Comment 2 Issue Tracker 2007-08-07 01:27:47 UTC
Just a forwarder: 

Event posted 08-07-2007 07:03am by kueda-RH

I tested booty-0.80.4-4.IT128375.1.noarch.rpm, but it used label
when multipath device is used for root volume.
So the fix is not correct, it may cause other boot failure
in case of multipath root.

The patch included in it checks existence of '/mpath' in the label
string of the device to see if the device is multipath or not.
But, the label of multipath devices is not special like including /mpath.
It is similar to non-multipath devices.
So it has to check the device name, not the label string.

Also, since the patch is made based on older booty (0.80.4-1),
it doesn't apply cleanly to the latest booty-0.80.4-4.

I modified the patch (attached) to fix the issues above.
I confirmed it worked for all of the following cases:
   [LABEL should be used: "root=LABEL=..."]
   1. SCSI + noLVM
   2. FC + nompath + noLVM

   [LABEL should NOT be used: "root=/dev/..."]
   3. SCSI + LVM
   4. FC + nompath + LVM
   5. FC + mpath + noLVM
   6. FC + mpath + LVM

diff -rup booty-0.80.4-4/bootloaderInfo.py
--- booty-0.80.4-4/bootloaderInfo.py 2007-08-06 12:42:48.000000000 -0400
+++ booty-0.80.4-4.fix/bootloaderInfo.py 2007-08-06 12:44:05.000000000
@@ -2061,7 +2061,7 @@ def getRootDevName(initrd, fsset, rootDe

        rootEntry = fsset.getEntryByMountPoint("/")
-        if rootEntry.getLabel() is not None and
rootEntry.find('/mpath') == -1:
+        if rootEntry.getLabel() is not None and
rootEntry.device.getDevice().find('/mpath') == -1:
            return "LABEL=%s" %(rootEntry.getLabel(),)
        return "/dev/%s" %(rootDev,)

Internal Status set to 'Waiting on SEG'

This event sent from IssueTracker by tumeya 
 issue 128375

Comment 4 Issue Tracker 2007-08-07 03:37:46 UTC
A comment from SEG: 

New test packages with the fix suggested. Keep in mind I'm not adding a
second patch to change the same line, but actually updating the patch that
changes that line in order to fix it. So although you see the same patches
in these packages, the contents of booty-0.80.4-multipath.patch will be

Version changed from '5.1' to 'UNKNOWN'

This event sent from IssueTracker by tumeya 
 issue 128375

Comment 5 Takuma Umeya 2007-08-07 03:42:05 UTC
Created attachment 160794 [details]
booty from SEG

Comment 6 Takuma Umeya 2007-08-07 03:42:29 UTC
Created attachment 160795 [details]
booty from SEG

Comment 7 Kiyoshi Ueda 2007-08-10 18:55:13 UTC
The fix of the updated booty-0.80.4-multipath.patch in Comment#6
is same as the fix in Comment#2.
So the test results in Comment#2 is still valid.
This problem is a regression from RHEL5.0.
Please apply the fix.

Comment 8 Jun'ichi Nomura (Red Hat) 2007-08-13 17:15:44 UTC
> Version changed from '5.1' to 'UNKNOWN'

Will the fix be included in 5.1?
Please note that this is a regression from 5.0.

Comment 11 David Cantrell 2007-08-14 15:50:10 UTC
Adding devel-ack and reassigning to me since I broke this in the first place.

Comment 13 David Cantrell 2007-08-14 16:03:25 UTC
Fix from comment #2 verified to work.  Updating booty and rebuilding for 5.1. 
The fix will be in booty-0.80.4-5.  Setting bug to MODIFIED.

Comment 16 errata-xmlrpc 2007-11-07 17:59:27 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


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