Bug 1124688
| Summary: | installer options are invalid for no reason | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Vered Volansky <vered> |
| Component: | anaconda | Assignee: | Martin Kolman <mkolman> |
| Status: | CLOSED NOTABUG | QA Contact: | Release Test Team <release-test-team-automation> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.0 | CC: | amureini, mkolman |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2014-12-15 17:28:34 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Aren't 2 & 3 the "installation source" and "software selection" spokes ? While it might not be readily apparent due to the limitations of the TUI they actually do an asynchronous initial refresh in the background. So it is quite possible that the ! you are seeing is just the repo metadata refresh failing (which makes the spoke not ready == "!"). Do you see the same behavior if you just stay on the main hub and refresh it (by pressing "r") repeatedly ? (In reply to Martin Kolman from comment #1) > Aren't 2 & 3 the "installation source" and "software selection" spokes ? Yes. > While it might not be readily apparent due to the limitations of the TUI > they actually do an asynchronous initial refresh in the background. So it is > quite possible that the ! you are seeing is just the repo metadata refresh > failing (which makes the spoke not ready == "!"). Do you see the same > behavior if you just stay on the main hub and refresh it (by pressing "r") > repeatedly ? I just tried this again, and I now get a starting point of 3 & 4 with !, so I don't have the same initial conditions. I tried r repeatedly and nothing changes. I also tried changing the timezone as before, but the situation stays the same (other options aren't affected as they were before). I then tried pressing r again several times, but no change. The main scenario happened again and again, but now I can't reproduce using the same vms. Will update if that changes. Apparently this no longer manifests itself, so closing. |
Description of problem: I installed RHEL7 on a virtual machine (VM) using ovirt-3.5. vdsm-4.16.1-0.gita4d9abf.fc20.x86_64 . I allocated a virtual disk of 10GB. I used the following installation from PXE: CSB-RHEL7-x86-64-xDEV2.3 . The initial installer setup complains about 'Destination Disk' (option 4 has '!' next to it). I started by changing the time zone and overriding the default to Jerusalem (option 32 in Asia). At this point options 2 and 3 in the main installer option got invalidated with an exclamation mark to their left, as well as option 4 (Destination Disk), that still had '!' to its left. I then changed the Time Zone to several values, as described in Steps to reproduce. On the second change the values for options 2+3 were good again (x instead of ! to the left. Changing back to the original value that caused the issue in the first place did NOT invalidate the other options this time around (options 2+3 values were still good). Version-Release number of selected component (if applicable): CSB-RHEL7-x86-64-xDEV2.3 Note: this version comes from the PXE, and we're not sure it's bona-fide 7.0 Note: I verified that there is indeed plenty (>60G) of free space in the underlying storage. How reproducible: 100% Steps to Reproduce: 1. Create virtual machine, selecting RHEL 7.x as the OS 2. Create a virtual disk, 10GB, thin provisioning 3. Run Once the VM, boot from network 4. Select CSB-RHEL7-x86-64-xDEV2.3 5. Verify you got the options menu (and Destination Disk is faulty? Not sure this is required, but this was my status). 6. Change Time Zone to Asia, Jerusalem (32). 7. Verify Options 2+3+4 are invalid ('!' to the left). This seemed random. At this point any change in the validation status of the other options should be worrying, 2+3+4 is what happened to specifically to me. 8. Change Time Zone to US, Eastern (And probably ant other time zone). 9. Verify options 2+3 are now valid (4 remained invalid for me, but was the same from the start, so this is not worrying. 10. Change Time Zone to Asia, Gaza (option 23). 11. Verify options 2+3 are still good. 12. Change Time Zone to Asia, Jerusalem again (option 32). 13. Verify options 2+3 are (surprisingly) still good. So this might suggest that any first change to Time Zone invalidates the other option's state, and and other change following it fixes it, and it probably doesn't happen again. A "first time only" bug. Actual results: As described above. Expected results: Changing the Time Zone to whatever value should not affect other options in the installation, and even if it should, the state should be consistent each time this value is selected. Additional info: Will supply logs on request (don't know what is relevant or where to get it). Note that I also opened bz1124379 recently, and they may be related somehow. Not marking as such since I'm not sure about this.