Bug 970030 - F19 release-name “Schrödinger’s Cat” shown as "SchrÔdingerūs Cat" on the linux console
F19 release-name “Schrödinger’s Cat” shown as "SchrÔdingerūs Cat" on the lin...
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
20
All Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
AcceptedFreezeException
: i18n, Reopened
: 1000504 1012470 (view as bug list)
Depends On:
Blocks: F19-accepted/F19FinalFreezeException
  Show dependency treegraph
 
Reported: 2013-06-03 07:07 EDT by Vít Ondruch
Modified: 2015-01-28 08:52 EST (History)
55 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 927564
Environment:
Last Closed: 2015-01-28 08:52:55 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Screenshot of kernel bug. (381.31 KB, image/jpeg)
2013-06-03 07:20 EDT, Harald Hoyer
no flags Details
? instead of i18n characters on bootup (174.47 KB, image/png)
2013-10-15 21:58 EDT, Jesus M. Rodriguez
no flags Details

  None (edit)
Description Vít Ondruch 2013-06-03 07:07:06 EDT
+++ 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.
Comment 1 Harald Hoyer 2013-06-03 07:20:43 EDT
Created attachment 756252 [details]
Screenshot of kernel bug.

attaching screenshot of kernel bug again.
Comment 2 Harald Hoyer 2013-06-03 07:23:00 EDT
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.
Comment 3 Adam Williamson 2013-06-03 12:10:09 EDT
Clean up some metadata crap from the cloning.
Comment 4 Hans de Goede 2013-06-08 15:50:22 EDT
(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.
Comment 5 Adam Williamson 2013-06-20 13:07:51 EDT
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.
Comment 6 Chris Murphy 2013-07-03 02:24:11 EDT
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.
Comment 7 Adam Williamson 2013-07-03 02:25:54 EDT
Yeah, I saw it intermittently in final validation, seemed to affect minimal installs at least.
Comment 8 Eli Wapniarski 2013-07-03 06:17:25 EDT
The problem continues to plague Fedora.

To work around the issue I added the following line to rc.local


setfont latarcyrheb-sun16
Comment 9 Andreas M. Kirchwitz 2013-07-23 21:36:52 EDT
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!
Comment 10 Mike FABIAN 2013-09-06 01:42:28 EDT
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.
Comment 11 Kevin Kofler 2013-09-17 20:02:04 EDT
> tty0 was setup with setfont before the kms driver was loaded.

That leads to the question: Why isn't the KMS driver loaded earlier?
Comment 12 Kevin Kofler 2013-09-17 20:06:07 EDT
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.)
Comment 13 Kevin Kofler 2013-09-18 07:24:45 EDT
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?
Comment 14 Harald Hoyer 2013-09-20 02:04:29 EDT
(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.
Comment 15 Kevin Kofler 2013-09-21 17:41:43 EDT
> 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!)
Comment 16 Lennart Poettering 2013-09-29 14:04:33 EDT
*** Bug 1000504 has been marked as a duplicate of this bug. ***
Comment 17 Lennart Poettering 2013-09-29 14:24:12 EDT
*** Bug 1012470 has been marked as a duplicate of this bug. ***
Comment 18 Jesus M. Rodriguez 2013-10-15 21:38:51 EDT
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
Comment 19 Jesus M. Rodriguez 2013-10-15 21:58:01 EDT
Created attachment 812721 [details]
? instead of i18n characters on bootup
Comment 20 Kevin Kofler 2013-10-16 16:50:58 EDT
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.)
Comment 21 Mike FABIAN 2013-11-18 11:27:15 EST
The problem still exists in Fedora-20-TC1-x86_64-netinst.iso.
Comment 22 Andreas M. Kirchwitz 2014-01-07 09:20:08 EST
Problem still exists in official Fedora 20 release.
Same workaround as in comments #8 and #9
Comment 23 Justin M. Forbes 2014-03-10 10:50:23 EDT
*********** 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.
Comment 24 customercare 2014-03-10 10:56:40 EDT
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)
Comment 25 customercare 2014-03-10 10:59:14 EDT
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)
Comment 26 Kevin Kofler 2014-03-10 12:07:39 EDT
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.)
Comment 27 Justin M. Forbes 2014-05-21 15:30:32 EDT
*********** 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.
Comment 28 Petr Pisar 2014-05-22 01:59:16 EDT
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.
Comment 29 Justin M. Forbes 2014-11-13 11:03:13 EST
*********** 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.
Comment 30 Justin M. Forbes 2014-12-10 10:02:18 EST
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.
Comment 31 Kevin Kofler 2014-12-10 10:27:50 EST
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?
Comment 32 Petr Pisar 2014-12-10 10:50:18 EST
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.
Comment 33 Zbigniew Jędrzejewski-Szmek 2014-12-10 11:32:56 EST
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.
Comment 34 Adam Williamson 2014-12-10 13:57:49 EST
See also https://bugzilla.redhat.com/show_bug.cgi?id=1150384 , perhaps?

Can this be fixed in 19 and 20?
Comment 35 Justin M. Forbes 2015-01-27 10:01:54 EST
*********** 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.
Comment 36 Andreas M. Kirchwitz 2015-01-27 22:50:44 EST
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.
Comment 37 Justin M. Forbes 2015-01-28 08:52:55 EST
Thanks for the update

Note You need to log in before you can comment on or make changes to this bug.