Bug 467289 - we are storing error strings as fs labels because execWithCapture is broken
we are storing error strings as fs labels because execWithCapture is broken
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: anaconda (Show other bugs)
ia64 Linux
medium Severity medium
: rc
: ---
Assigned To: David Lehman
Alexander Todorov
: 427457 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2008-10-16 13:45 EDT by David Lehman
Modified: 2010-10-23 01:13 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-01-20 16:36:43 EST
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 David Lehman 2008-10-16 13:45:05 EDT
Description of problem:
We're storing error strings as filesystem labels. This specific manifestation is a call to iutil.execWithCapture from isys._readFATLabel().

On ia64 systems with multiple PVs *or* multiple VGs, the following error dialog will halt any attempt to bring up the system in rescue mode:

      +----------------------+ Duplicate Labels +-----------------------+       
      |                                                                 |       
      | Multiple devices on your system are labelled Logical sector     |       
      | size is zero..  Labels across devices must be unique for your   |       
      | system to function properly.                                    |       
      |                                                                 |       
      | Please fix this problem and restart the installation process.   |       
      |                                                                 |       
      |                           +--------+                            |       
      |                           | Reboot |                            |       
      |                           +--------+                            |       
      |                                                                 |       
      |                                                                 |       

The basic problem is that iutil.execWithCapture makes no use of the stderr input argument and instead always dupes stderr to stdout. So, when dosfslabel throws an error to stdout trying to read a fat label from a PV, we end up thinking the PV has a label of "Logical sector size is zero." Another one is a VG with a label of "Read 512 bytes at 0:Is a directory".

Callers who want stderr duped to stdout should use execWithCapture(...,stderr=1).

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. create a partition that doesn't contain any fslabel
2. call isys._readFATLabel (or, on ia64, isys.readFSLabel) on the device

1. try to rescue an ia64 box containing more than one PV or more than one VG
Actual results:
An error string is returned as though it was a label, or an error indicating rescue mode is aborting.

Expected results:
No return value if no label is present, and successful rescue of systems we installed.

Additional info:
This only causes problems on ia64, but that's only because we don't collect FAT labels on other arches.
Comment 1 Alexander Todorov 2008-10-17 02:43:34 EDT
For additional info & partitioning layout see:
Comment 2 Denise Dumas 2008-10-21 16:06:46 EDT
Marking as release blocker because this prevents functioning of rescue mode on IA64
Comment 3 RHEL Product and Program Management 2008-10-21 16:27:34 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
Comment 4 David Lehman 2008-10-28 12:36:13 EDT
Fix will be in anaconda-
Comment 7 Alexander Todorov 2008-11-11 07:46:29 EST
I can't reproduce this issue neither with partitioning layout described in bug #456283 comment #28 neither with the layout described in comment #0
Comment 8 Alexander Todorov 2008-11-11 07:56:09 EST
With an older release on encrypted raid5 array shows the error:
# python
>>> import isys
>>> isys.readFSLabel("/dev/md0", 0)
'Logical sector size is zero.'

Trying with snap #2 leads to:
>>> import isys
>>> label = isys.readFSLabel("/dev/md0", 0)
>>> label is None

Moving to VERIFIED. Just for the record: rescue mode not always fails.
Comment 9 Alexander Todorov 2008-11-12 05:06:05 EST
*** Bug 427457 has been marked as a duplicate of this bug. ***
Comment 11 errata-xmlrpc 2009-01-20 16:36:43 EST
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 therefore 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.