Bug 889710 - VT is not put into an unicode mode
VT is not put into an unicode mode
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
19
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: systemd-maint
Fedora Extras Quality Assurance
AcceptedNTH RejectedBlocker https://f...
: CommonBugs
: 891353 (view as bug list)
Depends On:
Blocks: F18-accepted/F18FinalFreezeExcept
  Show dependency treegraph
 
Reported: 2012-12-22 15:17 EST by Reartes Guillermo
Modified: 2014-07-22 22:41 EDT (History)
31 users (show)

See Also:
Fixed In Version: anaconda-19.25-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-07-22 22:38:42 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
screenshot after trying the workaround from comment #10 (37.42 KB, image/png)
2013-01-01 18:26 EST, Reartes Guillermo
no flags Details
screenshot showing incorrect characters after running "lsblk" (9.92 KB, image/png)
2013-01-01 19:10 EST, Steve Tyler
no flags Details
screenshot showing correct characters after running "lsblk" (11.66 KB, image/png)
2013-01-01 19:15 EST, Steve Tyler
no flags Details

  None (edit)
Description Reartes Guillermo 2012-12-22 15:17:00 EST
Description of problem:

With these commands:

# localectl set-keymap es
# loadkeys es

I have the following issue: They do work correctly when executed from the tested Fedora DVDs, but they produce unexpected results when executed from the installed systems. Result: no 'ñ' and others.

Also i install with Spanish keyboard configured in anaconda. The installed system does have the keyboard configured but some specific characters output "JUNK".

Performed Tests:
 
TRY#1: INSTALLED a F18 instance (MINIMAL#1) and tested it.
TRY#2: INSTALLED a F18 instance (MINIMAL#2) and tested it.
TRY#3: Re-Tested from F18-TC2 DVD (NO INSTALLATION) 
TRY#4: Re-Tested from F18-smoke12 (anaconda 18.37.8) DVD (NO INSTALLATION)
TRY#5: INSTALLED a F18 instance (KDE) and tested it.

Version-Release number of selected component (if applicable):
Several, TC2 (18.37.3) and smoke12 (18.37.8)

How reproducible:
always
  
Actual results:
some characters like the 'ñ' output "JUNK"


Additional info:
I will put each test in its own comment.
Comment 1 Reartes Guillermo 2012-12-22 15:18:53 EST
TRY#1 PERFORMED STEPS:

0. Boot (no kernel parameter) F18-TC3 (anaconda 18.37.3)

1. WELCOME SCREEN:
  * Select 'Español(España)    Spanish(Spain)'
  * Leave unchecked: 'Set keyboard default layout for selected language'

2. MAIN HUB: KEYBOARD:
  * Change the Keyboard to 'Spanish; Castillian (Spanish)'
  * Installed MINIMAL

3. STORAGE: INSTALLATION DESTINATION
  * AUTOMATIC PARTITIONING: STANDARD PARTITIONS (Single Disk)

4. SOFTWARE SELECTION: MINIMAL

5. DATE & TIME:
  * America/Argentina/Buenos_Aires
  * NTP OFF
  
TRY#1: RESULTS (INSTALLED F18 SYSTEM):

# localectl status
 System Locale: LANG=es_ES.UTF-8
       VC Keymap: es
      X11 Layout: n/a
      
Does the 'ñ' work at VT (no X11): NO, "JUNK" is shown.

# localectl list-keymaps | grep -i es
es
es-cp850
es-oplc
mac-es
sun4-es
sun5-es

I tried 'localectl set-keymap' to all these but the problem with 'ñ' and others remained.

Note: Do NOT use/try 'mac-es', the keyboard will become useless. 

I power-cycled the guest, but that was not enough, i should have used loadkeys instead for testing... :-(
Comment 2 Reartes Guillermo 2012-12-22 15:20:03 EST
TRY#2 PERFORMED STEPS:

0. Boot (no kernel parameter) F18-TC3 (anaconda 18.37.3)

1. WELCOME SCREEN:
  * Select 'Español(España)    Spanish(Spain)'
  * Check: 'Set keyboard default layout for selected language'

2. MAIN HUB: KEYBOARD:
  * Change the Keyboard to 'Spanish; Castillian (Spanish)'

3. STORAGE: INSTALLATION DESTINATION
  * AUTOMATIC PARTITIONING: STANDARD PARTITIONS (Single Disk)

4. SOFTWARE SELECTION: MINIMAL

5. DATE & TIME:
  * America/Argentina/Buenos_Aires
  * NTP OFF

TRY#2: RESULTS (INSTALLED F18 SYSTEM):

# localectl status
 System Locale: LANG=es_ES.UTF-8
       VC Keymap: es
      X11 Layout: n/a
      
Does the 'ñ' work at VT (no X11): NO, "JUNK" is shown.
So, basically it is the same as TRY#1.

Additionally, using 'loadkeys es' does not fix the issue.
Comment 3 Reartes Guillermo 2012-12-22 15:21:08 EST
TRY#3 PERFORMED STEPS:

0. Boot (no kernel parameter) F18-TC3 (anaconda 18.37.3)
1. At the WELCOME SCREEN: switch to VT2

# localectl status
 System Locale: LANG=C
       VC Keymap: n/a
      X11 Layout: n/a

Does the 'ñ' work at VT (no X11): NO, but the ';' character is shown, witch indicates that the keyboard is in 'us' mode...  
This is OK at the moment and expected. No issue for now.

I tried a 'localectl set-keymap es' and it worked as expected, unlike an installed system. (TRY#1, TRY#2) 

Does the 'ñ' work at VT (no X11): YES.
So why it worked from the F18-TC3 DVD and not from an installed system? 
Isn't it odd?

Do setps #0 and #1 again, since i cannot return to a "n/a" status  for the 'VC keymap'.

I tried a 'loadkeys es' and it worked as expected, also unlike an installed system. This is definitively strange.

But why loadkeys did work from the F18-TC3 DVD and not from an installed system? I return the keyboard to us with 'loadkeys us'. This did not affect localectl status output which is still n/a (this seems to be ok).
Comment 4 Reartes Guillermo 2012-12-22 15:21:36 EST
TRY#4: PERFORMED STEPS:

0. Boot (no kernel parameter) F18-smoke12 (anaconda 18.37.8)

1. WELCOME SCREEN:
  * Select 'Español(España)    Spanish(Spain)'
  * Leave unckecked: 'Set keyboard default layout for selected language'

2. MAIN HUB: KEYBOARD:
  * Change the Keyboard to 'Spanish; Castillian (Spanish)'
Installed MINIMAL

3. STORAGE: INSTALLATION DESTINATION
  * AUTOMATIC PARTITIONING: STANDARD PARTITIONS (Single Disk)

4. SOFTWARE SELECTION: MINIMAL

5. DATE & TIME:
  * America/Argentina/Buenos_Aires
  * NTP OFF

TRY#4: RESULTS (INSTALLED F18 SYSTEM):

# localectl status
 System Locale: LANG=es_ES.UTF-8
       VC Keymap: es
      X11 Layout: n/a

Does the 'ñ' work at VT (no X11): NO, "JUNK" is shown.
So, basically it is the same as TRY#1.

Reboot the guest and try again. No improvement.
Comment 5 Reartes Guillermo 2012-12-22 15:22:40 EST
TRY#5 PERFORMED STEPS:

0. Boot (no kernel parameter) F18-TC2 (anaconda 18.37.3)

1. WELCOME SCREEN:
  * Select 'Español(España)    Spanish(Spain)'
  * Leave unchecked: 'Set keyboard default layout for selected language'

2. MAIN HUB: KEYBOARD:
  * Change the Keyboard to 'Spanish; Castillian (Spanish)'
  * Installed MINIMAL

3. STORAGE: INSTALLATION DESTINATION
  * AUTOMATIC PARTITIONING: STANDARD PARTITIONS (Single Disk)

4. SOFTWARE SELECTION: KDE

5. DATE & TIME:
  * America/Argentina/Buenos_Aires
  * NTP OFF

TRY#5: RESULTS (INSTALLED F18 SYSTEM):

Boot and switch to another VT (do not login to KDE)

# localectl status
 System Locale: LANG=es_ES.UTF-8
       VC Keymap: es
      X11 Layout: n/a

Does the 'ñ' work at VT (no X11): NO, but the ';' character is shown, witch indicates that the keyboard is in 'us' mode...  This is NOT ok in this case, isn't it?

By 'loadkeys es' the 'ñ' now can be used. 

Now reboot the guest. At KDM, login to KDE and open konsole.

# localectl status
 System Locale: LANG=es_ES.UTF-8
       VC Keymap: es
      X11 Layout: n/a

Does the 'ñ' work at VT (no X11): YES, all is OK.

Now reboot the guest. 
Boot and switch to another VT (do not login to KDE)

Does the 'ñ' work at VT (no X11): YES, all is OK.
But WHY?
Comment 6 Reartes Guillermo 2012-12-22 15:23:37 EST
With TRY#5 i selected KDE instead of MINIMAL. So it went through FIRSTBOOT.

With MINIMAL, the contents of /etc/vconsole.conf is:
KEYMAP="es"

But with KDE (RIGHT AFTER FIRSTBOOT), the contents of /etc/vconsole.conf is:
KEYMAP="es"

Now reboot the guest. Do not login to KDE yet.
But with KDE (RIGHT AFTER REBOOT), the contents of /etc/vconsole.conf is:
KEYMAP="es"

Now login to KDE and the contents of /etc/vconsole.conf is:
KEYMAP="es"

Now reboot and check the contents of /etc/vconsole.conf is:
KEYMAP="es"

Ok, /etc/vconsole.conf, is not guilty. I checked this due to:
https://bugzilla.redhat.com/show_bug.cgi?id=859867#c5

But the 'ñ' does work after the first reboot AFTER LOGIN TO KDE.
In MINIMAL installation this is not possible.
Comment 7 Adam Williamson 2012-12-31 19:21:02 EST
this just sounds like perhaps a console font is missing? Whatever is _displayed_, can you devise a test to determine if the character actually _behaves_ as ñ - a user or file name, perhaps?
Comment 8 Reartes Guillermo 2012-12-31 20:27:27 EST
In my F17 box:

# echo "ñññ" > enie.txt 

Then i installed from TC3 a minimal installation.
I copied with scp the file there and cat showed the same 'junk'. 
 
To verify it, then i performed the inverse operation. 

I typed the ñ to get the 'junk' characters and then redirected them to a file and scp it to my F17 box. And cat showed that the file contents are ñ. 

It looks like you are right and a console font might be missing.

Well, that is all for this year. 
See you in the next one.
Cheers.
Comment 9 Steve Tyler 2013-01-01 14:33:07 EST
IIUC, the kbd-misc package contains the console fonts. There are 246 font files in the package in both F17 and F18, so a missing font file doesn't seem to be the problem.

$ rpm -ql kbd-misc | grep font | wc -l
246

$ rpm -qi kbd-misc
...
Summary     : Data for kbd package
Description :
The kbd-misc package contains data for kbd package - console fonts,
keymaps etc. Please note that kbd-misc is not helpful without kbd.
Comment 10 Steve Tyler 2013-01-01 14:46:36 EST
A workaround appears to be to create /etc/sysconfig/i18n and reboot:

# cat /etc/sysconfig/i18n
SYSFONT="True"

NB: /etc/sysconfig/i18n is not created during an F18 install.
Comment 11 Steve Tyler 2013-01-01 14:51:26 EST
This is my test case:

# yum -y install python-babel

# python
...
>>> import babel
>>> print babel.Locale.parse('es_ES').display_name
español (España)
Comment 12 Reartes Guillermo 2013-01-01 18:26:32 EST
Created attachment 671151 [details]
screenshot after trying the workaround from comment #10

the workaround for comment #10 did not work for me.
i tried again on a new "minimal" system.
Comment 13 Steve Tyler 2013-01-01 19:10:05 EST
Created attachment 671184 [details]
screenshot showing incorrect characters after running "lsblk"

Thanks for your report. Your screenshot shows what I was seeing. After renaming /etc/sysconfig/i18n and rebooting, the correct characters were still displayed, so that file doesn't seem to be related to the problem ...

Here is another attempt: :-)

Do a clean, default, minimal install.

Reboot.

Repeatedly press the escape key while booting.

Login as root.

Run the "lsblk" command.

If the escape key is repeatedly pressed while booting, the expected characters are displayed.

If the escape key is not pressed during booting, the incorrect characters are displayed as in the attached screenshot.
Comment 14 Steve Tyler 2013-01-01 19:15:33 EST
Created attachment 671185 [details]
screenshot showing correct characters after running "lsblk"

This screenshot was captured after repeatedly pressing the escape key during booting.
Comment 15 Reartes Guillermo 2013-01-01 19:47:44 EST
Removing 'rhbg' and 'quiet' boot parameters does the trick, which is a bit more appropriate for unattended booting.
Comment 16 Reartes Guillermo 2013-01-01 19:48:21 EST
Correction: 

Removing 'rhgb' and 'quiet' boot parameters does the trick, which is a bit more appropriate for unattended booting.
Comment 17 Reartes Guillermo 2013-01-01 19:59:31 EST
Actually, it affects only tty1 (when booting with 'rhgb' and 'quiet')
Comment 18 Steve Tyler 2013-01-01 23:05:25 EST
Confirming:
1. With 'rhgb' and 'quiet':
   tty1 displays incorrect characters, and tty2-tty6 display correct characters.
2. Without 'rhgb' and 'quiet':
   tty1-tty6 display correct characters.

Tested with the "lsblk" command.

Also:
If the "unicode_start" command is run, correct characters are displayed.
If the "unicode_stop" command is run, incorrect characters are displayed.
Comment 19 Steve Tyler 2013-01-02 03:01:51 EST
Appending "LANG=en_US.UTF-8" to the kernel command line also results in correct characters being displayed in tty1.
Comment 20 Kamil Páral 2013-01-02 12:32:11 EST
*** Bug 891353 has been marked as a duplicate of this bug. ***
Comment 21 Kamil Páral 2013-01-02 12:36:26 EST
This is not an issue with just Spanish, plain English install also prints invalid characters in "findmnt" and similar commands ("rm nonexistent_file" is a good test as well). unicode_start really fixes that. Adjusting title.
Comment 22 Adam Williamson 2013-01-02 13:15:57 EST
Discussed at 2013-01-02 blocker review meeting: http://meetbot.fedoraproject.org/fedora-bugzappers/2013-01-02/f18final-blocker-review-8.2013-01-02-17.03.log.txt . Rejected as a blocker: there are about a dozen workarounds (run the command that fixes it, hit esc during boot, boot without 'rhgb', use another vt...) and the impact of the bug isn't really _terrible_, just annoying. Accepted as NTH, though, obviously it'd be nice to fix this for release. Does anyone know where the bug actually is? Are we guessing plymouth since it affects only vt1 and taking out 'rhgb' seems to fix it?
Comment 23 Bill Nottingham 2013-01-02 13:24:56 EST
It's probably an ordering issue with console unicode initialization, where the step is done in the wrong order with switching to graphics mode and/or initializing additional consoles.
Comment 24 Ray Strode [halfline] 2013-01-02 14:37:50 EST
hmm, So looking we have this in systemd's code:

src/vconsole/vconsole-setup.c:        if (loop_write(fd, "\033%G", 3, false) < 0)

and in plymouth-start.service we have:

plymouth-start.service:After=systemd-vconsole-setup.service

so it seems like the ordering should be correct.
Comment 25 Steve Tyler 2013-01-02 15:16:55 EST
This problem does not occur after a complete update, including everything from updates-testing.

An apparent difference is that "LANG=en_US.UTF-8" is now automatically appended to the kernel command line. That parameter is set in /boot/grub2/grub.cfg.

Which component would add it?
Comment 26 Kamil Páral 2013-01-03 03:48:35 EST
(In reply to comment #25)
> This problem does not occur after a complete update, including everything
> from updates-testing.

Please always test with "rm non-existing-file". While lsblk output may be fixed, I always see problems with the apostrophes, even in older and updated F18 systems.

> An apparent difference is that "LANG=en_US.UTF-8" is now automatically
> appended to the kernel command line.

LANG seems to fix just lsblk ouput, not rm output. unicode_start fixes both, regardless of LANG presence.
Comment 27 Lennart Poettering 2013-01-13 17:52:36 EST
Does invoking /usr/lib/systemd/systemd-vconsole-setup fix the issue?

Note that the kernel defaults to UTF8 anyway. Setting UTF8 from userspace is hence not necessary, really.
Comment 28 Kamil Páral 2013-01-14 11:20:59 EST
Lennart, running /usr/lib/systemd/systemd-vconsole-setup fixes the lsblk output, but doesn't fix the apostrophes in rm output.
Comment 29 Chris Lumens 2013-03-08 10:08:05 EST
So, is this actually an anaconda problem or does it need to get reassigned?
Comment 30 Andreas M. Kirchwitz 2013-03-08 20:18:59 EST
I've run into this annoying bug myself. It reminds of the bug with console blanking. It seems that both, "unicode_start" and "setterm", require a tty to output some special character sequences. Systemd makes it difficult during startup to send any text to the console.

Btw, this bug is not specific to the 64 bit version of Fedora 18 (same on 32 bit). And is it really Anaconda related? Even *after* the installation of Fedora 18, there's currently no proper fix (only two ugly workarounds, either remove "rhgb"+"quiet" or have each user run "unicode_start" in his/her login scripts - which is not as trivial as it sounds).

The bug in Anaconda is that it puts the wrong vconsole.keymap setting in the kernel line in /etc/sysconfig/grub (in my case it puts "de" there instead of "de-latin1-nodeadkeys" which I selected during installation). But that's a different story.
Comment 31 Adam Williamson 2013-03-08 21:21:12 EST
"But that's a different story." Specifically, it's more or less https://bugzilla.redhat.com/show_bug.cgi?id=889562 , but ultimately will be https://bugzilla.redhat.com/show_bug.cgi?id=837292 .
Comment 32 Andreas M. Kirchwitz 2013-03-09 07:56:59 EST
Afters dozens of reboots, it looks like I've found a configuration that works. But to be honest, I don't know why.

Fedora 18, fresh installation, graphical installation from USB stick, language for installation is English (US), keyboard layout is German without dead keys.

By default, the F18 installer automatically adds vconsole.keymap=de to the Linux kernel command line (but no LANG or any fonts), and it puts KEYMAP="de" to /etc/vconsole.conf (but nothing else). The only correct setting written by the F18 installer is LANG="en_US.UTF-8" in /etc/locale.conf

After a lot of changes (and reboots) my configuration now looks like this and magically works:

* Removed all vconsole.* settings from Linux kernel command line.

* No LANG settings in Linux kernel command line.

* Removed "rhgb" from Linux kernel command line but not (!) "quiet".

* Contents of /etc/vconsole.conf are:

   KEYMAP="de-latin1-nodeadkeys"
   FONT="latarcyrheb-sun16"

* Contents of /etc/locale.conf are (unchanged):

   LANG="en_US.UTF-8"

* No extra calls of "unicode_start" or "loadkeys".

That gives me proper german "umlaute" (those funny special characters) and "rm filenotexists" works as well. In all virtual consoles (1-6).

What I do *not* understand is that it does not work if I add "vconsole.keymap=de-latin1-nodeadkeys vconsole.font=latarcyrheb-sun16" to the Linux kernel command line. To my understanding that should be the same as my current /etc/vconsole.conf, but for some reason it isn't. (Why does the installer put it to the kernel line anyway?)

Unfortunately, there's a strange feeling that I maybe changed some more things during all my debugging (which I do not remember right now) and they might be important as well to fix the problem.

I've also found out, that console blanking works if I redirect the output of setterm (which I run in rc.local) to /dev/tty0 and add "-term linux" to its command line. So I no longer need to add consoleblank=0 to the kernel.

Maybe someone likes to try if it works for him/her too. I'm a little bit confused right now. :-)
Comment 33 Adam Williamson 2013-05-29 21:33:58 EDT
bcl: can we close this at this point? I'm a bit confused. But we're definitely past 19.25 in stable.
Comment 34 Vratislav Podzimek 2013-05-30 04:13:45 EDT
This should be fixed, at least from the anaconda's perspective.
Comment 35 Vojtěch Boček 2013-05-30 08:24:49 EDT
In Fedora 19 Beta 19 RC4, after clean minimal installation, VT still shows rectangles instead of ' character. Can be reproduced in "rm nonexistingfilename" and in "Fedora release 19 (Schrodinger's Cat)" welcome message. Output of "findmnt" is fine though.
Running "unicode_start" in console fixes it, "rm nonexistingfilename" shows ' properly and welcome message after typing "exit" is okay too.
Comment 36 Adam Williamson 2013-05-30 12:07:07 EDT
I did a minimal netinstall yesterday and got ', not a box.
Comment 37 Kamil Páral 2013-05-31 04:53:13 EDT
Our testing:

F18 host with QXL driver - apostrophe OK       (dvd install)
F18 host with cirrus driver - apostrophe FAIL  (dvd install)
F19 host with QXL driver - apostrophe FAIL     (dvd install)
F19 host with cirrus driver - apostrophe FAIL  (dvd install)
bare metal - apostrophe FAIL                   (netinst install, 2 different PCs)

Interesting, isn't it?
Comment 38 Vratislav Podzimek 2013-06-04 04:46:23 EDT
(In reply to Kamil Páral from comment #37)
> Our testing:
> 
> F18 host with QXL driver - apostrophe OK       (dvd install)
> F18 host with cirrus driver - apostrophe FAIL  (dvd install)
> F19 host with QXL driver - apostrophe FAIL     (dvd install)
> F19 host with cirrus driver - apostrophe FAIL  (dvd install)
> bare metal - apostrophe FAIL                   (netinst install, 2 different
> PCs)
> 
> Interesting, isn't it?
Interesting, indeed. But hardly an Anaconda issue.
Comment 39 Kamil Páral 2013-06-04 05:12:37 EDT
(In reply to Vratislav Podzimek from comment #38)
> Interesting, indeed. But hardly an Anaconda issue.

There was a suspicion that it can be caused by some configuration file incorrectly set by anaconda. But it can also by caused by many other components. It would be nice to have someone around who has some idea.

Btw, when booting Anaconda DVD, the apostrophe in "Welcome to Fedora 19 (Schrődinger's cat)" is also FAIL, a box. But after the installer is started, it displays OK on tty2.
Comment 40 Andreas M. Kirchwitz 2013-07-04 08:38:37 EDT
Installed official Fedora 19 (64 bit) Desktop DVD yesterday from scratch (GNOME desktop), but in the virtual consoles "cat /etc/fedora-release" fails to display the apostrophe correctly. Same problem with "rm filedoesnotexist".

LANG="en_US.UTF-8", keyboard "us". My fix for Fedora 18 (remove all vconsole.* settings and "rhgb" from kernel boot line) no longer works for Fedora 19.

If I login to a virtual console und run "unicode_start", it fixes the problem for (only!) this console until next reboot.

Have not found a way yet to fix this problem globally for the system, so that user don't need to modify their login process.

Does anyone has a system-wide workaround?
Comment 41 Fedora End Of Life 2013-12-21 10:43:16 EST
This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '18'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be 
able to fix it before Fedora 18 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior to Fedora 18's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 42 Vratislav Podzimek 2014-01-07 08:39:45 EST
Is this still an issue on F19? If yes, please provide additional information and reassing this bug to systemd (there is nothing more anaconda could do).
Comment 43 Andreas M. Kirchwitz 2014-01-07 09:20:29 EST
This bug still exists in Fedora 19 *AND* Fedora 20. Never been fixed.
As workaround for the default six consoles, put this in /etc/rc.d/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

No extra "loadkeys" or "unicode_start". See also bug #970030
Comment 44 Kamil Páral 2014-01-07 09:26:23 EST
I performed a minimal F20 DVD install on F20 host (QXL driver), and lsblk output and rm nonexistingfile displays correctly (well, the opening apostrophe is white instead of gray on my screen, but it is rendered correctly).
Comment 45 Nicola Soranzo 2014-01-07 11:21:41 EST
(In reply to Vratislav Podzimek from comment #42)
> Is this still an issue on F19? If yes, please provide additional information
> and reassing this bug to systemd (there is nothing more anaconda could do).

Yes, it is on my Fedora 19, which is not a fresh install, but has been continuously updated since 2009.
Wrong characters appear in the virtual console with:
- findmnt
- lsblk
- cat /etc/fedora-release
No problem with "rm filedoesnotexist".
unicode_start fixes the 3 problems.
Comment 46 Adam Williamson 2014-01-07 11:39:40 EST
tests with 'rolling' systems aren't valid if the bug is in anaconda, because anaconda has never had another shot at configuring things.
Comment 47 Andreas M. Kirchwitz 2014-01-08 13:10:48 EST
Don't know what I did differently compared to Kamil (comment #44). I freshly installed three machines (2 notebooks, 1 desktop PC) with Fedora 20 64-bit DVD. Installation language "English (United States)", keyboard "us" (default) on one notebook, keyboard "de (eliminate dead keys)" on other notebook and desktop PC. Default "GNOME Desktop" installation.

My LANG setting is the default (en_US.UTF-8).

On all virtual terminals, "rm filenotexists" displays the opening and closing apostrophe as grey box (on all three machines). Tested with the default root account (no custom configuration) right after the fresh installation. The new distribution name ("Heisenbug") no longer contains special characters, so I didn't change the login banner just to check for Umlauts etc. I guess it still wouldn't work.

In F19 + F20, "setfont -C /dev/tty1 latarcyrheb-sun16" in rc.local is a workaround to this bug for virtual terminal #1 (and tty2 for VT #2 etc.)

Please note that I do not run "unicode_start" (or setfont etc.) in my .tcshrc (or .bashrc etc.) Some people do that (maybe because of the same bug in F18+F19), and of course, that is also a workaround.

If you like me to run specific tests (only F20, don't have F19 any longer), just let me know. I'm happy to help.
Comment 48 Felix Miata 2014-02-27 06:22:10 EST
unicode_start fails to run in Mageia 4 and openSUSE 13.1 too, most noticeable when I start mc on vtty2 and get characters other than line/box characters where line/box characters belong, which means virtually every boot. openSUSE 13.1 bug https://bugzilla.novell.com/show_bug.cgi?id=859710 seems to be this bug, which happens here in both F20 and Rawhide. I have Plymouth installed in neither F20 nor Rawhide nor 13.1; splash=verbose, absent rhgb, absent quiet, absent lang=, absent FONT= on cmdlines.
Comment 49 Zbigniew Jędrzejewski-Szmek 2014-07-22 22:38:42 EDT
I sincerely hope this has been improved in F21. I'll close this bug because untangling F19 issues doesn't make much sense anymore. Please post new bugs if necessary against newer versions.

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