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.
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... :-(
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.
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).
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.
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?
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.
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?
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.
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.
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.
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)
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.
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.
Created attachment 671185 [details] screenshot showing correct characters after running "lsblk" This screenshot was captured after repeatedly pressing the escape key during booting.
Removing 'rhbg' and 'quiet' boot parameters does the trick, which is a bit more appropriate for unattended booting.
Correction: Removing 'rhgb' and 'quiet' boot parameters does the trick, which is a bit more appropriate for unattended booting.
Actually, it affects only tty1 (when booting with 'rhgb' and 'quiet')
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.
Appending "LANG=en_US.UTF-8" to the kernel command line also results in correct characters being displayed in tty1.
*** Bug 891353 has been marked as a duplicate of this bug. ***
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.
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?
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.
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.
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?
(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.
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.
Lennart, running /usr/lib/systemd/systemd-vconsole-setup fixes the lsblk output, but doesn't fix the apostrophes in rm output.
So, is this actually an anaconda problem or does it need to get reassigned?
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.
"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 .
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. :-)
bcl: can we close this at this point? I'm a bit confused. But we're definitely past 19.25 in stable.
This should be fixed, at least from the anaconda's perspective.
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.
I did a minimal netinstall yesterday and got ', not a box.
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?
(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.
(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.
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?
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.
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).
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
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).
(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.
tests with 'rolling' systems aren't valid if the bug is in anaconda, because anaconda has never had another shot at configuring things.
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.
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.
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.
BTW, potentially relevant commits: http://cgit.freedesktop.org/systemd/systemd/commit/?id=abee28c56d http://cgit.freedesktop.org/systemd/systemd/commit/?id=ff452e76e2