# rpm -qf /etc/udev/rules.d/10-console.rules
initscripts-8.76.2-1.x86_64

When did this start? If you run /lib/udev/console_init tty0, does it fix it?

(In reply to comment #2)
> When did this start?

Around when plymouth started showing up in rawhide, iow some time ago.

> If you run /lib/udev/console_init tty0, does it fix it?

No

p.s.

With the latest rawhide, my console colors are fscked up too know, the plymouth ascii busy animation colors stay in effect after the system has booted, for example the [ OK ] for starting a service has the OK in plymouth light blue now.

And /lib/udev/console_init tty0 doesn't fix this either.

This might be related - I'm running Fedora 10 Beta with russian locale, and russian characters show up as garbage.

Running /sbin/setsysfont does fix this, /lib/udev/console_init tty0 (or tty1) does not.

Created attachment 319458 [details]
patch to fix setfont call from console_init

Ok, I've found the problem - if UNIMAP is not set, console_init defaults to calling setfont with '-u none' which overrides the unicode map provided in the font itself. Attached patch fixes this.

Thanks! Will be in 8.84-1.

http://git.fedorahosted.org/git/?p=initscripts.git;a=commitdiff;h=7f102d17b56f7697c963462eb422df2077ce919c

*** Bug 450690 has been marked as a duplicate of this bug. ***

*** Bug 466611 has been marked as a duplicate of this bug. ***

This should be then "backported" also to F9 right?

It's been backported to the F-9 git branch, there will probably be an update at some point.

initscripts-8.76.4-1 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/initscripts-8.76.4-1

This didn't quite fix it for me (Serbian Cyrillic sr_RS.utf8 system locale).

If i switch from plymouth using Esc straigh away, the "Starting" in "Starting udev" appears garbled, and the other strings show up fine.

If I switch later (i.e. halfway) in the boot process, all the messages still appear garbled.

Neither for me. F10 console and starting/stopping messages are not showing correct characters. I'll attach screenshot to demonstrate this.

Created attachment 320768 [details]
fedora console unicode

See steps - after login, after setfont, after unicode_start and their influence on characters. The correct ouput is after unicode_start.

I'm using russian cyrillic ru_RU.UTF8 locale, and things are fine here with initscripts 8.84 - cyrillic characters in console and during boot show up fine, regardless of when I press Esc. Midnight Commander also looks fine. The only exception is "Starting udev" message, I could live with that. However, I'm a special case - Nvidia on a powerpc machine, so plymouth is using non-graphical mode.

Adam, could you attach your /etc/sysconfig/i18n and cestina.txt files? I could try to reproduce the problem then.

Milos, can I have your i18n file as well?

Alex, I have tried with the nomodeset kernel boot option and they show up fine then, just like for you.

$ cat /etc/sysconfig/i18n
LANG="sr_RS.utf8"
SYSFONT="latarcyrheb-sun16"

Btw, do your cyrillic characters appear highlighted during init? Pretty sure this wasn't case in F7 or before...

Yes, if plymouth is in use, then everything ends up highlighted in console. I think this should be filed as a plymouth bug though. I can't comment on the graphical plymouth -> garbage from non-latin characters, as I can't reproduce it.

Created attachment 321122 [details]
screenshot from virtualbox showing highlighted chars

LANG="cs_CZ.UTF-8"
SYSFONT="latarcyrheb-sun16"

Attached: Highlighted characters I had in F9 already - not related to plymouth, also this happens at all consoles.

The file cestina.txt is attached to my bug marked as duplicate:
https://bugzilla.redhat.com/attachment.cgi?id=309052

Yep, highlighted non-ascii chars in init appeared around F7 or F8 IIRC, nothing to do with plymouth.

Adam, I just tried booting with your i18n, and in both text plymouth and no plymouth modes the file is displayed fine. So I think the problem is specifically with graphical plymouth, and I can't reproduce that - nvidia card here. The highlighted characters issue doesn't occur either - might be because of different framebuffer drivers.

Bill, console_init (and unicode_start) do some magic to set up UTF-8 consoles:
http://git.fedorahosted.org/git/?p=initscripts.git;a=blob;f=src/console_init.c;h=a3d9379160e382606268b7c67bf05d667e7b53e2;hb=251c0bfcfdb53f2c11fcafa9381d4322a1973fc8#l120

Seems like it's not working if graphical plymouth is running. Should it be moved to initrd, just before plymouth is started?

CC'ing Ray - what exactly does plymouth do with the tty when it starts?

I have only nvidia, intel and virtualbox - all of them use text based plymouth and all of them show this behaviour. Then I would really like to know where is the difference. How did you done the installation of the system? I did it in english, then I added czech support.

Are we discussing the garbage characters, unwanted character highlighting or both now? Comment 16 seems to confirm that the first is a graphical plymouth issue.

I did the installation in russian. No idea how that could make a difference though.

I experience both problems at once. 

I found however one interesting thing - booting into init 3 (without plymouth and with nomodeset), I have only highlighted characters, but letters are OK. Booting into init 5 and switching to console letters are changed to garbage.

This is something I already noticed earlier - swichting to X and back to tty causes the settings of tty to be reset.

initscripts-8.76.4-1 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.

Alex/Adam/Milos - please open a separate bug for interactions with plymouth. I'm trying to reproduce here and not having a lot of luck.

Just as an example, using cs_CZ.UTF-8:

- I can't reproduce highlighted characters
- I can't reproduce the messages being in the wrong encoding/characters when switched to details mode after udev starts.

I have cs_CZ.UTF-8 myself -- in later upgrades of Rawhide this problem has been fixed. Please, anybody who is affected by this issue, please, upgrade and reopen if it has not been fixed yet.

I'm still seeing this with sr_RS.UTF-8 (and sr_RS.utf8) if I press Esc more than about 2/3 in during Plymouth startup. Running latest rawhide.

Milos - which 'this' - characters in wrong encoding, or highlighted characters?

I guess encoding, because I just get squares instead of non-ASCII letters in plymouth if I switch to details late. This remains the case in virtual consoles then.

With nomodeset I do get correct Curillic letters even if I switch to details late, but non-ASCII is highlighted.

Is your /etc/sysconfig/i18n *just* LANG=sr_RS.UTF-8, or do you have additional font-related customizations I should be testing with?

My /etc/sysconfig/i18n is

LANG="sr_RS.UTF-8"
SYSFONT="latarcyrheb-sun16"

as created by the F10 Live beta installer, with the system updated to latest rawhide. Are you saying that SYSFONT shouldn't be there?

No, just making sure you don't have SYSFONTACM or UNIMAP set (which, if you're using UTF-8, you shouldn't, but just making sure...)

Milos: if you apply http://notting.fedorapeople.org/0001-Do-full-console-initialization-in-the-initrd-not-ju.patch and rebuild your initrd, does it fix the character set issues? 

(Note: this patch may not go in as is, as it's a rather large and somewhat gross hammer.)

Bill, thanks for the patch, it applied ok.

Unfortunately, no difference here with the newly generated initrd - still get mostly ok output (minus the "Starting udev") if I switch to details at the start of plymouth, or the squares if I switch late.

This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  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 '10'.

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 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 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 please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

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.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Still getting the same behavior on F12 - boxes if I switch to booting details after udev, mostly ok ("Starting udev" exception) if I switch before udev starting.

What sort of hard

Meant to say 'what sort of hardware?' (video-wise)

This is on a ThinkPad T60p (2613-H5U) with

01:00.0 VGA compatible controller: ATI Technologies Inc M56GL [Mobility FireGL V5200]

One difference with F12 I just noticed is that virtual consoles are ok once the system is up, so the problem is only present during init...

For highlighted characters, please have a look at bug 486042, a similar issue with Polish locale is described there.

This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  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 '12'.

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 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 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 please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

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.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

This is no longer happening in F-14, closing.