Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
Created attachment 714635[details]
Screenshot
Description of problem:
During a network installation, if there is any network hiccup that prevents a package from being downloaded, the installation aborts and the only way forward is to reboot and try again. Previous versions of the installer (RHEL6 for example) provided an option to retry the package download, which was really useful in case of any network glitches.
Version-Release number of selected component (if applicable): 7.0 Alpha 3
How reproducible: always
Steps to Reproduce:
1. Start network installation
2. Create a network disconnection between the new system and the installation server
Actual results: Error message shown (see atached screenshot). The only available option is to abort the installation.
Expected results: Error message shown, giving a chance to retry the package download or abort the installation.
Additional info:
I've just hit the same ... well, almost, in my case I got "error populating transaction"
setting Regression as per the initial comment - if that worked in RHEL6, it would be a step back ...
I did some testing with the January 27 RHEL7 nightly and the current behavior seems to be like this:
* if you remove a package that's needed for the package selection from the repository (from the Packages folder - glib & co is a good candidate to test this) BEFORE starting package installation, you will get the "error populating transaction" error message and installation will be aborted
* if you remove a package from the repo (or even just move the whole Packages folder) AFTER package installation has been started (eq Anaconda is reporting that packages are being installed) Anaconda will retry the failed download until it is available, without any upper limit on the number of tries
- once you move the package (or the whole Packages folder) back, it will get the package, the installation will continue & the system will be installed correctly
- the unlimited number of retries could also be an issue due to logging, every retry attempt is logged to the packages.log file and without an upper bound, this could theoretically lead to OOM issues if the repo breaks during an unattended installation (as the log file resides on a ramdisk during the install)
I think this behavior (no retries when populating the transaction, unlimited retries when getting the packages) could be improved upon, by setting an upper bound on the number of retries - for both transaction population and package download. Also for the retries to make sense (eq. to overcome short connectivity issues) we should also wait a bit before retrying.
Based on how retries are implemented in RHEL6, I'll aim for:
* maximum of 3 retries
* 3 seconds wait between retries
The new behavior is:
- initial attempt + 10 retries
- raising time between retries, from 0.5 seconds
before first retry up to 256 seconds before the final retry attempt
All retry attempts are logged to the /tmp/packaging.log log file.
This request was resolved in Red Hat Enterprise Linux 7.0.
Contact your manager or support representative in case you have further questions about the request.
Created attachment 714635 [details] Screenshot Description of problem: During a network installation, if there is any network hiccup that prevents a package from being downloaded, the installation aborts and the only way forward is to reboot and try again. Previous versions of the installer (RHEL6 for example) provided an option to retry the package download, which was really useful in case of any network glitches. Version-Release number of selected component (if applicable): 7.0 Alpha 3 How reproducible: always Steps to Reproduce: 1. Start network installation 2. Create a network disconnection between the new system and the installation server Actual results: Error message shown (see atached screenshot). The only available option is to abort the installation. Expected results: Error message shown, giving a chance to retry the package download or abort the installation. Additional info: