Created attachment 1232743 [details] screen shot Description of problem: Translated login prompt is displayed in the emergency mode, but it is not always that the console can display the localized text. Garbled characters lead to confusion, especially in the situation that the system drops into the emergency mode. Translated login prompt is meaningless because another help message is displayed in English. The attached image is a screen shot of the emergency mode in case that the system locale was ja_JP.UTF-8. The user would not get that the user should enter a password of the root. Steps to Reproduce: 1. Edit /etc/locale.conf, and set ja_JP.UTF-8 as the system locale. 2. Make the situation so that the emergency mode will start after the reboot. (e.g. add '/dev/mapper/nonexistentvol /mnt ext4 defaults 0 0' to /dev/fstab ) 3. Reboot Actual results: See the screen shot image. Expected results: Login prompt is displayed in characters that the current console can display.
Package langpacks-ja is also required to install to reproduce.
I think this is partly the same as a bug I happened to file yesterday: https://bugzilla.redhat.com/show_bug.cgi?id=1405240 where we make no attempt to configure an appropriate console font for the language the system is being installed in; we just give all installs the 'eurlatgr' console font, which certainly can't display any Japanese characters at all. There's an additional complication for CJK languages, though, which is that I don't think there *is* a viable CJK console font. I mean, it's clearly just impossible with a 'regular' console for Chinese or even for commonly-used kanji, there are just too many of them. You could do hiragana+katakana, I guess. So...I think my guess is that it doesn't make any sense that this message is translated to Japanese, since it's only ever going to be shown in an environment which can't possibly display Japanese properly. I believe this message comes from sulogin.c in util-linux: https://git.kernel.org/cgit/utils/util-linux/util-linux.git/tree/login-utils/sulogin.c#n536 and we can see that, indeed, util-linux has a Japanese translation upstream: https://git.kernel.org/cgit/utils/util-linux/util-linux.git/tree/po/ja.po so I'm gonna assign this to util-linux, for now. I am surprised this hasn't come up as an issue before, though (if it hasn't). It seems like it'd be something that'd frequently be a problem, unless there's a commonly-used mechanism for displaying Japanese on consoles that I'm not aware of.
Note that there will almost certainly be the same problem in Russian (and Hebrew, and Arabic...), but in that case, the bug really *is* #1405240, because there is a viable console font for Russian (and Hebrew and Arabic) and we should be setting it for installs in those languages.
I don't think we want to be smart in this area in sulogin, it's too late. The sulogin command just follows locale setting and has no clue about fonts etc. (BTW, for sulogin or agetty the locale setting is also important for the terminal flags initialization). If there is a problem with some languages then we need to set LANG=C (or POSIX or so) *before* sulogin is executed. It does not make sense to set locale to ja_JP.UTF-8 and then add to our programs exceptions to ignore this setting.
At least so far as I know, it's impossible for a standard kernel console (like the one that this emergency message will almost certainly be displayed on) to display Chinese, Japanese or Korean at least. It would be a good idea to check with a domain expert, but I think I'm right. A lower-tech solution, of course, would simply be to mark strings only likely to be used during the boot process in the code somehow to indicate to translators of the affected languages that they should *not* be translated. It's a trickier case for, say, Russian or Greek, which *can* be shown on a kernel console, but might not be supported by the font that's loaded at the time. A really ideal solution would be to make kernel consoles suck less, but it seems like kmscon was discontinued in favour of systemd-consoled, which was itself dropped in 2015: https://github.com/systemd/systemd/pull/747 and since then I lose track of where things stand, but it sure doesn't seem like we have a non-ASCII-centric console implementation coming any time soon. Might be nice for RH to fund more work in this area generally, but we're a bit out of scope there.
This message is a reminder that Fedora 25 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 25. 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 '25'. 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 25 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.
Fedora 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 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.