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):
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
Only the DASD drive formatted during the installation has "Interconnect" and "Serial Number" fields filled.
"Interconnect" and "Serial Number" fields are filled for all DASD drives.
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.
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.
'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)
Created attachment 518995 [details]
'udevadm info --export-db' before entering the filterring UI
Created attachment 518996 [details]
'udevadm info --export-db' when in the filterring UI
Gathered after entering the filtering UI.
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.
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.
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.
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.
Patch pushed upstream, should be in the next build of anaconda for RHEL6.
Different, better patch posted upstream for review.
4c9ce631c56b4f3e42012d79f3aaff873c1a38ab and a02ad5117f3b84b78166b43f50c69e9752e2782b were pushed upstream to fix this. Can be pulled into rhel6 when appropriate.
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.
Both Interconnect and Serial Number are filled correctly.
Tested with anaconda-13.21.186
Moving to VERIFIED.
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.