Bug 814713
| Summary: | curl --progress-bar is too verbose on s390 (x3270 terminal) | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Jesse Keating <jkeating> |
| Component: | dracut | Assignee: | dracut-maint |
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | rawhide | CC: | dan, dcantrell, dracut-maint, harald, jonathan, jstodola, kdudka, mbanas, wwoods |
| Target Milestone: | --- | Keywords: | Reopened |
| Target Release: | --- | ||
| Hardware: | s390x | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | dracut-018-26.git20120424.fc17 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | 806426 | Environment: | |
| Last Closed: | 2012-11-30 07:41:01 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 802788, 806426 | ||
| Bug Blocks: | 799508 | ||
|
Description
Jesse Keating
2012-04-20 14:00:01 UTC
I doubt this is going to get fixed in curl in time, so in the mean time we need to just not use --progress-bar when on the s390x platform. I think that's easy enough to do in modules.d/45url-lib/url-lib.sh (In reply to comment #1) > I doubt this is going to get fixed in curl in time Jesse, please specify what exactly you mean by "get fixed in curl". There has been so far no valid proposal of a fix for curl... The "easy fix" is to ignore --progress-bar when the cms environment is detected. No idea how to properly detect that environment though. I honestly have no idea if there are any scan codes that are useful to do anything like a progress bar within cms. Jesse, there is proposed solution for curl, but the problem is on the s390 side where it uses TERM=dumb which reports the capability of handling \r, while the console in fact doesn't handle it. And all that will need some time to resolve if possible at all. In the meantime I'd prefer dracut to not use the --progress-bar option when on s390x. So: the TERM setting is wrong, since the terminal doesn't even fully support "dumb". Is there a TERM more appropriate (or dumb enough) for CMS? (In the meantime, we can skip '--progress-bar' if TERM=dumb. The normal output still uses '\r', but it only updates once per second, so that's why it's less verbose..) An alternative approach would be to introduce a new option in curl (e.g. --progress-simple) and let dracut use it. With this option, we can simply forget about the problems with terminal detection and curl does not need to to build against the terminfo library at all. A solution like this was also suggested by upstream meanwhile (independently on my original proposal): http://thread.gmane.org/gmane.comp.web.curl.general/12769/focus=12786 dracut-018-26.git20120424.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/dracut-018-26.git20120424.fc17 Package dracut-018-26.git20120424.fc17: * should fix your issue, * was pushed to the Fedora 17 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing dracut-018-26.git20120424.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-6603/dracut-018-26.git20120424.fc17 then log in and leave karma (feedback). dracut-018-26.git20120424.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report. Well this was supposedly fixed by not using the --progress-bar option for all hosts. However now it uses curl's built in progress thing, which is still too wide for x3270 causing a cascade of text wraps which is still pretty ugly. I think we need to bite the bullet here and just operate curl in silent mode for s390x :( still an issue? (In reply to comment #11) > still an issue? no, all seems to work sufficiently good |