Description of problem: Clicking back-button immediately after registering takes you back to "Choose Service" screen and you can re-register again. But clicking on back-button after navigating to create user take you back to "enter server url and port" screen. Version-Release number of selected component (if applicable): # rpm -qa | egrep "subscription-manager|python-rhsm" subscription-manager-migration-data-1.11.3.1-1.git.1.78afd75.el5 subscription-manager-debuginfo-1.8.8-1.el5 python-rhsm-1.8.12-1.git.0.d747a65.el5 subscription-manager-firstboot-1.8.10-1.git.27.c1dbb63.el5 subscription-manager-gui-1.8.10-1.git.27.c1dbb63.el5 subscription-manager-1.8.10-1.git.27.c1dbb63.el5 subscription-manager-migration-1.8.10-1.git.27.c1dbb63.el5 How reproducible: Always Steps to Reproduce: 1. Launch firstboot 2. Register using firstboot 3. Click on back-button after registering 4. You navigate to "Choose Service" 5. Register 6. Click Forward till you reach "Create User" menu 7. Click back-button Actual results: You are navigated back to "Enter server url and port" screen Expected results: Should either navigate to the the screen before "Create User" or to "Choose service" Additional info:
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.
This request was not resolved in time for the current release. Red Hat invites you to ask your support representative to propose this request, if still desired, for consideration in the next release of Red Hat Enterprise Linux.
This is actually expected behaviour and somewhat of a "best we could do" situation. On RHEL 5 specifically, we cannot go from the next firstboot module (Create User) back to the last screen of our module due to limitations with firstboot. We were unable to locate the bug where this behaviour was decided upon but it's been through a number of iterations and this was where we had to settle with it. If this were to resurface on RHEL 6 we *may* be able to do something there, but not on EL5. Closing for now.