Hide Forgot
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:
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.
Created attachment 412950 [details] second error occurance
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.
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.
How might I get this post beta 1 code?
Contact your Red Hat EPM for information on further RHEL 6.0 test releases.
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.
I have not been able to get the beta1 build so i cannot test the fix.
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.
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.
Created attachment 442968 [details] anaconda debug file for the beta2 rhel6 failure
Created attachment 442976 [details] anaconda debug file for the beta2 rhel6 failure 3390m3
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.
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.
(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...
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.
Created attachment 445785 [details] Latest test with rhel 6 beta2 using snapshot 13
Retested with snapshot 13 with errors again.
Moving to ASSIGNED based on comments 23 and 24
Created attachment 445998 [details] snapshot 13 test with 3390 mod3's
What does: cp q v dasd Report in this z/VM guest?
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
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.
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
Can we close this bug?
yes and thanks for all the help.