+++ This bug was initially created as a clone of Bug #927564 +++ - Minimal install of Fedora-19-Alpha-TC2-x86_64-netinst.iso At first login on the linux console, it looks as in the attached screenshot. I.e. it shows something like Fedora release 19 (Schrödinger▮s Cat) --- Additional comment from Mike FABIAN on 2013-03-26 10:03:39 CET --- The character displayed as a box is U+2019 RIGHT SINGLE QUOTATION MARK, utf-8 is #xE2 #x80 #x99 --- Additional comment from Mike FABIAN on 2013-03-26 10:07:41 CET --- This is only a font problem, for example after setfont latarcyrheb-sun16 this displays just fine as can be seen in the attachment. --- Additional comment from Chris Lumens on 2013-03-26 15:53:53 CET --- anaconda's not in the console font specifying or setting business anymore. --- Additional comment from Harald Hoyer on 2013-03-26 17:25:24 CET --- Does: # systemctl restart systemd-vconsole-setup.service fix the issue? Does booting with "plymouth.enable=0" fix the issue? --- Additional comment from Mike FABIAN on 2013-03-27 12:29:06 CET --- Harald, comment#4> Does: Harald, comment#4> Harald, comment#4> # systemctl restart systemd-vconsole-setup.service Harald, comment#4> Harald, comment#4> fix the issue? No, apparently it even makes it worse, see screen shot. --- Additional comment from Mike FABIAN on 2013-03-27 12:34:09 CET --- Harald, comment#4> Does booting with "plymouth.enable=0" fix the issue? No, see attached screen shot. --- Additional comment from Harald Hoyer on 2013-03-27 13:18:49 CET --- What is the contents of your /etc/vconsole.conf ? --- Additional comment from Harald Hoyer on 2013-03-27 13:20:23 CET --- What is the contents of your /etc/sysconfig/i18n ? --- Additional comment from Mike FABIAN on 2013-03-27 16:01:44 CET --- Harald, comment#7> What is the contents of your /etc/vconsole.conf ? KEYMAP="us' Harald, comment#8> What is the contents of your /etc/sysconfig/i18n ? This file does not exist. See attached screenshot. --- Additional comment from Harald Hoyer on 2013-04-02 09:50:07 CEST --- (In reply to comment #9) > Created attachment 717122 [details] > contents-of-etc-vconsole-conf-and-etc-sysconfig-i18n.png > > > Harald, comment#7> What is the contents of your /etc/vconsole.conf ? > > KEYMAP="us' > Well, you are missing a console FONT in vconsole.conf FONT=latarcyrheb-sun16 What is the contents of /etc/locale.conf? --- Additional comment from Mike FABIAN on 2013-04-02 10:13:22 CEST --- (In reply to comment #10) > (In reply to comment #9) > > Created attachment 717122 [details] > > contents-of-etc-vconsole-conf-and-etc-sysconfig-i18n.png > > > > > > Harald, comment#7> What is the contents of your /etc/vconsole.conf ? > > > > KEYMAP="us' > > > > Well, you are missing a console FONT in vconsole.conf > > FONT=latarcyrheb-sun16 Yes, but who should write “FONT=latarcyrheb-sun16” into vconsole.conf, if anaconda doesn’t do it, who should? > What is the contents of /etc/locale.conf? LANG="ja_JP.UTF-8" (or any other locale like en_US.UTF-8, doesn’t matter). --- Additional comment from Harald Hoyer on 2013-04-02 12:38:01 CEST --- (In reply to comment #11) > (In reply to comment #10) > > (In reply to comment #9) > > > Created attachment 717122 [details] > > > contents-of-etc-vconsole-conf-and-etc-sysconfig-i18n.png > > > > > > > > > Harald, comment#7> What is the contents of your /etc/vconsole.conf ? > > > > > > KEYMAP="us' > > > > > > > Well, you are missing a console FONT in vconsole.conf > > > > FONT=latarcyrheb-sun16 > > Yes, but who should write “FONT=latarcyrheb-sun16” into vconsole.conf, > if anaconda doesn’t do it, who should? anaconda should and have to!!! > > > What is the contents of /etc/locale.conf? > > LANG="ja_JP.UTF-8" > > (or any other locale like en_US.UTF-8, doesn’t matter). looks ok.. so UTF-8 is set here --- Additional comment from Harald Hoyer on 2013-04-02 12:40:23 CEST --- --- Additional comment from Harald Hoyer on 2013-04-02 12:42:39 CEST --- anaconda should fill in a unicode FONT in /etc/vconsole.conf --- Additional comment from Chris Lumens on 2013-04-02 20:29:49 CEST --- Why is this anaconda's job? Does the font ever differ between languages? If not, can't the system just assume a value now? --- Additional comment from Harald Hoyer on 2013-04-03 16:57:54 CEST --- (In reply to comment #15) > Why is this anaconda's job? Does the font ever differ between languages? > If not, can't the system just assume a value now? /etc/vconsole.conf is not shipped by systemd. It's only included as %ghost So, I would think the installer should fill it in. I don't know what the system console font should be in non-latin areas, but I guess FONT=latarcyrheb-sun16 is fine for most, if we want to display UTF-8 chars. --- Additional comment from Jens Petersen on 2013-04-04 03:38:53 CEST --- The string actually looks much worse for me again in current F19: both the "ö" and "’" are corrupted (rendered as garbage) - see attachment 730667 [details]. Worse "setfont latarcyrheb-sun16" or adding FONT=latarcyrheb-sun16 does not seem to fix the text for me. I am not sure what the current default is but setting FONT="latarcyrheb-sun16" sounds fine, but I am not sure if it will fix this problem, though I am no expert on kernel console fonts. Maybe someone has a solution - I know this should work and I think I was also seeing "Schrödinger■s Cat" earlier around TC2 I think. [F18 installs don't seem to have FONT set either. Though my own laptop which has now been running Fedora for almost 2 years does have it in "/etc/vconsole.conf" (probably it got migrated?).] --- Additional comment from Mike FABIAN on 2013-04-04 09:58:41 CEST --- (In reply to comment #17) > The string actually looks much worse for me again in current F19: > both the "ö" and "’" are corrupted (rendered as garbage) - > see attachment 730667 [details]. > Worse "setfont latarcyrheb-sun16" or adding FONT=latarcyrheb-sun16 > does not seem to fix the text for me. Right, now I need printf '\033%%G' setfont latarcyrheb-sun16 to fix it (see /bin/unicode_start). Previously, only the setfont was enough. > I am not sure what the current default is but setting > FONT="latarcyrheb-sun16" sounds fine, I also think this font is good enough for most cases. Anaconda used to have a mapping language -> console font but it used latarcyrheb-sun16 for almost all languages. I think the only exception was Greek where it used iso07u-16. For languages where no suitable console font exists anyway (Japanese, Chinese, ...) using latarcyrheb-sun16 seems OK as well. --- Additional comment from Jens Petersen on 2013-04-04 10:56:26 CEST --- (In reply to comment #18) > to fix it (see /bin/unicode_start). Previously, only the setfont > was enough. So maybe unicode_start was being used recently but not now, and should be enabled again? At least from my simple testing running "unicode_start" seems to be sufficient to fix the Schroedinger problem. --- Additional comment from Jens Petersen on 2013-04-04 11:08:34 CEST --- Or maybe just "printf '\033%%G'" was being run recently. 1) with just "printf '\033%%G'" I see "Schrödinger■s Cat" 2) with "printf '\033%%G'" and "setfont latarcyrheb-sun16" like Mike it is rendering fully correctly. unicode_start does more stuff - dunno if it is all desirable by default though it looks useful, but at least: FONT=latarcyrheb-sun16 and printf '\033%%G' seem necessary to render the F19 release name correctly. --- Additional comment from Harald Hoyer on 2013-04-04 13:33:23 CEST --- (In reply to comment #20) > Or maybe just "printf '\033%%G'" was being run recently. > > 1) with just "printf '\033%%G'" I see "Schrödinger■s Cat" > > 2) with "printf '\033%%G'" and "setfont latarcyrheb-sun16" like Mike > it is rendering fully correctly. > > unicode_start does more stuff - dunno if it is all desirable > by default though it looks useful, but at least: > > FONT=latarcyrheb-sun16 > > and > > printf '\033%%G' > > seem necessary to render the F19 release name correctly. Actually systemd-vconsole-setup does the "\033%G" writing, if the locale is UTF-8 and then calls keymap_load() and font_load(). Maybe something resets this state afterwards? Can you check, that you have: # fgrep systemd-vconsole /usr/lib/systemd/system/plymouth-start.service After=systemd-vconsole-setup.service systemd-udev-trigger.service and # lsinitrd /boot/initramfs-$(uname -r).img usr/lib/systemd/system/plymouth-start.service | fgrep systemd-vconsole After=systemd-vconsole-setup.service systemd-udev-trigger.service --- Additional comment from Kay Sievers on 2013-04-04 14:18:33 CEST --- This does not look like a unicode mode issue, or something that needs escape sequences printed. The unicode char takes only one space, it is just the wrong char but it seems like in unicode mode, otherwise we would likely see multiple chars instead of one. And just loading the font again on the active tty fixes all further output just fine, without any unicode mode changes. I rather suspect the kernel's font handling to not do enough, or something wrong. Maybe some unimap is not set up properly in the final state, and it does not survive the switch from the early-boot console driver (vga, efi) to the real console driver (kms). --- Additional comment from Kay Sievers on 2013-04-04 14:26:17 CEST --- (In reply to comment #20) > 1) with just "printf '\033%%G'" I see "Schrödinger■s Cat" You need to: cat /etc/os-release again. The already rendered text will not change. And if there is no FONT= in vconsole.conf, then the kernel's font is used and that font does not have that char. This seems like the correct, and expected behaviour. > 2) with "printf '\033%%G'" and "setfont latarcyrheb-sun16" like Mike > it is rendering fully correctly. Setfont should be enough, I don't think the printf matter here. > unicode_start does more stuff - dunno if it is all desirable > by default though it looks useful, but at least: > > FONT=latarcyrheb-sun16 Right, but it's still broken, probably in the kernel itself. Only loading the font later, not early at bootup, makes it work for all newly printed chars not for the already printed ones. Which might hint at a broken unimap handling not the chars/glyphs themselves. > and > > printf '\033%%G' > > seem necessary to render the F19 release name correctly. I don't think that's needed. It's the kernel's VT default anyway. --- Additional comment from Mike FABIAN on 2013-04-04 15:41:14 CEST --- (In reply to comment #22) > This does not look like a unicode mode issue, or something that needs escape > sequences printed. The unicode char takes only one space, it is just the > wrong char but it seems like in unicode mode, That is true for comment#0 and https://bugzilla.redhat.com/attachment.cgi?id=716369 it behaved like this in TC2. But it has changed recently, see comment#17. In TC4, we do se multiple characters. > otherwise we would likely see multiple chars instead of one. Right, this is what we see in TC4: SchrA¶dingerâÇÖs Cat So this is an issue of being not in Unicode mode. --- Additional comment from Mike FABIAN on 2013-04-04 15:43:36 CEST --- (In reply to comment #23) > (In reply to comment #20) > > 1) with just "printf '\033%%G'" I see "Schrödinger■s Cat" > > You need to: > cat /etc/os-release > again. The already rendered text will not change. Yes, of course, I did this and Jens did as well, I think. > And if there is no FONT= in vconsole.conf, then the kernel's font is used > and that font does not have that char. This seems like the correct, and > expected behaviour. > > > 2) with "printf '\033%%G'" and "setfont latarcyrheb-sun16" like Mike > > it is rendering fully correctly. > > Setfont should be enough, I don't think the printf matter here. Setfont was enough on TC2, it is not enough anymore on TC4. --- Additional comment from Jens Petersen on 2013-04-05 04:42:40 CEST --- (In reply to comment #21) > Actually systemd-vconsole-setup does the "\033%G" writing, if the locale is > UTF-8 and then calls keymap_load() and font_load(). Cool. Does it matter if FONT is set? > Maybe something resets this state afterwards? Perhaps > # fgrep systemd-vconsole /usr/lib/systemd/system/plymouth-start.service > After=systemd-vconsole-setup.service systemd-udev-trigger.service > > and > > # lsinitrd /boot/initramfs-$(uname -r).img > usr/lib/systemd/system/plymouth-start.service | fgrep systemd-vconsole > After=systemd-vconsole-setup.service systemd-udev-trigger.service They both output: Wants=systemd-ask-password-plymouth.path systemd-vconsole-setup.service After=systemd-vconsole-setup.service systemd-udev-trigger.service --- Additional comment from Jens Petersen on 2013-04-05 08:09:34 CEST --- Simple patch that also sets FONT=latarcyrheb-sun16 in "/etc/vconsole.conf". I think this is sufficient for now and an improvement over F18. Though if we are to hardcode the font I tend to agree that systemd could do that. Otherwise we can handle the Greek special case later. --- Additional comment from Jens Petersen on 2013-04-05 08:52:25 CEST --- updates=http://petersen.fedorapeople.org/console-font-update.img should provide a small installer update that include the above patch. --- Additional comment from Jens Petersen on 2013-04-05 09:33:34 CEST --- (In reply to comment #28) > updates=http://petersen.fedorapeople.org/console-font-update.img This didn't work for me sorry. Trying another patch. --- Additional comment from Jens Petersen on 2013-04-05 11:57:46 CEST --- updates=http://petersen.fedorapeople.org/console-font-update-2.img should actually contain the modified keyboard.py but it is not doing anything for me. However I am not very optimistic it will help since I have already done a lot of testing with rebooting with FONT=latarcyrheb-sun16 in "/etc/vconsole.conf" and it made no difference. A new data point though - today I did a Japanese Live TC4+anaconda-19.16 install and see "Schrödinger■s Cat" at the console login prompt. However again setting FONT in "/etc/vconsole.conf" did not help. I also tried adding FONT=latarcyrheb-sun16 (and SYSFONT for good measure) in "/etc/vconsole.conf" by hand before rebooting from the installer and this also does not work. So naively it looks like systemd is ignoring FONT in vconsole.conf? --- Additional comment from Jens Petersen on 2013-04-05 12:09:17 CEST --- I filed bug 948750 about systemd seemingly ignore FONT (and even vconsole.font I think) --- Additional comment from Jens Petersen on 2013-04-06 03:44:05 CEST --- I think once bug 948750 is fixed and if the above patch applied to anaconda (or at least "FONT=latarcyrheb-sun16" is added to /etc/vconsole.conf during installation) then this bug will be fixed from my testing on Alpha TC5 (see bug 948750#c4). --- Additional comment from Jens Petersen on 2013-04-06 04:03:12 CEST --- (sorry meant to post below here not in bug 948750) To recreate fix locally in TC5 minimal install: 1. add FONT=latarcyrheb-sun16 to vconsole.conf 2. run dracut -f 3. reboot either removing vconsole.keymap=.. *or* add vconsole.font=... to kernel boot line --- Additional comment from Jens Petersen on 2013-04-06 15:52:16 CEST --- Okay I finally worked out how to make an updates.img correctly from an anaconda src tree (using "make updates"). updates=http://petersen.fedorapeople.org/console-font-update3.img Currently it still seems necessary to run "dracut -f". --- Additional comment from Harald Hoyer on 2013-04-08 09:20:29 CEST --- (In reply to comment #34) > Okay I finally worked out how to make an updates.img correctly from > an anaconda src tree (using "make updates"). > > updates=http://petersen.fedorapeople.org/console-font-update3.img > > Currently it still seems necessary to run "dracut -f". If that is necessary, then you have to setup /etc/vconsole.conf before you run the rpm transaction installing all the packages, because in rpm posttrans dracut generates the initramfs images, which will then contain /etc/vconsole.conf of the system. --- Additional comment from Harald Hoyer on 2013-04-09 10:39:36 CEST --- systemd-201 fixes another issue, where unicode mode was not set, because /etc/locale.conf was not in the initramfs, because it was not yet setup when the rpm posttrans was running on installation, when dracut created the initramfs. --- Additional comment from Robert Lightfoot on 2013-04-15 03:45:39 CEST --- I am still seeing this issue or its cousin in F19-Alpha-TC6 --- Additional comment from Robert Lightfoot on 2013-04-15 03:49:36 CEST --- Fedora 19 Alpha Release Criteria state -- Any component which prominently identifies a Fedora release version number, code name or milestone (Alpha, Beta, Final) must do so correctly. I propose this for consideration as release blocker not freeze exception. --- Additional comment from Adam Williamson on 2013-04-15 18:14:27 CEST --- Discussed at 2013-04-15 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-04-15/f19alpha-blocker-review-7.2013-04-15-16.00.log.txt . Rejected as a blocker - good catch on the criteria, Bob, but the intent of that criterion is to ensure people don't get confused as to what they're running. This bug does make the name look kind of wacky, but it doesn't seem like we're in any danger of people mis-identifying it. We may need to tweak the wording of the criterion a bit in light of this one. --- Additional comment from Jens Petersen on 2013-04-16 12:09:40 CEST --- Even with systemd-201 in updates-testing however it seems the console is still not getting set to unicode mode after a fresh F19 install. Running "dracut -f" fixes it though. --- Additional comment from Harald Hoyer on 2013-04-16 13:10:11 CEST --- Another upstream fix: http://cgit.freedesktop.org/systemd/systemd/commit/?id=fee79e010f1f8ad2bce6b41c67e8ddd4f419ff4b If LANG=C, the console will not be set into non-unicode mode. Will be in systemd-202. --- Additional comment from Jens Petersen on 2013-04-17 02:37:13 CEST --- Thanks Harald! --- Additional comment from Jens Petersen on 2013-04-17 02:46:22 CEST --- Would it make sense then to default to a Unicode console font like latarcyrheb-sun16 too then in systemd if FONT is not set? --- Additional comment from Kay Sievers on 2013-04-17 11:06:09 CEST --- (In reply to comment #43) > Would it make sense then to default to a Unicode console font > like latarcyrheb-sun16 too then in systemd if FONT is not set? Probably not. Systemd should leave the kernel settings alone if no configuration is found. The installer should take care of that. --- Additional comment from Harald Hoyer on 2013-04-19 16:41:00 CEST --- (In reply to comment #41) > Another upstream fix: > http://cgit.freedesktop.org/systemd/systemd/commit/ > ?id=fee79e010f1f8ad2bce6b41c67e8ddd4f419ff4b > > If LANG=C, the console will not be set into non-unicode mode. > > Will be in systemd-202. systemd-202 in bodhi --- Additional comment from Mike FABIAN on 2013-04-26 11:27:14 CEST --- A netinstall of Fedora 19 Alpha contains systemd-202-3.fc19.x86_64 now. The console is in Unicode mode but the font is still wrong, “’” in “Schrödinger’s Cat” still displays as a box. Adding the font “latarcyrheb-sun16” to /etc/vconsole.font like this [mfabian@Fedora-19-Alpha-x86_64-netinst-r ~]$ cat /etc/vconsole.conf KEYMAP="us" FONT="latarcyrheb-sun16" [mfabian@Fedora-19-Alpha-x86_64-netinst-r ~]$ and rebooting does not fix the problem, the ’ is still displayed as a box. Manually calling “setfont latarcyrheb-sun16” fixes the problem though. --- Additional comment from Vít Ondruch on 2013-05-06 13:46:01 CEST --- Ping? What is the status here, please? --- Additional comment from Mike FABIAN on 2013-05-06 14:19:54 CEST --- After editing /etc/vconsole.conf as in comment#46 and calling dracut -f and rebooting, the problem is not fixed, the ’ is still displayed as a box. Manually calling “setfont latarcyrheb-sun16” fixes the problem though. --- Additional comment from Vít Ondruch on 2013-05-06 14:56:32 CEST --- Thanks Mike, I was more hoping in answer from Harald for example :) --- Additional comment from Lukáš Nykrýn on 2013-05-07 10:50:41 CEST --- --- Additional comment from Harald Hoyer on 2013-05-07 11:19:02 CEST --- (In reply to comment #48) > After editing /etc/vconsole.conf as in comment#46 and calling > > dracut -f > > and rebooting, the problem is not fixed, the ’ is still displayed as a > box. > > Manually calling “setfont latarcyrheb-sun16” fixes the problem though. If it's only one char, then the kernel driver handover does not work correctly, which is a kernel driver bug then. Somehow the map is not copied. --- Additional comment from Mike FABIAN on 2013-05-07 13:13:26 CEST --- (In reply to comment #51) > (In reply to comment #48) > > After editing /etc/vconsole.conf as in comment#46 and calling > > > > dracut -f > > > > and rebooting, the problem is not fixed, the ’ is still displayed as a > > box. > > > > Manually calling “setfont latarcyrheb-sun16” fixes the problem though. > > If it's only one char, then the kernel driver handover does not work > correctly, which is a kernel driver bug then. Somehow the map is not copied. There is only one char, ’ U+2019 RIGHT SINGLE QUOTATION MARK in the string which is not in the default console font. The font latarcyrheb-sun16 has a glyph for that character though. And “setfont latarcyrheb-sun16” works just fine. So I don’t see how this could be a kernel driver bug. It looks like whatever font is written to /etc/vconsole.conf like [mfabian@Fedora-19-Alpha-x86_64-netinst-r ~]$ cat /etc/vconsole.conf KEYMAP="us" FONT="latarcyrheb-sun16" [mfabian@Fedora-19-Alpha-x86_64-netinst-r ~]$ is completely ignored. Whether with “dracut -f” or without, the font information from /etc/vconsole.conf is just never used. --- Additional comment from Berend De Schouwer on 2013-05-09 13:26:50 CEST --- Here both the ö ’ are rendered wrong (/etc/issue; /etc/os-release) o is o^ ' is u" . /etc/vconsole.conf; setfont $FONT # fixes it. /etc/vconsole.conf: FONT=latarcyrheb-sun16 KEYMAP=us /etc/sysconfig/i18n: no such file. locale is en_ZA.utf8 (some things en_GB) systemd-203-2.fc19.x86_64 --- Additional comment from Vratislav Podzimek on 2013-05-09 21:58:39 CEST --- Bugs #889710 and #869233 are focusing on the same issue. I have a patch for the #869233 prepared for a long time, but it seemed to me that the problem lies somewhere else. From all the comments it seems to me obvious, that the Anaconda should write out the FONT=latarcyrheb-sun16 line to the /etc/vconsole.conf file. Sending a patch for it to anaconda-patches. --- Additional comment from Vratislav Podzimek on 2013-05-10 13:20:33 CEST --- The patch that adds the FONT=latarcyrheb-sun16 line to the /etc/vconsole.conf and vconsole.font=latarcyrheb-sun16 to boot options has been pushed. I think from Anaconda's side this is all we can do. If the issue still persists, please reassign this bug to dracut or systemd. If it is necessary to write the keyboard configuration before package installation, please let me know. But I believe that shouldn't be necessary and if yes, it is a bug in the dracut. --- Additional comment from Vratislav Podzimek on 2013-05-10 13:52:35 CEST --- I've just tested the patch and everything seems to okay. --- Additional comment from Jens Petersen on 2013-05-13 05:57:12 CEST --- Thanks this looks fixed in Fedora 19 Beta TC4 (anaconda-19.25-1.fc19). I still feel that dracut/systemd should just default to latarcyrheb-sun16, but I'll try and stay out of that bikeshed today... --- Additional comment from Adam Williamson on 2013-05-13 08:17:36 CEST --- 19.25 has actually been pushed stable already, so we can close this entirely. --- Additional comment from Chris Murphy on 2013-05-13 21:23:48 CEST --- So are the remaining issues I'm seeing in fresh installs of beta TC4 related to this bug or dracut/systemd? Because I'm seeing the following: New install on barebetal: SchrÔdingerūs Cat The o is an upper case O with circumflex. And the apostrophe is a lower case u with macron. New install on vbox: Schrödinger□s Cat That's with the correct lower case o with umlaut, but the apostrophe is a white box. --- Additional comment from Andre Robatino on 2013-05-13 21:34:39 CEST --- Are you installing from live or install images? I did minimal DVD installs in vbox and default DVD installs in KVM and the release name is correct in both (both umlaut and apostrophe). --- Additional comment from Chris Murphy on 2013-05-13 21:44:29 CEST --- (In reply to comment #60) > Are you installing from live or install images? Fedora-Live-Desktop-x86_64-19-Beta-TC4-1.iso --- Additional comment from Andre Robatino on 2013-05-13 23:35:29 CEST --- I can confirm that Fedora-Live-Desktop-i686-19-Beta-TC4-1.iso in vbox (either running live in a VT, or in the installed system) shows "Schrödinger□s Cat". (I chose the 32-bit image to fill out another box in the test matrix.) --- Additional comment from Mike FABIAN on 2013-05-14 01:10:35 CEST --- I still see the problem on a netinstall of Fedora-19-Beta-TC4-x86_64-netinst.iso [mfabian@Fedora-19-Beta-TC4-x86_64-netins ~]$ cat /etc/vconsole.conf KEYMAP="us" FONT="latarcyrheb-sun16" [mfabian@Fedora-19-Beta-TC4-x86_64-netins ~]$ --- Additional comment from Mike FABIAN on 2013-05-14 01:13:28 CEST --- --- Additional comment from Chris Murphy on 2013-05-14 04:51:00 CEST --- I failed to point out that this manifests in tty, not in Gnome Terminal, and does so in rescue, emergency, and multiuser target boots. The qemu result is the same as vbox: white box instead of apostrophe. --- Additional comment from Kay Sievers on 2013-05-14 05:15:51 CEST --- The issue only happens on the kernel virtual console, which just seems buggy; terminals running in X have no such issues. If you log into the box and do: $ setfont latarcyrheb-sun16 The screen content changes and you see other "garbage" instead of the white box, right? If you then do: $ cat /etc/os-release The newly rendered text looks fine, while the earlier printed doesn't, right? If that's the case, I still expect the issue in comment#22 to be the reason, and this cannot really be solved in userspace tools, it would need a fix in the kernel to preserve the unicode mapping at console driver switching. --- Additional comment from Chris Murphy on 2013-05-14 05:18:20 CEST --- At least on qemu, problem does occur as previously described with kernel 3.9.0-301 but does not occur with kernel 3.9.1-301. dracut-027-45.git20130430.fc19.x86_64 produced both initramfs's, the 3.9.0 one was produced under the Live environment, however. When I use dracut to build a new 3.9.0 initramfs, after reboot, neither 3.9.0 or 3.9.1 boot options exhibit the problem. --- Additional comment from Chris Murphy on 2013-05-14 05:27:58 CEST --- (In reply to comment #66) > The newly rendered text looks fine, while the earlier printed doesn't, right? Yes. In virt-manager, booting beta TC4 and dropping to tty2, I get the result in comment 59 for bare metal, and the same result for cat /etc/os-release. After setfont latarcyrheb-sun16, subsequent cat /etc/os-release appears correctly, and so does the tagline+login prompt if I use the exit command (yet remain in tty2). So something about the Live state isn't right, part of which is baked into the installed OS's initramfs which causes partial problems upon reboot in the newly installs OS. But upon rebuilding the initramfs while booted from the installed OS instead of the Live environment, the problem appears to be resolved. Same kernel and dracut versions, no updates have yet been done. Kinda curious. --- Additional comment from Jens Petersen on 2013-05-14 11:03:19 CEST --- Live does not have a /etc/vconsole.conf file and hence the default console unicode font is used which does not have the apostrophe sign. Maybe better to open a separate bug for the Live case unless more people can reproduce for non-Live installs. --- Additional comment from Mike FABIAN on 2013-05-14 11:23:52 CEST --- Jens, comment#69> Live does not have a /etc/vconsole.conf file and hence the default Jens, comment#69> console unicode font is used which does not have the apostrophe sign. My netinstall of TC4 does have /etc/vconsole.conf and the contents look correct. Jens, comment#69> Maybe better to open a separate bug for the Live case Jens, comment#69> unless more people can reproduce for non-Live installs. I can reproduce for a netinstall, see comment#63 and comment#64. --- Additional comment from Jens Petersen on 2013-05-15 09:55:48 CEST --- You're right I see "Schrödinger▮s Cat" too now on a fresh minimal Japanese f19 Beta TC4 net install. Reopening. Now I am wondering why it worked for me in my first TC4 Gnome install (comment 57). --- Additional comment from Vratislav Podzimek on 2013-05-15 10:15:55 CEST --- (In reply to comment #71) > You're right I see "Schrödinger▮s Cat" too now on a fresh minimal > Japanese f19 Beta TC4 net install. Reopening. What are the contents of the /etc/vconsole.conf file? And is the 'vconsole.font=latarcyrheb-sun16' in /etc/grub2.cfg as a boot option? If there is 'FONT=latarcyrheb-sun16' in the conf file and so is the boot option in the grub config, please reassign this bug to systemd or kernel, because Anaconda can hardly do anything more. --- Additional comment from Vít Ondruch on 2013-05-15 11:10:32 CEST --- (In reply to comment #72) > (In reply to comment #71) > > You're right I see "Schrödinger▮s Cat" too now on a fresh minimal > > Japanese f19 Beta TC4 net install. Reopening. > What are the contents of the /etc/vconsole.conf file? $ cat /etc/vconsole.conf KEYMAP=cz-us-qwertz FONT=latarcyrheb-sun16 > And is the > 'vconsole.font=latarcyrheb-sun16' in /etc/grub2.cfg as a boot option? # cat /etc/grub2.cfg | grep latarcyrheb-sun16 linux /vmlinuz-3.9.1-301.fc19.x86_64 root=UUID=29a15114-4d0f-4139-be03-47e098da8da8 ro rootflags=subvol=F19_-_root rd.md=0 rd.dm=0 rd.lvm.lv=vg_dhcp251/lv_swap_f17 rd.luks=0 vconsole.font=latarcyrheb-sun16 rd.lvm.lv=vg_dhcp251/lv_root_f19 vconsole.keymap=cz-lat2 rd.lvm.lv=vg_dhcp251/lv_swap_f18 rd.lvm.lv=vg_dhcp251/lv_swap_f19 rhgb quiet LANG=cs_CZ.UTF-8 linux /vmlinuz-3.9.0-301.fc19.x86_64 root=/dev/mapper/vg_dhcp251-lv_root_f19 ro rootflags=subvol=F19_-_root rd.md=0 rd.dm=0 rd.lvm.lv=vg_dhcp251/lv_swap_f17 rd.luks=0 vconsole.font=latarcyrheb-sun16 rd.lvm.lv=vg_dhcp251/lv_root_f19 vconsole.keymap=cz-lat2 rd.lvm.lv=vg_dhcp251/lv_swap_f18 rd.lvm.lv=vg_dhcp251/lv_swap_f19 rhgb quiet linux /vmlinuz-3.8.9-200.fc18.x86_64 root=/dev/mapper/vg_dhcp251-lv_root_f19 ro rootflags=subvol=F19_-_root rd.md=0 rd.dm=0 rd.lvm.lv=vg_dhcp251/lv_swap_f17 rd.luks=0 vconsole.font=latarcyrheb-sun16 rd.lvm.lv=vg_dhcp251/lv_root_f19 vconsole.keymap=cz-lat2 rd.lvm.lv=vg_dhcp251/lv_swap_f18 rd.lvm.lv=vg_dhcp251/lv_swap_f19 rhgb quiet linux /vmlinuz-3.8.8-202.fc18.x86_64 root=/dev/mapper/vg_dhcp251-lv_root_f19 ro rootflags=subvol=F19_-_root rd.md=0 rd.dm=0 rd.lvm.lv=vg_dhcp251/lv_swap_f17 rd.luks=0 vconsole.font=latarcyrheb-sun16 rd.lvm.lv=vg_dhcp251/lv_root_f19 vconsole.keymap=cz-lat2 rd.lvm.lv=vg_dhcp251/lv_swap_f18 rd.lvm.lv=vg_dhcp251/lv_swap_f19 rhgb quiet linux /vmlinuz-3.8.6-203.fc18.x86_64 root=/dev/mapper/vg_dhcp251-lv_root_f19 ro rootflags=subvol=F19_-_root rd.md=0 rd.dm=0 rd.lvm.lv=vg_dhcp251/lv_swap_f17 rd.luks=0 vconsole.font=latarcyrheb-sun16 rd.lvm.lv=vg_dhcp251/lv_root_f19 vconsole.keymap=cz-lat2 rd.lvm.lv=vg_dhcp251/lv_swap_f18 rd.lvm.lv=vg_dhcp251/lv_swap_f19 rhgb quiet linux /vmlinuz-3.6.2-4.fc17.x86_64 root=/dev/mapper/vg_dhcp251-lv_root_f19 ro rootflags=subvol=F19_-_root rd.md=0 rd.dm=0 rd.lvm.lv=vg_dhcp251/lv_swap_f17 rd.luks=0 vconsole.font=latarcyrheb-sun16 rd.lvm.lv=vg_dhcp251/lv_root_f19 vconsole.keymap=cz-lat2 rd.lvm.lv=vg_dhcp251/lv_swap_f18 rd.lvm.lv=vg_dhcp251/lv_swap_f19 rhgb quiet linux /vmlinuz-0-rescue-8550f98ca7ec4f5b9d8fb75ef595bc17 root=/dev/mapper/vg_dhcp251-lv_root_f19 ro rootflags=subvol=F19_-_root rd.md=0 rd.dm=0 rd.lvm.lv=vg_dhcp251/lv_swap_f17 rd.luks=0 vconsole.font=latarcyrheb-sun16 rd.lvm.lv=vg_dhcp251/lv_root_f19 vconsole.keymap=cz-lat2 rd.lvm.lv=vg_dhcp251/lv_swap_f18 rd.lvm.lv=vg_dhcp251/lv_swap_f19 rhgb quiet > If there is 'FONT=latarcyrheb-sun16' in the conf file and so is the boot option > in the grub config, please reassign this bug to systemd or kernel, because > Anaconda can hardly do anything more. --- Additional comment from Jens Petersen on 2013-05-15 12:14:08 CEST --- Also got "Schrödinger▮s Cat" in a fresh TC4 Japanese GNOME net install and for a Live install. I guess this is because vconsole.conf currently needs to be written before anaconda starts to install packages for dracut to pick it up. Though I am not sure how it will work for the Live install case? --- Additional comment from Vratislav Podzimek on 2013-05-15 12:48:55 CEST --- (In reply to comment #74) > Also got "Schrödinger▮s Cat" in a fresh TC4 Japanese GNOME net install > and for a Live install. > > I guess this is because vconsole.conf currently needs to be written before > anaconda starts to install packages for dracut to pick it up. I really think that having the font specified on the command line should work. It would be a hack to write this configuration before package installation, nothing else works that way in the Anaconda. --- Additional comment from Jens Petersen on 2013-05-16 11:11:56 CEST --- I agree that setting vconsole.font on the kernel commandline should be sufficient. Some installs it is working for me, others not. Moving to systemd based on comment 72 and comment 73. --- Additional comment from Jens Petersen on 2013-05-16 11:16:21 CEST --- (or maybe better to open a bug - the anaconda side has been fixed anyway but there still seem to be some edge case on systemd/dracut side) --- Additional comment from Adam Williamson on 2013-05-20 20:53:29 CEST --- Discussed at 2013-05-20 freeze exception review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-05-20/f19beta-blocker-review-7.2013-05-20-16.07.log.txt . Agreed that it's now late in Beta cycle and: a) we're not totally clear what still needs changing here b) whatever it is, it's probably in something very critical (grub2, grubby, kernel or systemd) accordingly, this is rejected as a freeze exception issue for Beta. It's obviously ugly, but the dangers of trying to fix it any harder outweigh the benefits. We should certainly try and ensure it's fixed for Final, though. --- Additional comment from Jens Petersen on 2013-05-23 09:55:22 CEST --- A workaround for the remaining Live case would be to set vconsole.fonts=latarcyrheb-sun16 on the syslinux kernel line. The non-Live install only seems to work since vconsole.fonts is set on the grub kernel boot line. However I feel that vconsole.fonts and vconsole.keymap should not really be set by default on Fedora's kernel line. I still think Fedora should just default to latarcyrheb-sun16 (unless a different font is specified through anaconda for a particular locale). --- Additional comment from Nix\ on 2013-05-29 14:03:46 CEST --- The bug is present on fedora beta 1, show: Schrödinger▮s Cat on boot. After complete update (29 May 2013) and reboot the bug is solved. --- Additional comment from Harald Hoyer on 2013-05-31 10:26:32 CEST --- https://admin.fedoraproject.org/updates/dracut-027-81.git20130531.fc19 has another fix. dracut was installing LatArCyrHeb-16 instead of latarcyrheb-sun16 as the default fallback font, if vconsole.conf was empty. So, now if vconsole.font=latarcyrheb-sun16 is specified on the kernel command line, it should work out of the box. --- Additional comment from Vít Ondruch on 2013-05-31 14:51:11 CEST --- I have update dracut, but it still does not work for me :/ --- Additional comment from Harald Hoyer on 2013-05-31 16:20:05 CEST --- (In reply to Vít Ondruch from comment #82) > I have update dracut, but it still does not work for me :/ does your kernel cmdline has "vconsole.font=latarcyrheb-sun16" and did you update the initramfs after updating? --- Additional comment from Vít Ondruch on 2013-05-31 16:24:44 CEST --- (In reply to Harald Hoyer from comment #83) > does your kernel cmdline has "vconsole.font=latarcyrheb-sun16" # cat /etc/grub2.cfg | grep latarcyrheb-sun16 linux /vmlinuz-3.9.4-300.fc19.x86_64 root=UUID=29a15114-4d0f-4139-be03-47e098da8da8 ro rootflags=subvol=F19_-_root rd.md=0 rd.dm=0 rd.luks=0 vconsole.font=latarcyrheb-sun16 rd.lvm.lv=vg_dhcp251/lv_root_f19 vconsole.keymap=cz-lat2 rd.lvm.lv=vg_dhcp251/lv_swap_f19 rhgb quiet LANG=cs_CZ.UTF-8 < ... snip ... > > and did you update the initramfs after updating? No. Why should I do that? How should I do that? What everybody else who has already installed F19 as I do. --- Additional comment from Vít Ondruch on 2013-05-31 16:35:23 CEST --- Actually, after installing new dracut, I updated kernel in next step, this should do the job, shouldn't it? --- Additional comment from Igor Gnatenko on 2013-05-31 18:12:59 CEST --- $ cat /proc/cmdline BOOT_IMAGE=/vmlinuz-3.9.4-300.fc19.x86_64 root=/dev/mapper/fedora_thinkpad--x230-root ro rd.md=0 rd.dm=0 rd.lvm.lv=fedora_thinkpad-x230/root vconsole.keymap=us rd.luks=0 vconsole.font=latarcyrheb-sun16 rd.lvm.lv=fedora_thinkpad-x230/swap rhgb quiet $ cat /etc/vconsole.conf KEYMAP=us tested with "FONT" in vconsole and without. Not working. Schrödinger’s Cat ö -> o with ^ ’ -> u with - --- Additional comment from Igor Gnatenko on 2013-05-31 18:14:12 CEST --- I updated initrd. dracut -f --- Additional comment from Igor Gnatenko on 2013-05-31 18:20:31 CEST --- Manual setfont works correctly. --- Additional comment from Harald Hoyer on 2013-06-03 13:01:30 CEST --- This screenshot shows the symptoms of the kernel bug, kay and me mentioned in comment 22, comment 23 and comment 51. There is nothing systemd, dracut and setfont can do about it. A kernel bug should be filed, that the unimap is not copied like the font glyphs are.
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