Bug 1532451
| Summary: | "Fix" for 1526861 prematurely removed unicode-related escape code without properly assessing consequences | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Adam Williamson <awilliam> |
| Component: | anaconda | Assignee: | Anaconda Maintenance Team <anaconda-maint-list> |
| Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 28 | CC: | anaconda-maint-list, jonathan, kellin, mkolman, vanmeeuwen+fedora, v.podzimek+fedora, vponcova, wwoods, zbyszek |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2019-05-28 19:01:07 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: | |||
|
Description
Adam Williamson
2018-01-09 01:22:26 UTC
Note that according to https://bugzilla.redhat.com/show_bug.cgi?id=1527700#c1 , systemd has since been fixed such that the ExecStartPre line should work again, so it should be fine to restore it... Wait, sorry, no, that's not what that comment says at all. Please disregard #c1, it is incorrect. systemd has not been fixed. In case anyone missed it, Will commented on the github commit discussion - https://github.com/rhinstaller/anaconda/commit/ab29bdff2e041ec4f354c3334d8aa15ea8366a17#commitcomment-26796171 . Quoting: "Adam's correct - that control sequence is required to set a virtual console / terminal to UTF-8 mode. On a normal system it gets sent to the terminal by systemd-vconsole-setup (see vconsole-setup.c:toggle_utf8()) ( https://github.com/systemd/systemd/blob/v234/src/vconsole/vconsole-setup.c#L93 ) during early startup. But it only happens if locale_is_utf8() is true, and since the anaconda environment generally doesn't have the correct locale until we ask the user, the terminals weren't getting set up correctly - so instead we do this to force the tmux-attached terminal to use LANG=en_US.UTF-8 and enable UTF-8 mode. A cleaner way to handle this might be: 1. Ensure the default locale.conf in initramfs (and/or the anaconda runtime) is LANG=en_US.UTF-8 so all terminals get set for UTF-8 at startup (although I'm not 100% sure that applies to every possible TTY that tmux might run on - ssh, hypervisor, virtual-serial, etc.), and maybe also 2. (re)run systemctl restart systemd-vconsole-setup.service after the user chooses a locale/keymap, to reload console fonts and set UTF-8 mode once we are sure that we have the right locale and all the TTYs are present. Anyway, that's just one possible solution - but whatever you do I'd definitely suggest you make sure it's getting handled correctly somewhere before you drop it from here, because if it isn't you're probably gonna get some very confusing "console corruption" bugs later on, and those are No Fun to debug." (In reply to Adam Williamson from comment #3) > In case anyone missed it, Will commented on the github commit discussion - > https://github.com/rhinstaller/anaconda/commit/ > ab29bdff2e041ec4f354c3334d8aa15ea8366a17#commitcomment-26796171 . Quoting: > > "Adam's correct - that control sequence is required to set a virtual console > / terminal to UTF-8 mode. > > On a normal system it gets sent to the terminal by systemd-vconsole-setup > (see vconsole-setup.c:toggle_utf8()) ( > https://github.com/systemd/systemd/blob/v234/src/vconsole/vconsole-setup. > c#L93 ) during early startup. But it only happens if locale_is_utf8() is > true, and since the anaconda environment generally doesn't have the correct > locale until we ask the user, the terminals weren't getting set up correctly > - so instead we do this to force the tmux-attached terminal to use > LANG=en_US.UTF-8 and enable UTF-8 mode. Interesting! > > A cleaner way to handle this might be: > > 1. Ensure the default locale.conf in initramfs (and/or the anaconda > runtime) is LANG=en_US.UTF-8 so all terminals get set for UTF-8 at startup > (although I'm not 100% sure that applies to every possible TTY that tmux > might run on - ssh, hypervisor, virtual-serial, etc.), and maybe also > 2. (re)run systemctl restart systemd-vconsole-setup.service after the > user chooses a locale/keymap, to reload console fonts and set UTF-8 mode > once we are sure that we have the right locale and all the TTYs are present. > > Anyway, that's just one possible solution - but whatever you do I'd > definitely suggest you make sure it's getting handled correctly somewhere > before you drop it from here, because if it isn't you're probably gonna get > some very confusing "console corruption" bugs later on, and those are No Fun > to debug." Comparing both suggestions with the previous behavior (just sending the escape code unconditionally) I think it still comes up ahead as it should be more robust and less complicated. I have no issue with putting it back in place now that we have found what it is actually doing and that it might be needed. But in such case we will have to find a way of running the command without systemd barfing on it. I see two option basically: 1) find out why systemd considers the call with the escape code invalid (possibly a bug in systemd ?) 2) put the call in a wrapper script and call it from there This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle. Changing version to '28'. This message is a reminder that Fedora 28 is nearing its end of life. On 2019-May-28 Fedora will stop maintaining and issuing updates for Fedora 28. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '28'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 28 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. mkolman, didn't you say you'd eventually figured this out somehow? Fedora 28 changed to end-of-life (EOL) status on 2019-05-28. Fedora 28 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. (In reply to Adam Williamson from comment #7) > mkolman, didn't you say you'd eventually figured this out somehow? Hi, we investigated the issue and it should be fine. |