Bug 970030
| Summary: | F19 release-name “Schrödinger’s Cat” shown as "SchrÔdingerūs Cat" on the linux console | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Vít Ondruch <vondruch> | ||||||
| Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> | ||||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
| Severity: | unspecified | Docs Contact: | |||||||
| Priority: | unspecified | ||||||||
| Version: | 20 | CC: | alekcejk, amk, awilliam, berend.de.schouwer, BobLfoot, bugzilla, bugzilla, chris, customercare, eli, error, gansalmon, g.kaviyarasu, harald, hdegoede, herrold, ignatenko, itamar, jesusr, jforbes, johannbg, jonathan, jones.peter.busi, jorgeml, jorti, kernel-maint, kevin, kvolny, lnykryn, madhu.chinakonda, marcus.moeller, metherid, mfabian, mkolman, msekleta, nix.sasl, pahan, petersen, plautrba, ppisar, robatino, rtguille, rvokal, sara.c, sergio, systemd-maint, thomas, thomas.moschny, vanmeeuwen+fedora, vcrhonek, vg.aetera, vondruch, vpavlin, zbyszek, zing | ||||||
| Target Milestone: | --- | Keywords: | i18n, Reopened | ||||||
| Target Release: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | AcceptedFreezeException | ||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | 927564 | Environment: | |||||||
| Last Closed: | 2015-01-28 13:52:55 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: | |||||||||
| Bug Depends On: | |||||||||
| Bug Blocks: | 834091 | ||||||||
| Attachments: |
|
||||||||
|
Description
Vít Ondruch
2013-06-03 11:07:06 UTC
Created attachment 756252 [details]
Screenshot of kernel bug.
attaching screenshot of kernel bug again.
tty0 was setup with setfont before the kms driver was loaded. After switching to the kms driver, it has the correct font set, but apparently the unimap was not copied and is only set/uploaded after an additional setfont run. Clean up some metadata crap from the cloning. (In reply to Harald Hoyer from comment #2) > tty0 was setup with setfont before the kms driver was loaded. > > After switching to the kms driver, it has the correct font set, but > apparently the unimap was not copied and is only set/uploaded after an > additional setfont run. I've run into this today too, and here is some more info, first for those who don't like downloading screenshots all the screenshot shows is our beloved release name showing up as: "Schrôdingerūs Cat" instead of "Schrödinger’s Cat" I noticed this first on on allwinner a10 arm system which has a simple fb driver (no kms involved), and at first I had the "Schrödinger▮s Cat" problem there, rather then the "Schrôdingerūs Cat" problem. Doing a "setfont latarcyrheb-sun16" there then transforms the problem text in the login banner into "Schrôdingerūs Cat" while a "cat /etc/redhat-release" does show the right text! This seems to confirm that the problem is a font-map problem, since already drawn (so already mapped) text gets the problem when switching from built-in font to latarcyrheb-sun16, gets redrawn with the new font. but not remapped, resulting in the "Schrôdingerūs Cat" text, whereas text drawn later, so first mapped with the fontmap for latarcyrheb-sun16 loaded by setfont, does show up correctly. Discussed at 2013-06-20 freeze exception review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-06-20/f19final-blocker-review-7.1.2013-06-20-15.01.log.txt . Accepted as a freeze exception issue: this is a (set of) polish issue(s) we've been fighting the whole cycle and we'd like to fix it as hard as (safely) possible before release. We'll evaluate the safety of proposed fixes as they appear. This continues to be a problem on release, with updates and with kernels 3.9.5 through 3.10.0. But the problem is restricted to tty on the system console itself, both the title at a login prompt and when issuing cat /etc/redhat-release I get: Schrôdingerūs Cat. Whereas if I ssh to this system and issue the same command, I get Schrödinger’s Cat. Yeah, I saw it intermittently in final validation, seemed to affect minimal installs at least. The problem continues to plague Fedora. To work around the issue I added the following line to rc.local setfont latarcyrheb-sun16 Great idea with "setfont latarcyrheb-sun16", but to work on all my virtual consoles (six by default) I have to use this in rc.local: setfont -C /dev/tty1 latarcyrheb-sun16 setfont -C /dev/tty2 latarcyrheb-sun16 setfont -C /dev/tty3 latarcyrheb-sun16 setfont -C /dev/tty4 latarcyrheb-sun16 setfont -C /dev/tty5 latarcyrheb-sun16 setfont -C /dev/tty6 latarcyrheb-sun16 Works well, and users no longer need to run "unicode_start" in their shell login scripts. Thanks a lot, Eli, your workaround is the best so far! The problem still exists on Fedora-20-Alpha-TC4-x86_64-netinst.iso.
It has the release name
Fedora release 20 (null)
in /etc/redhat-release. But if I change the "null" to "Schrödinger’s cat"
and then reboot, I still see the same problem as on f19.
> tty0 was setup with setfont before the kms driver was loaded.
That leads to the question: Why isn't the KMS driver loaded earlier?
By the way, if you look closely, you'll notice the "ô" is actually a capital "Ô". (The O is a bit shrunk compared to an unaccented uppercase O due to the fixed total height, but it's larger than a lowercase o.) This package: http://mirror.yandex.ru/fedora/russianfedora/russianfedora/free/fedora/releases/19/Everything/x86_64/os/workaround-cyrillic-console-1.0-5.fc19.R.noarch.rpm (thanks nucleo for the link) (source code here: https://github.com/RussianFedora/workaround-cyrillic-console ) is basically the workaround from comment #9 packaged as a native systemd unit. Installing that workaround package makes the text consoles work properly (not just for Cyrillic, but also for all the other characters covered by latarcyrheb-sun16, including "Schrödinger’s Cat"), but it's not a complete workaround, the string at bootup (shown if you hit Esc in Plymouth) is still misprinted as "SchrÔdingerūs Cat". I think we really need to load the KMS drivers earlier. I found out that Arch Linux users have reported similar issues: https://bbs.archlinux.org/viewtopic.php?id=146743 but their mkinitcpio tool has a feature called "Early KMS" which reportedly fixes the issue for them. Does that load KMS earlier than we do with dracut? Can we do the same? (In reply to Kevin Kofler from comment #13) > Can we do the same? of course we could always workaround issues, but we could also fix the issue at the source... the kernel. > but we could also fix the issue at the source... the kernel.
Can we really? The issue has been open for 3½ months now, with no resolution in sight. It's a serious i18n issue, because this affects not only how the release name is printed, but also how non-ASCII characters entered in those ttys are printed. And it's not clear to me that loading KMS earlier is not actually the best fix. Right now we're stuck with worse workarounds such as that workaround-cyrillic-console RPM.
Now if you're sure that this can and should be fixed in the kernel, then can we PLEASE get that fixed there? This bug is breaking both i18n in general (as explained above) and the Fedora 19 release name in particular (which makes us look really bad). Having this bug ignored for so long is really not acceptable. (In fact, IMHO, it should have been a blocker, not just a freeze exception. But it's too late for that, now please at least fix it in an update!)
*** Bug 1000504 has been marked as a duplicate of this bug. *** *** Bug 1012470 has been marked as a duplicate of this bug. *** Fedora 19 # rpm -q kernel kernel-3.11.2-201.fc19.x86_64 kernel-3.11.3-201.fc19.x86_64 kernel-3.11.4-201.fc19.x86_64 # uname -a Linux dhcp137-228.rdu.redhat.com 3.11.4-201.fc19.x86_64 #1 SMP Thu Oct 10 14:11:18 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux Shown as: Schr?dinger?s Cat Created attachment 812721 [details]
? instead of i18n characters on bootup
That's unrelated to this bug. It's a GRUB 2 issue. (It can't show Unicode in plaintext mode, only in the graphics mode, if you rerun grub2-mkconfig, you get the graphics mode, there's a bug filed for the plaintext mode.) The problem still exists in Fedora-20-TC1-x86_64-netinst.iso. Problem still exists in official Fedora 20 release. Same workaround as in comments #8 and #9 *********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs. Fedora 19 has now been rebased to 3.13.5-100.fc19. Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel. If you experience different issues, please open a new bug report for those. Consoleoutput for 3.13.5-103 : Fedora release 19 (Schr?dinger?s Cat) Kernel 3.13.5-103.fc19.i686.PAE on an i686 (hvc0) unfortunatly, the copy&paste did harm one 'Umlaut' This is the correct display: ö is ok, but ' not. Fedora release 19 (Schrödinger?s Cat) Kernel 3.13.5-103.fc19.i686.PAE on an i686 (hvc0) This bug still happens (exactly as described, with "SchrÔdingerūs Cat") on 3.13.5-103.fc19.i686. (The bug in comment #24 and comment #25 is a different bug.) *********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs. Fedora 19 has now been rebased to 3.14.4-100.fc19. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 20, and are still experiencing this issue, please change the version to Fedora 20. If you experience different issues, please open a new bug report for those. Still issue with 3.14.4-200.fc20.x86_64. The problems is the unicode mode does not survive respawning agetty by systemd. Running "unicode_start" after logging in make consecutive UTF-8 output correct. Whether this is a feature or bug, it must be decided by TTY maintainers. *********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 20 kernel bugs. Fedora 20 has now been rebased to 3.17.2-200.fc20. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 21, and are still experiencing this issue, please change the version to Fedora 21. If you experience different issues, please open a new bug report for those. This bug is being closed with INSUFFICIENT_DATA as there has not been a response in over 3 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously. At least kernel-3.14.23-100.fc19.i686 (latest from F19 updates) still exhibits this bug. I don't have F20 yet, Petr Pisar, you bumped Version to 20, can you retest on F20 and/or F21 to see if it's still broken there too? Still broken with 3.17.4-200.fc20.x86_64 on F20. The only difference is respawning agetty does not reset the unicode mode anymore. (Systemd does not destroy the virtual console probably.) But still, when KMS driver gets loaded, the unicode mode is lost and until I run "unicode_start" manually, the console is not able to print wide characters. Should be fixed now or soon (I'm not sure if the right patch has been landed yet in F21 rpm) in systemd. We reinitalize unicode settings after the switch now. See also https://bugzilla.redhat.com/show_bug.cgi?id=1150384 , perhaps? Can this be fixed in 19 and 20? *********** MASS BUG UPDATE ************** We apologize for the inconvenience. There are a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 21 kernel bugs. Fedora 21 has now been rebased to 3.18.3-201.fc21. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you experience different issues, please open a new bug report for those. Just for the records: The problem did still exist in the initial release of Fedora 21 (can be verified easily on fresh F21 install), but one of the recent updates seems to have fixed it finally. Can no longer reproduce the issue on a fully patched Fedora 21 system. Looks good to me. Thanks for the update |