Bug 729910

Summary: Anaconda doesn't fill "Interconnect" and "Serial Number" columns for some DASD devices
Product: Red Hat Enterprise Linux 6 Reporter: Jan Stodola <jstodola>
Component: anacondaAssignee: David Cantrell <dcantrell>
Status: CLOSED ERRATA QA Contact: Release Test Team <release-test-team-automation>
Severity: medium Docs Contact:
Priority: medium    
Version: 6.1CC: bcl, jreed
Target Milestone: rc   
Target Release: ---   
Hardware: s390x   
OS: Linux   
Whiteboard:
Fixed In Version: anaconda-13.21.177-1 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 824601 (view as bug list) Environment:
Last Closed: 2013-02-21 09:58:14 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 691780, 756082, 824601, 840685    
Attachments:
Description Flags
DASD 3527 drive formatted during the install
none
'udevadm info --export-db' before entering the filterring UI
none
'udevadm info --export-db' when in the filterring UI none

Description Jan Stodola 2011-08-11 08:53:22 UTC
Created attachment 517755 [details]
DASD 3527 drive formatted during the install

Description of problem:
When installing on DASD devices that don't need to be formatted during the install with dasdfmt, anaconda doesn't fill "Interconnect" and "Serial Number" columns in filtering UI.
On the other hand, when dasdfmt is used to format an uninitialized DASD drive during the install, both columns are filled.
See attached screenshot - DASD drive with device number 3527 was formatted with cpfmtxa before starting the install and then formatted by anaconda.

Version-Release number of selected component (if applicable):
anaconda-13.21.126-1.el6

How reproducible:
always

Steps to Reproduce:
1. run cpfmtxa in CMS to format any DASD disk
2. start the installation in graphical mode
3. when asked, format all uninitialized DASD disks
4. proceed to the filtering UI
  
Actual results:
Only the DASD drive formatted during the installation has "Interconnect" and "Serial Number" fields filled.

Expected results:
"Interconnect" and "Serial Number" fields are filled for all DASD drives.

Comment 2 Jan Stodola 2011-08-11 09:01:50 UTC
One note to add:
After selecting all DASD drives in filtering UI, clicking on "Next" and then "Back" to filtering UI, columns "Interconnect" and "Serial Number" are filled correctly for all DASD drives.

Comment 3 Chris Lumens 2011-08-18 21:19:29 UTC
We get this information straight from udev.  When you hit this problem, can you grab the output of udevadm info --export-db and attach it to this bug?

On the other hand, your comment #2 makes me worried that this could be timing-specific, and by the time you grab that log, the data has made it into udev.

Comment 4 Jan Stodola 2011-08-19 09:09:29 UTC
'udevadm monitor' shows following:

# having "Specialized Storage Devices" selected, click "Next" to continue to the filtering UI:
KERNEL[1313744756.182081] add      /module/scsi_wait_scan (module)
UDEV  [1313744756.182454] add      /module/scsi_wait_scan (module)
KERNEL[1313744756.188311] remove   /module/scsi_wait_scan (module)
UDEV  [1313744756.188539] remove   /module/scsi_wait_scan (module)
KERNEL[1313744756.271878] change   /devices/css0/0.0.000c/0.0.3727/block/dasdd (block)
UDEV  [1313744756.278137] change   /devices/css0/0.0.000c/0.0.3727/block/dasdd (block)
KERNEL[1313744756.292838] change   /devices/css0/0.0.000b/0.0.3627/block/dasdc (block)
UDEV  [1313744756.297079] change   /devices/css0/0.0.000b/0.0.3627/block/dasdc (block)
KERNEL[1313744756.312532] change   /devices/css0/0.0.000a/0.0.3527/block/dasdb (block)
UDEV  [1313744756.316147] change   /devices/css0/0.0.000a/0.0.3527/block/dasdb (block)

# In the filtering UI, click on "Back" and then "Next" to the filtering UI
KERNEL[1313744772.408230] add      /module/scsi_wait_scan (module)
UDEV  [1313744772.408624] add      /module/scsi_wait_scan (module)
KERNEL[1313744772.413869] remove   /module/scsi_wait_scan (module)
UDEV  [1313744772.414014] remove   /module/scsi_wait_scan (module)

Comment 5 Jan Stodola 2011-08-19 09:12:06 UTC
Created attachment 518995 [details]
'udevadm info --export-db' before entering the filterring UI

Comment 6 Jan Stodola 2011-08-19 09:14:08 UTC
Created attachment 518996 [details]
'udevadm info --export-db' when in the filterring UI

Gathered after entering the filtering UI.

Comment 7 Chris Lumens 2011-08-19 14:47:59 UTC
As you can see, ID_BUS and ID_SERIAL are not set in the initial udevadm output for those couple d3evices, but are set after you're in the filter UI.  My guess is that our call to dasd.DASD().startup in iw/filter_gui.py is causing those attributes to be set, but they do not appear in time for populate to make use of them.

Perhaps we need yet another udev_settle call after all those startups.

Comment 11 Jesse Keating 2012-04-23 22:12:06 UTC
Sadly, a udev_settle() call isn't enough here.  There is quite a lot of stuff happening when "next" is clicked from the filter screen, perhaps something there is triggering the data to be filled in.  Will have to look in that direction.

Comment 12 Jesse Keating 2012-04-23 23:42:55 UTC
Upon further tracing, it's a call to parted.Device() that triggers the extra information to show up in udev.  Calls to udev_settle() or udev_trigger() do not make anything happen.  This /feels/ like a udev bug, in that the data isn't showing up when we can for dasds.  I'll have to dig into it with the udev folks.

Comment 13 Jesse Keating 2012-04-24 22:49:56 UTC
After discussing with udev devs and reading more code, we think that this is ultimately a kernel bug, where the kernel isn't issuing a change or add event when these devices are created.  I'd like to get the kernel involved in that aspect, however I do have patch with a workaround to manually trigger udev to notice more information about these devices.  I'll post the patch and discuss using the workaround as opposed to a kernel change.

Comment 14 Jesse Keating 2012-04-25 19:04:22 UTC
Patch pushed upstream, should be in the next build of anaconda for RHEL6.

Comment 17 Jesse Keating 2012-06-06 20:09:26 UTC
Different, better patch posted upstream for review.

Comment 18 Jesse Keating 2012-06-07 00:03:16 UTC
4c9ce631c56b4f3e42012d79f3aaff873c1a38ab and a02ad5117f3b84b78166b43f50c69e9752e2782b were pushed upstream to fix this.  Can be pulled into rhel6 when appropriate.

Comment 20 RHEL Program Management 2012-07-16 22:46:23 UTC
This request was evaluated by Red Hat Product Management for
inclusion in a Red Hat Enterprise Linux release.  Product
Management has requested further review of this request by
Red Hat Engineering, for potential inclusion in a Red Hat
Enterprise Linux release for currently deployed products.
This request is not yet committed for inclusion in a release.

Comment 22 Jan Stodola 2012-11-27 13:47:50 UTC
Both Interconnect and Serial Number are filled correctly.

Tested with anaconda-13.21.186

Moving to VERIFIED.

Comment 24 errata-xmlrpc 2013-02-21 09:58:14 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-0373.html