Bug 478885 - anaconda may cause tapes to rewind, causing data corruption
anaconda may cause tapes to rewind, causing data corruption
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: anaconda (Show other bugs)
All Linux
low Severity medium
: rc
: ---
Assigned To: Anaconda Maintenance Team
Release Test Team
Depends On:
  Show dependency treegraph
Reported: 2009-01-05 15:43 EST by Brian Parks (Quantum Corp)
Modified: 2009-04-22 09:48 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-01-05 15:51:59 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 Brian Parks (Quantum Corp) 2009-01-05 15:43:57 EST
Description of problem:
"anaconda" links with libkudzu.a which contains a bug (RedHat bug # 468680)
that may cause tapes to rewind. Specifically, libkudzu.a contains a routine
that opens the rewind-on-close tape device (/dev/st<x>) when obtaining drive
information instead of opening the no-rewind tape device (/dev/nst<x>). 

This is a problem if the system on which "anaconda" is run has access to a tape drive which is also accessible by another system, e.g. a tape drive accessible via a fibre switch. If another system is accessing the tape when the rewind occurs then the data may be read from an incorrect tape location (BOT) or data at BOT may be overwritten, potentially leaving all previously written data on the tape inaccessible.

Once bug #468680 is fixed, this problem will also be fixed once
"anaconda" is linked with the fixed kudzu library. It is necessary to confirm
that the relinked "anaconda" is included in the same release as the fix for
bug #468680 and bug #478881.

Version-Release number of selected component (if applicable):
All versions of RedHat Enterprise Linux 4 including update 7.

How reproducible:

Steps to Reproduce:
The problem is most easily observed if two systems have access to the same tape drive.
1. insert a tape in a drive
2. position tape past BOT, e.g. "mt -f /dev/nst0 fsr 1"
3. run anaconda (boot install media using either "rescue mode" or using the standard "install")
4. check tape status, e.g. "mt -f /dev/nst0 status". This is most easily done by running "mt" on a separate system having access to the same tape drive though it can also be done by running anaconda (booting install media) in rescue mode and running "mt" from the underlying system's root file system.

Actual results:
Tape is at BOT

Expected results:
Tape position should remain unchanged.

Additional info:
See RedHat bug # 468680.
Comment 1 Chris Lumens 2009-01-05 15:51:59 EST
Once the new kudzu is included in the build root, the next rebuild of anaconda will pick up the fix.  Of course since we have several fixes to include in anaconda for 4.8, we will rebuild several times.  Thanks for the heads up on this, but there's really nothing for us to do other than just let the natural course of rebuilding work itself out.
Comment 2 Brian Parks (Quantum Corp) 2009-04-22 09:48:57 EDT
(In reply to comment #1)
The underlying bug (#468680) is fixed in RedHat Enterprise Linux 4 update 8 beta, however the anaconda portion of the fix is not included on the update 8 beta install media (booting the install media still rewinds tapes). Will the fix be included in the official release of update 8?

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