I figured a new bug would be the best way to trace this. So, https://bugzilla.redhat.com/show_bug.cgi?id=1526861 was filed when a change to systemd caused text installs to stop working. The bug was that systemd choked on an `ExecStartPre` command that was, at that time, included in the systemd service file used for running anaconda in text mode: ExecStartPre=/usr/bin/echo -e \033%G This bug was "fixed" by simply removing that line: https://github.com/rhinstaller/anaconda/commit/ab29bdff2e041ec4f354c3334d8aa15ea8366a17 The commit message claims that this command "most likely tries to ring the terminal bell (!)". This is, however, entirely wrong. It is a console escape sequence, but its purpose has nothing to do with the bell. I looked into what it's actually for and tracked it down. It is in fact to do with unicode / UTF-8. This escape sequence was initially introduced in: https://github.com/rhinstaller/anaconda/commit/702e343f84f85536e1eddf49462a18e946c79613 directly to the `anaconda` script itself. That commit explains its intended purpose to some extent: "Finally, emit the magic control sequence to set UTF-8 output, which fixes the line-drawing characters in text-mode virtual terminals." Later, https://github.com/rhinstaller/anaconda/commit/2ce721057958ba589bb79189fbe0cb4ec0dd14dd rejigged things so the escape sequence was emitted by calling `echo` from the systemd service file rather than using a Python `print` statement (or function call, on Python 3) in the `anaconda` script. I found some background on the escape code here: https://www.nntp.perl.org/group/perl.unicode/1999/11/msg52.html it is an ISO 2022-specified escape code which announces that subsequent content will be UTF-8 encoded, it seems. Will's initial commit message implies that without it, there will be an issue with 'line-drawing characters' during text installs (possibly only with certain locales). I haven't yet looked into this specifically, but the obvious thing to do would be to try text installs in languages like Chinese and Japanese, look for places where we draw ASCII tables and stuff, and see how those look; I did check the anaconda mailing list archives to see if there was a discussion of the actual problem that the escape code fixed, but haven't found one (or a bug report) so far. There are some bug reports that mention issues with line-drawing characters and exotic locales, like https://bugzilla.redhat.com/show_bug.cgi?id=138445 and https://bugzilla.redhat.com/show_bug.cgi?id=186907 , but they aren't quite the same thing. We can update this bug's summary and severity when we figure out precisely what this broke, if anything.
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.