Bug 677203

Summary:	scsi_id to the /dev/tmp-scsi-maj-mi-<pid> device doesn't unlink for cciss devices
Product:	Red Hat Enterprise Linux 5	Reporter:	wangshibo <jaswang>
Component:	udev	Assignee:	Harald Hoyer <harald>
Status:	CLOSED ERRATA	QA Contact:	qe-baseos-daemons
Severity:	high	Docs Contact:
Priority:	high
Version:	5.4	CC:	azelinka, fnadge, kvolny, pknirsch
Target Milestone:	rc
Target Release:	5.4
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:	Cause The user runs fsck.gfs2 on a GFS2 file system in verbose mode (with the -v parameter). Consequence The user sees alarming error messages indicating that the master and root inode are not marked "In use" by the file system and an indication that the problem has been corrected: System inode for 'master' is located at block 23 (0x17) The inode exists but the block is not marked 'in use'; fixing it. System inode for 'root' is located at block 22 (0x16) The inode exists but the block is not marked 'in use'; fixing it. There is no problem with either inode; the error messages are just misleading. Fix The code has been changed to set both the master and root inodes as "in use" in the in-core block map. Result As a result, fsck.gfs2 now realizes the master and root inodes are properly marked, so the error messages are not printed.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2011-07-21 11:13:47 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description wangshibo 2011-02-14 02:17:24 UTC

Description of problem:
scsi_id  to the /dev/tmp-scsi-maj-mi-<pid> device doesn't unlink for cciss devices

Version-Release number of selected component (if applicable):
Red Hat Enterprise Linux 5.4

How reproducible:
Reproduce every time.


Steps to Reproduce:
1.#scsi_id -g -s /block/cciss\!c0d0/cciss\!c0d0p3 -v
#ll /dev/cciss/c0d0p3 
brw-r----- 1 root disk 104, 3 Feb 12 21:43 /dev/cciss/c0d0p3

2. #ll /dev/tmp-scsi-maj104-min3-21685 
brw------- 1 root root 104, 3 Feb 13 07:49 /dev/tmp-scsi-maj104-min3-21685

3. #pvcreate /dev/cciss/c0d0p3 
  Physical volume "/dev/cciss/c0d0p3" successfully created

4.#pvscan 
  PV /dev/cciss/c0d0p2     VG myvg            lvm2 [135.50 GB / 0    free]
  PV /dev/tmp-scsi-maj104-min3-21685          lvm2 [996.22 MB]
  Total: 2 [136.47 GB] / in use: 1 [135.50 GB] / in no VG: 1 [996.22 MB]

  
Actual results:
The pvscan command should display the /dev/tmp-scsi-maj104-min3-21685 for physical volume.

Expected results:
The pvscan command should display the /dev/cciss/c0d0p3 for physical volume.

Additional info:
The scsi_id command will unlink the temporary device at last for the non cciss device.

Comment 1 wangshibo 2011-02-14 02:18:34 UTC

The kbase article is https://access.redhat.com/kb/docs/DOC-46365

Comment 6 Florian Nadge 2011-05-25 14:48:08 UTC

    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Cause

The user runs fsck.gfs2 on a GFS2 file system in verbose mode (with the -v parameter).

Consequence

The user sees alarming error messages indicating that the master and root inode are not marked "In use" by the file system and an indication that the problem has been corrected:

System inode for 'master' is located at block 23 (0x17)
The inode exists but the block is not marked 'in use'; fixing it.
System inode for 'root' is located at block 22 (0x16)
The inode exists but the block is not marked 'in use'; fixing it.

There is no problem with either inode; the error messages are just misleading.

Fix

The code has been changed to set both the master and root inodes as "in use" in the in-core block map.

Result

As a result, fsck.gfs2 now realizes the master and root inodes are properly marked, so the error messages are not printed.

Comment 8 errata-xmlrpc 2011-07-21 11:13:47 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 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.

http://rhn.redhat.com/errata/RHBA-2011-1046.html