Created attachment 716369 [details] Schrödinger’s-Cat-with-box.png - 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)
The character displayed as a box is U+2019 RIGHT SINGLE QUOTATION MARK, utf-8 is #xE2 #x80 #x99
Created attachment 716371 [details] Schrödinger’s-Cat-with-apostrophe.png This is only a font problem, for example after setfont latarcyrheb-sun16 this displays just fine as can be seen in the attachment.
anaconda's not in the console font specifying or setting business anymore.
Does: # systemctl restart systemd-vconsole-setup.service fix the issue? Does booting with "plymouth.enable=0" fix the issue?
Created attachment 717004 [details] systemctl-restart-systemd-vconsole-setup.service.png 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.
Created attachment 717006 [details] booted-with-plymouth.enable=0.png Harald, comment#4> Does booting with "plymouth.enable=0" fix the issue? No, see attached screen shot.
What is the contents of your /etc/vconsole.conf ?
What is the contents of your /etc/sysconfig/i18n ?
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' Harald, comment#8> What is the contents of your /etc/sysconfig/i18n ? This file does not exist. See attached screenshot.
(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?
(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).
(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
*** Bug 947378 has been marked as a duplicate of this bug. ***
anaconda should fill in a unicode FONT in /etc/vconsole.conf
Why is this anaconda's job? Does the font ever differ between languages? If not, can't the system just assume a value now?
(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.
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?).]
(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.
(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.
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.
(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
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).
(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.
(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.
(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.
(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
Created attachment 731830 [details] anaconda-19-console-font.patch 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.
updates=http://petersen.fedorapeople.org/console-font-update.img should provide a small installer update that include the above patch.
(In reply to comment #28) > updates=http://petersen.fedorapeople.org/console-font-update.img This didn't work for me sorry. Trying another patch.
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?
I filed bug 948750 about systemd seemingly ignore FONT (and even vconsole.font I think)
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).
(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
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".
(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.
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.
Created attachment 735713 [details] Schroedinger's Cat with incorrect characters Alpha-TC6 I am still seeing this issue or its cousin in F19-Alpha-TC6
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.
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.
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.
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.
Thanks Harald!
Would it make sense then to default to a Unicode console font like latarcyrheb-sun16 too then in systemd if FONT is not set?
(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.
(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
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.
Ping? What is the status here, please?
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.
Thanks Mike, I was more hoping in answer from Harald for example :)
*** Bug 960460 has been marked as a duplicate of this bug. ***
(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.
(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.
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
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.
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.
Created attachment 746131 [details] screenshot from the system installed with the patch applied I've just tested the patch and everything seems to okay.
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...
19.25 has actually been pushed stable already, so we can close this entirely.
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.
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).
(In reply to comment #60) > Are you installing from live or install images? Fedora-Live-Desktop-x86_64-19-Beta-TC4-1.iso
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.)
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 ~]$
Created attachment 747465 [details] screenshot-from-netinstall-of-Fedora-19-Beta-x86_64-netinstall.png
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.
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.
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.
(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.
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.
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.
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).
(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.
(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.
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?
(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.
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.
(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)
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.
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).
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.
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.
I have update dracut, but it still does not work for me :/
(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?
(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.
Actually, after installing new dracut, I updated kernel in next step, this should do the job, shouldn't it?
$ 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 -
I updated initrd. dracut -f
Manual setfont works correctly.
Created attachment 756238 [details] Screenshot of kernel bug. 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.
I cloned this thread for Kernel as bug 970030. Lets see what they think about it.
general note to the wind: cloning bugs is often not the best idea. Especially when a bug has 88 comments. I find cloning is only (marginally) useful when you really need to report *the exact same bug* for a different product or whatever (Fedora vs. RHEL). 'Cloning' for a somewhat-related-but-not-really-the-same issue just creates all kinds of noise - a giant, impossible to read bug description, a bunch of metadata that is not appropriate, and CCs for lots of people who may not care.
The dracut update from c#81 is now stable, so closing this. Please follow up on the new kernel bug and only re-open this if it turns out fixes are still needed in dracut or systemd.
Yes, wow it seems fixed now. :)