kbd service is replaced by vconsole service which should do the same action as kbd.

I've tested your console file (btw, next time, attach it directly to the bug report, rather than using pastebin) and yandex.ru is displayed correctly.

What is the output of 
systemctl status systemd-vconsole-setup.service 

?

Here is the output:
systemctl status systemd-vconsole-setup.service
systemd-vconsole-setup.service - Setup Virtual Console
	  Loaded: loaded (/lib/systemd/system/systemd-vconsole-setup.service; static)
	 Process: 428 ExecStart=/lib/systemd/systemd-vconsole-setup (code=exited, status=0/SUCCESS)
	  CGroup: name=systemd:/system/systemd-vconsole-setup.service

so, it seems it worked fine.

Could you try running :
systemctl restart systemd-vconsole-setup.service and check if w3m www.yandex.ru renders correctly ?

After restarting font displayed correctly.

Is there any way to fix the need for manual restart of vconsole-setup service after each system restart?

it should work fine after startup. Restarting it manually won't fix the real problem, it will just hide the issue.

Could you boot with "systemd.log_level=debug systemd.log_target=kmsg" on your boot command line and attach dmesg output to this bug report ?

Created attachment 473326 [details]
dmesg log

hmm, from the log, it looks like you have another issue with network causing a timeout, try updating sysconfig package from http://download.opensuse.org/repositories/home:/mtomaschewski:/branches:/openSUSE:/12.1:/Update:/Test/openSUSE_12.1/ (update is pending)

Please attach dmesg output with "systemd.log_level=debug systemd.log_target=kmsg" when this update is applied.

Created attachment 473791 [details]
dmesg log 2

I 've updated sysconfig package. Still no luck with fonts. Attached new log.
BTW where I should look for issue with network?

from the trace, the network "issue" I was seeing (failed state) is fixed with sysconfig update.

when you login, which vt are you using ? do you have the font issue on vt1 and vt2 ?

do you have a file /etc/vconsole.conf ?

Usually I login to vt2. 

Font issue is present on every vt (vt1-vt6). Also worth mentioning, that systemctl restart systemd-vconsole-setup.service only fixes vt it was launched from. E.g. if after restart I will login to vt3 and launch systemctl restart systemd-vconsole-setup.service, then fonts on vt3 are fixed, but all other vts still have an issue. 

/etc/vconsole.conf: No such file or directory

Is this the network issue, you saw in the first log?
[   33.856719] systemd[1]: Received SIGCHLD from PID 2850 (ifup-route).
[   33.856745] systemd[1]: Got SIGCHLD for process 2850 (ifup-route)
[   33.856798] systemd[1]: Child 2850 died (code=exited, status=1/FAILURE)

forget about the network issue, I think I mixed two different bugs, sorry.

could you try the following (as root):
cp /lib/systemd/system/systemd-vconsole-setup.service /etc/systemd/system

and append the following lines in the [Unit] section of /etc/systemd/system/systemd-vconsole-setup.service :
BindTo=dev-tty1.device
After=dev-tty1.device

and reboot to see if it works better.

Still the same.

could you attach dmesg output after the change ?

I'd be also interested boot.svg file obtained by :
systemd-analyze plot > boot.svg

Created attachment 474978 [details]
dmesg log 3

Created attachment 474979 [details]
boot.svg

dmesg log is unusable, you didn't boot with systemd.log_level=debug systemd.log_target=kmsg (you might want to put them in /boot/grub/menu.lst)

however, could you try with the following content in /etc/systemd/system/systemd-vconsole-setup.service (and I'll need dmesg output after rebooting with this change, if it doesn't work):
[Unit]
Description=Setup Virtual Console
DefaultDependencies=no
Conflicts=shutdown.target
After=dev-tty0.device systemd-readahead-collect.service systemd-readahead-replay.service
Before=sysinit.target shutdown.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/lib/systemd/systemd-vconsole-setup
StandardOutput=syslog

Created attachment 475265 [details]
dmesg log 4 instead dmesg log 3

Rebooting several times to prepare the right kind of log I've discovered that this issue is not "hard-coded", but rather some kind of race-condition. E.g. after another reboot I've switched to tty and discovered, that fonts are ok without any further intervention. Confused about sounding a "false" alarm I've rebooted again and again fonts were ok right after boot. But after one more try issue was back, and it's still here. I haven't applied changes, you proposed in Comment 17 yet. Should I apply them or prepare dmesg log of successful boot with working fonts?

if you can get a dmesg and svg file from a working setup, please do, but don't too much time trying to reproduce.

And test the change from comment 17, it might fix the issue (but I'm not 100% sure of that).

Created attachment 475742 [details]
dmesg log from a working setup

Created attachment 475743 [details]
svg file from a working setup

Now I will try proposed changes.

Change from comment 17, doesn't fix the issue. While I've had fonts working right after boot a few times, but it's still more like a matter of luck. Following is the dmesg.log and boot.svg from setup with changes applied, but still not working.

Created attachment 475817 [details]
dmesg log 6

Created attachment 475818 [details]
boot svg 3

let's try something else.

Replace /etc/systemd/system/systemd-vconsole-setup.service with the following content (replace the <KEYMAP> value with the path of the file corresponding to KEYTABLE from /etc/sysconfig/keyboard, in /usr/share/kbd/keymaps, otherwise, you'll be using qwerty keyboard ;)
[Unit]
Description=Setup Virtual Console
DefaultDependencies=no
Conflicts=shutdown.target
After=systemd-readahead-collect.service
systemd-readahead-replay.service
Before=sysinit.target shutdown.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/setfont -C /dev/tty1 UniCyrExt_8x16.psf.gz -m trivial
ExecStart=/bin/setfont -C /dev/tty2 UniCyrExt_8x16.psf.gz -m trivial
ExecStart=/bin/setfont -C /dev/tty3 UniCyrExt_8x16.psf.gz -m trivial
ExecStart=/bin/setfont -C /dev/tty4 UniCyrExt_8x16.psf.gz -m trivial
ExecStart=/bin/setfont -C /dev/tty5 UniCyrExt_8x16.psf.gz -m trivial
ExecStart=/bin/setfont -C /dev/tty6 UniCyrExt_8x16.psf.gz -m trivial
ExecStart=/bin/loadkeys -C '/dev/tty1 /dev/tty2 /dev/tty3 /dev/tty4 /dev/tty5 /dev/tty6' <KEYMAP>
StandardOutput=syslog

(In reply to comment #26)
> let's try something else.
> 
While keyboard is working fine with new systemd-vconsole-setup.service, the fonts are still rendered incorrect. Nevertheless after manual launch of "sudo /bin/setfont -C /dev/tty2 UniCyrExt_8x16.psf.gz -m trivial" they gets fixed. With all those truubles systemd looks like some voodoo magic, compared to sysvinit.

this service is probably getting started too early (or something else is conflicting), it is just hard to debug (sysvinit is starting kbd way more later in the boot process).

Could you check /var/log/messages for error message from setfont ? and attach systemctl status systemd-vconsole-setup.service output when it fails ?

Tere is no any trace of setfont in /var/log/messages.

systemctl status systemd-vconsole-setup.service:

          Loaded: loaded (/etc/systemd/system/systemd-vconsole-setup.service; static)
          Active: active (exited) since Thu, 16 Feb 2012 12:41:05 +0200; 1h 16min ago
         Process: 616 ExecStart=/bin/loadkeys -C /dev/tty1 /dev/tty2 /dev/tty3 /dev/tty4 /dev/tty5 /dev/tty6 /usr/share/kbd/keymaps/i386/qwerty/ua-utf.map.gz (code=exited, status=0/SUCCESS)
         Process: 613 ExecStart=/bin/setfont -C /dev/tty6 UniCyrExt_8x16.psf.gz -m trivial (code=exited, status=0/SUCCESS)
         Process: 609 ExecStart=/bin/setfont -C /dev/tty5 UniCyrExt_8x16.psf.gz -m trivial (code=exited, status=0/SUCCESS)
         Process: 607 ExecStart=/bin/setfont -C /dev/tty4 UniCyrExt_8x16.psf.gz -m trivial (code=exited, status=0/SUCCESS)
         Process: 604 ExecStart=/bin/setfont -C /dev/tty3 UniCyrExt_8x16.psf.gz -m trivial (code=exited, status=0/SUCCESS)
         Process: 601 ExecStart=/bin/setfont -C /dev/tty2 UniCyrExt_8x16.psf.gz -m trivial (code=exited, status=0/SUCCESS)
         Process: 449 ExecStart=/bin/setfont -C /dev/tty1 UniCyrExt_8x16.psf.gz -m trivial (code=exited, status=0/SUCCESS)
          CGroup: name=systemd:/system/systemd-vconsole-setup.service

hmm, frankly, I'm out of idea.

Stanislav, do you have an idea ?

Stanislav, could you answer, please?

It could be a unicode_start issue, as we see in the bug 750326. Maybe it is called too late, or it fails sometimes.

A simple work-around could be:
rm /lib/systemd/system/kbd.service

It will force starting of the old init script.

There is yet another systemd+kbd regression: bug 746595.

my point is not to workaround the issue but fix it properly.

As far as I see it, it is a font loading issue.

Unicode_start is not called by systemd, the equivalent change are done by systemd itself ( ioctl(fd, KDSKBMODE, K_UNICODE); )

Yes, in that case, we need to implement all missing features.

Unicode is started from:
systemd/src/util.c: reset_terminal_fd()
Called from: console_setup(), reset_terminal(), acquire_terminal()

Our important call is probably:
src/vconsole/vconsole-setup.c: main()
This code has a lot of SUSE specific sections.

We have to find, where the race happens. Are virtual terminals not yet fully initialized? We have had virtual console race issue in past in bug 575123, which was only worked around.

I'm not sure it is an issue in vconsole-setup : the latest test .service I asked Dino to test was doing the exact same command vconsole-setup is doing and fonts were not properly loaded.

So, either the service is called too early or something is changing the font after it is started..

(In reply to comment #32)

> A simple work-around could be:
> rm /lib/systemd/system/kbd.service
> 
> It will force starting of the old init script.

I've just tried and it indeed works.

I tried to reproduce but failed. The system boots with correct font and even initial login text in Cyrillic is OK.

Looking at the svg, I see a difference between comment 21 and comment 25: In one case sys-devices-virtual-tty-tty*.device scripts are called later than systemd-vconsole-setup.service and once in the same time.

Ad comment 34 and comment 35: Yes, vconsole-setup main() calls only open_terminal() and optionally unsets UTF-8 mode, if the locale is not UTF-8.

Is it possible that reset_terminal_fd() is sometimes called after setfont?

reset_terminal_fd is called :
- one time at systemd startup
- after a tty is released (to be acquired by systemd for monitoring)
- before and after spawning an executable

Is this bug still valid for openSUSE 12.3 or 13.1 ?

(In reply to comment #39)
> Is this bug still valid for openSUSE 12.3 or 13.1 ?

I can confirm it for 12.3.

Is there anyone who is able to reproduce this with 13.1 or factory?

Beside this: if I'm reading correct the result is correct after a restart of the systemd-vconsole-setup.service unit.  This let me assume that this could be plymouth or any other service which holds the setup of the  virtual consoles locked and fools vconsole-setup.

But I do not know if plymouth was already in 12.1.

Nonetheless something is locking or ``restoring'' the virtual console(s) during the initial start of vconsole-setup.service.

Hmmm ... looks very similar https://bugzilla.redhat.com/show_bug.cgi?id=700971

From the link shown im my last comment #42

|--- Additional comment from  notting@redhat.com on 2011-04-28 18:38:23 CEST ---
|
|(In reply to comment #8)
|> Hmm, Ray, have you heard of such a problem with font loading and Plymouth
|> colliding?
|
|vconsole setup needs done before plymouth sets the terminal to graphics 
|mode/the framebuffer driver is loaded, IIRC.
|
|(font/unicode state is per-VT, but inherited from the prior existing console)
|
|--- Additional comment from  lpoetter@redhat.com on 2011-04-30 03:45:44 CEST ---
|
|OK, will duplicate against dracut then, which apparently dropped the font 
|loading.
|
|Harald, please add an invocation of systemd-vconsole-setup to dracut, before 
|you run plymouth, as discussed on IRC the other day.

IMHO we should do the same in mkinitrd as well as in dracut.

(In reply to comment #41)
> Is there anyone who is able to reproduce this with 13.1 or factory?

No, I haven't (nor with 12.3 ) :(

OK ... let me ask a stupid question as it seems to be a race condition.

What does happen if the line

  After=sys-devices-virtual-tty-tty0.device

has been added in the [Unit] section of systemd-vconsole-setup.service.
Does the race also occur?

Are there any news that is: does the line help or does the race happen again?

Ping! Any news?

(In reply to comment #45)
> OK ... let me ask a stupid question as it seems to be a race condition.
> 
> What does happen if the line
> 
>   After=sys-devices-virtual-tty-tty0.device
> 
> has been added in the [Unit] section of systemd-vconsole-setup.service.
> Does the race also occur?

Sorry for the delay. Just tried this. The race still occur.

(In reply to comment #45)
> OK ... let me ask a stupid question as it seems to be a race condition.
> 
> What does happen if the line
> 
>   After=sys-devices-virtual-tty-tty0.device
> 
> has been added in the [Unit] section of systemd-vconsole-setup.service.
> Does the race also occur?

My previous reports was based on working installation of openSUSE 12.3. Because there was a comment that this bug isn't reproducing on other system, and to make sure that its indeed the bug, I've just created a fresh VM in VirtualBox 4.2.6_OSE and installed openSUSE 12.3 from openSUSE-12.3-DVD-i586.iso. All defaults, KDE. The only configs I've edited is /etc/sysconfig/console and /etc/sysconfig/keyboard. Bug is here. No cyrillic fonts after reboot, "systemctl restart systemd-vconsole-setup.service" fixes them. Fixes proposed for systemd-vconsole-setup.service are not working. And as on the real working system, on the VM this race occurs 99% if not 100% of the time.
Later I will create a VM with 13.1 and give it a try.

I not reproduce this bug. See https://bugzilla.novell.com/show_bug.cgi?id=780516#c35

(In reply to Andrey Karepin from comment #54)
> I not reproduce this bug. See
> https://bugzilla.novell.com/show_bug.cgi?id=780516#c35

Thanks for the feedback, closing as fixed in current openSUSE Version.
If you still see the problem in 13.1, please reopen the bug and update the Product information to 13.1

(In reply to Thomas Blume from comment #55)
> (In reply to Andrey Karepin from comment #54)
> > I not reproduce this bug. See
> > https://bugzilla.novell.com/show_bug.cgi?id=780516#c35
> 
> Thanks for the feedback, closing as fixed in current openSUSE Version.
> If you still see the problem in 13.1, please reopen the bug and update the
> Product information to 13.1

Sorry, but noting has changed from 12.3 through 13.1 to 13.2. And while there are couple of workarounds available, the bug itself is still here "out of the box". I've just installed fresh copy of openSUSE 13.2 on real hardware and can confirm. Tested and used workaround was packaged by some Fedora people and available as both rpm/srpm:
http://www.mediafire.com/download/i9vwh12t2w9is26/cyrconfix-1.0-13.2.noarch.rpm
http://www.mediafire.com/download/9396p0vp3ezcck2/cyrconfix-1.0-0.1.src.rpm

and as manual fix:

# /usr/lib/systemd/system/setup-cyrfont@.service  

[Unit]  
Description=Cyrillic workaround on %I  
After=systemd-user-sessions.service plymouth-quit-wait.service  
After=getty@%i.service  

BindsTo=getty@%i.service  
Requires=getty@%i.service  
IgnoreOnIsolate=yes  

[Service]  
Environment="FONT=UniCyr_8x16"  
EnvironmentFile=-/etc/vconsole.conf  
ExecStart=/usr/bin/setfont -C /dev/%i $FONT  
Type=oneshot  

[Install]  
RequiredBy=getty@.service


# /etc/vconsole.conf

KEYMAP=ruwin_alt-UTF-8  
FONT=UniCyr_8x16

~>systemctl daemon-reload && systemctl enable setup-cyrfont@.service && systemctl start setup-cyrfont@.service

Another posibility is to add "unicode_start" to ".bashrc"

(In reply to Dino E from comment #56)
> 
> Sorry, but noting has changed from 12.3 through 13.1 to 13.2. And while
> there are couple of workarounds available, the bug itself is still here "out
> of the box". I've just installed fresh copy of openSUSE 13.2 on real
> hardware and can confirm. 

Can you please try wheter the dracut package from:

http://download.opensuse.org/repositories/home:/tsaupe:/branches:/Base:/System:/bsc744108-dracut/openSUSE_13.2/

solves the issue without using workarounds?

(In reply to Thomas Blume from comment #57)

> Can you please try wheter the dracut package from:
> 
> http://download.opensuse.org/repositories/home:/tsaupe:/branches:/Base:/
> System:/bsc744108-dracut/openSUSE_13.2/
> 
> solves the issue without using workarounds?

Yes. Installing dracut from this repo resolves the issue. 

While preparing multiple test VMs, I've gathered some additional info. The bug seems to be dependent on language and components selected during openSUSE installation. If we select Russian in the installer and some graphical DE, then there's no this bug in the installed system. If we select English in the installer and some graphical DE, and after installation change primary language to Russian in YAST or manually in /etc/sysconfig/language and /etc/sysconfig/console, than this bug appears. Also installing "Minimal Server Selection (Text Mode)" pattern seems to be not dependent on language, selected in the installer and results in a system, free from this bug.

(In reply to Dino E from comment #58)
> (In reply to Thomas Blume from comment #57)
> 
> > Can you please try wheter the dracut package from:
> > 
> > http://download.opensuse.org/repositories/home:/tsaupe:/branches:/Base:/
> > System:/bsc744108-dracut/openSUSE_13.2/
> > 
> > solves the issue without using workarounds?
> 
> Yes. Installing dracut from this repo resolves the issue. 
> 
> While preparing multiple test VMs, I've gathered some additional info. The
> bug seems to be dependent on language and components selected during
> openSUSE installation. If we select Russian in the installer and some
> graphical DE, then there's no this bug in the installed system. If we select
> English in the installer and some graphical DE, and after installation
> change primary language to Russian in YAST or manually in
> /etc/sysconfig/language and /etc/sysconfig/console, than this bug appears.
> Also installing "Minimal Server Selection (Text Mode)" pattern seems to be
> not dependent on language, selected in the installer and results in a
> system, free from this bug.

What you have seen is most probably another effect of the vconsole setup bug (see bug 927250 ).
The testpackages included the fixes from this bug and also solved your issue.

Adding this one as duplicate.

*** This bug has been marked as a duplicate of bug 927250 ***