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 1124688 - installer options are invalid for no reason
Summary: installer options are invalid for no reason
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: anaconda
Version: 7.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Martin Kolman
QA Contact: Release Test Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-07-30 05:49 UTC by Vered Volansky
Modified: 2016-05-05 04:38 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-12-15 17:28:34 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Vered Volansky 2014-07-30 05:49:21 UTC 
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.
Comment 1 Martin Kolman 2014-07-30 08:46:38 UTC 
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 ?
Comment 2 Vered Volansky 2014-07-31 09:00:05 UTC 
(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.
Comment 3 Martin Kolman 2014-12-15 17:28:34 UTC 
Apparently this no longer manifests itself, so closing.
Note You need to log in before you can comment on or make changes to this bug.