RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 590838 - s390 installer disk partition failure rhel6 beta
Summary: s390 installer disk partition failure rhel6 beta
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: anaconda
Version: 6.1
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: 6.1
Assignee: Anaconda Maintenance Team
QA Contact: Release Test Team
URL:
Whiteboard:
Depends On:
Blocks: 564512
TreeView+ depends on / blocked
 
Reported: 2010-05-10 19:17 UTC by Ray Hand
Modified: 2010-09-10 02:09 UTC (History)
8 users (show)

Fixed In Version: anaconda-13.21.37-1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-09-10 02:09:49 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
error log from the installer (83.33 KB, text/plain)
2010-05-10 19:17 UTC, Ray Hand 		no flags Details
second error occurance (83.00 KB, text/plain)
2010-05-10 19:58 UTC, Ray Hand 		no flags Details
anaconda debug file for the beta2 rhel6 failure (104.78 KB, text/xml)
2010-09-03 19:36 UTC, Ray Hand 		no flags Details
anaconda debug file for the beta2 rhel6 failure 3390m3 (171.83 KB, text/xml)
2010-09-03 20:16 UTC, Ray Hand 		no flags Details
Latest test with rhel 6 beta2 using snapshot 13 (106.86 KB, text/xml)
2010-09-07 20:50 UTC, Ray Hand 		no flags Details
snapshot 13 test with 3390 mod3's (171.71 KB, text/xml)
2010-09-08 14:40 UTC, Ray Hand 		no flags Details
View All

Description Ray Hand 2010-05-10 19:17:59 UTC 
Created attachment 412943 [details]
error log from the installer

Description of problem:

rhel 6 beta,  when doing the initial install the disk device is selected and when anaconda goes to set the partitions i get an invalid device specification.
This is a z/10 box running osa network cards using 1 3390 mod9 disk drive.

How reproducible:
every time

Steps to Reproduce:
1. run redhat exec under vm
2. setup and start vnc
3. select device 
  
Actual results:

error - invalid device

Expected results:


Additional info:
Comment 2 Ray Hand 2010-05-10 19:57:24 UTC 
the first debug file was from the vnc advanced setup under the basic devices tab.  I went back thru and recreated the error just using the basic devices setup without entering the advanced setup. I have attached the new debu file here.
Comment 3 Ray Hand 2010-05-10 19:58:15 UTC 
Created attachment 412950 [details]
second error occurance
Comment 4 RHEL Program Management 2010-05-10 20:17:39 UTC 
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.
Comment 5 David Cantrell 2010-05-11 01:22:39 UTC 
This has been fixed in RHEL 6.0 post beta 1.  I just tried reproducing this problem on the latest nightly and was unable to.
Comment 7 Ray Hand 2010-05-11 10:20:37 UTC 
How might I get this post beta 1 code?
Comment 8 David Cantrell 2010-05-11 14:25:00 UTC 
Contact your Red Hat EPM for information on further RHEL 6.0 test releases.
Comment 10 Jan Stodola 2010-05-19 07:32:39 UTC 
Hi,
I'm not able to reproduce this issue with RHEL6 beta1 build. I tried with one 3390 mod3 (and also with mod12, I don't have mod9 disk). Are you still able to reproduce this bug with beta1 and/or any post beta1 build? Thank you.
Comment 11 Ray Hand 2010-05-19 12:50:14 UTC 
I have not been able to get the beta1 build so i cannot test the fix.
Comment 12 Jan Stodola 2010-08-11 09:08:41 UTC 
Ray, could you retest this issue with public beta2 build? I'm not able to reproduce this issue on our local z/VM guests.
Thank you.
Comment 13 Ray Hand 2010-09-03 19:34:39 UTC 
I was able to test rhel beta2 and still got an error with 1 3390 mod9.
I also tried on another VM guest with 3 3390 mod 3's and got an error also.
Comment 14 Ray Hand 2010-09-03 19:36:04 UTC 
Created attachment 442968 [details]
anaconda debug file for the beta2 rhel6 failure
Comment 15 Ray Hand 2010-09-03 20:16:21 UTC 
Created attachment 442976 [details]
anaconda debug file for the beta2 rhel6 failure 3390m3
Comment 18 David Cantrell 2010-09-07 14:18:57 UTC 
Your debug attachments indicate that "/dev/dasda" is being used for partitioning.  If you are trying to perform a kickstart installation that specifies /dev/dasda, understand that the /dev/dasda is used early in the installation process for the CMS disk.  The /dev/dasd* names available during installation will begin at /dev/dasdb

A better way to specify your devices in a kickstart file on s390x is to use the /dev/disk/by-path link, such as:

    /dev/disk/by-path/ccw-X.Y.Zp

Where X.Y.Z corresponds to the CCW specification and 'p' indicates the partition, such as a, b, or c.

The use of /dev/dasd* names in kickstart files is discouraged as we have no way to guarantee the device assignments for those names.
Comment 20 Ray Hand 2010-09-07 15:37:45 UTC 
This is a text install and as such i only get prompted for device numbers.  The assignment of /dev/dasda is done by the installation.  There is no kickstart file for this install.  Its totally manual.
Comment 21 Jan Stodola 2010-09-07 15:56:42 UTC 
(In reply to comment #18)
> Your debug attachments indicate that "/dev/dasda" is being used for
> partitioning.  If you are trying to perform a kickstart installation that
> specifies /dev/dasda, understand that the /dev/dasda is used early in the
> installation process for the CMS disk.  The /dev/dasd* names available during
> installation will begin at /dev/dasdb

hmm, looking into the log attached in comment 14, anaconda didn't run with kickstart:

...
19:18:37,648 INFO    : kernel command line: root=/dev/ram0 ro ip=off ramdisk_size=40000 cio_ignore=all,!0.0.0009
...

And CMS parameter file was not used as well, because there are no CMSDASD= and CMSCONFFILE= parameters on the command line. Based on that, the first DASD device should be named as /dev/dasda.

Later in the log I see two DASD devices:
...
            sysfsPath: /devices/css0/0.0.000d/0.0.0303/block/dasda
...
            sysfsPath: /devices/css0/0.0.000e/0.0.0400/block/dasdb
...
but comment 13 says there should be only one 3390 mod9 DASD device...
Comment 22 Ray Hand 2010-09-07 16:25:05 UTC 
Two tests were done - 1 with one 3390 mod9 and another test with 3 3390 mod3 dasd devices.  I tried to name the debug files with that indication as well.
Comment 23 Ray Hand 2010-09-07 20:50:42 UTC 
Created attachment 445785 [details]
Latest test with rhel 6 beta2 using snapshot 13
Comment 24 Ray Hand 2010-09-07 20:51:20 UTC 
Retested with snapshot 13 with errors again.
Comment 25 Jan Stodola 2010-09-08 13:53:10 UTC 
Moving to ASSIGNED based on comments 23 and 24
Comment 26 Ray Hand 2010-09-08 14:40:02 UTC 
Created attachment 445998 [details]
snapshot 13 test with 3390 mod3's
Comment 27 David Cantrell 2010-09-08 21:29:52 UTC 
What does:

    cp q v dasd

Report in this z/VM guest?
Comment 29 Ray Hand 2010-09-09 12:21:56 UTC 
cp q v dasd                                                                   
DASD 0190 3390 ZN5GLD R/O        107 CYL ON DASD  0773       SUBCHANNEL = 0004 
DASD 019D 3390 ZN5GLD R/O        200 CYL ON DASD  0773       SUBCHANNEL = 0005 
DASD 019E 3390 ZN5GLD R/O        250 CYL ON DASD  0773       SUBCHANNEL = 0006 
DASD 0300 3390 ZN7VM0 R/W       3338 CYL ON DASD  34F8       SUBCHANNEL = 000A 
DASD 0301 3390 ZN7VM1 R/W       3338 CYL ON DASD  34F9       SUBCHANNEL = 000B 
DASD 0302 3390 ZN7VM2 R/W       3338 CYL ON DASD  34FA       SUBCHANNEL = 000C 
DASD 0303 3390 ZN9VM7 R/W      10016 CYL ON DASD  3436       SUBCHANNEL = 000D 
DASD 0400 9336 (VDSK) R/W     262144 BLK ON DASD  VDSK       SUBCHANNEL = 000E
Comment 30 David Cantrell 2010-09-09 13:46:40 UTC 
Can you perform a cpfmtxa on DASD 0300 and then perform an installation again?  Tell cpfmtxa to format, cylinders 0-200, and label it ZN7VM0 again.

When you start the installation, when you are asked what DASD range to use, be sure to specify the 300-302 or whatever you have been specifying at that prompt.  Let me know what you specify for that prompt as well.

What I'm looking for is the installer detecting that it needs to run dasdfmt on /dev/dasda and asking you if that's ok to do.  Tell it yes and continue with installation as you have been.
Comment 31 Ray Hand 2010-09-09 19:58:20 UTC 
That worked.  Odd that i would have to use ICKDSF to format the volumes first 200 cyls.  I used CMS format on the volumes each time changes were written to disk on my previous attempts.  Thanks
Comment 32 Ronald Pacheco 2010-09-09 23:52:45 UTC 
Can we close this bug?
Comment 33 Ray Hand 2010-09-10 02:01:25 UTC 
yes and thanks for all the help.
Note You need to log in before you can comment on or make changes to this bug.