What else was upgraded around or before the 3.15.x kernels?  Your yum history should show this information.

Also, does your initramfs contain a copy of /etc/vconsole.conf?  You can figure this out by using lsinitrd /boot/initramfs-<version>.img | grep vconsole

This is more likely a bug in systemd or dracut than the kernel itself.

Hi Josh.

I'm curently running the latests dracut & systemd versions, ie
dracut-037-11.git20140402.fc20.x86_64
&
systemd-208-19.fc20.x86_64


Not sure how to interpret the output of your recommended command line:

sudo lsinitrd /boot/initramfs-3.15.4-200.fc20.x86_64.img | grep vconsole
-rw-r--r--   1 root     root           39 Dec 14  2013 etc/vconsole.conf
lrwxrwxrwx   1 root     root           33 Jul 15 17:49 usr/lib/systemd/system/dracut-emergency.service.wants/systemd-vconsole-setup.service -> ../systemd-vconsole-setup.service
-rwxr-xr-x   1 root     root        45048 Jul 15 17:49 usr/lib/systemd/systemd-vconsole-setup
lrwxrwxrwx   1 root     root           33 Jul 15 17:49 usr/lib/systemd/system/emergency.target.wants/systemd-vconsole-setup.service -> ../systemd-vconsole-setup.service
lrwxrwxrwx   1 root     root           33 Jul 15 17:49 usr/lib/systemd/system/rescue.service.wants/systemd-vconsole-setup.service -> ../systemd-vconsole-setup.service
lrwxrwxrwx   1 root     root           33 Jul 15 17:49 usr/lib/systemd/system/systemd-ask-password-console.service.wants/systemd-vconsole-setup.service -> ../systemd-vconsole-setup.service
lrwxrwxrwx   1 root     root           33 Jul 15 17:49 usr/lib/systemd/system/systemd-ask-password-plymouth.service.wants/systemd-vconsole-setup.service -> ../systemd-vconsole-setup.service
-rw-r--r--   1 root     root          690 Jun 21 17:29 usr/lib/systemd/system/systemd-vconsole-setup.service

KEYMAP argument is handled correctly though (ie. KEYMAP="fr-oss")
Currently in testing systemd-208-20.fc20 mentions virtual console font fixes among other bug fixes.
Curiously enough, 3.15.x kernels running on my Mac VirtualBox are not affected.
Please advise whether I should close this report or change the component to systemd Josh.

sudo lsinitrd /boot/initramfs-3.15.6-200.fc20.x86_64.img | grep Lat2
-rw-r--r--   1 root     root         2022 Nov 27  2013 usr/lib/kbd/consolefonts/Lat2-Terminus16.psfu.gz

What is the output of:

# lsinitrd -f /etc/vconsole.conf /boot/initramfs-<version>.img 
# cat /proc/cmdline

sudo lsinitrd -f /etc/vconsole.conf /boot/initramfs-3.15.8-200.fc20.x86_64.img 
KEYMAP="fr-oss"
FONT="Lat2-Terminus16"

sudo cat /proc/cmdline 
BOOT_IMAGE=/vmlinuz-3.15.8-200.fc20.x86_64 root=/dev/mapper/fedora_bmasse-root ro rd.lvm.lv=fedora_bmasse/root rd.luks.uuid=luks-3da5eea2-3176-44cc-a834-177834a0a88d vconsole.font=Lat2-Terminus16 rd.lvm.lv=fedora_bmasse/swap rhgb quiet LANG=fr_FR.utf8

So, we have  usr/lib/kbd/consolefonts/Lat2-Terminus16.psfu.gz in the initramfs and kernel command line and vconsole.conf setup correctly.

So, as soon as you are asked a password with plymouth or on the console, systemd-vconsole-setup.service should be started ( comment 2 ) and set the font in the initramfs.

But if not, it is not dracut's fault.

See comment 1 :
3. Press TAB or any arrow during boot or switch to another tty

I guess this is in the real system and not in the initramfs.

Reassigning to systemd.

Created attachment 932917 [details]
journalctl --this-boot export

After booting without the 'quiet' argument, font actually does switch to font specified in vconsole.conf but falls back to Latarcyheb when around encountering [drm:cpt_serr_int_handler] *ERROR* PCH transcoder A FIFO underrun
and prior to entering LUKS passphrase

Filled BZ https://bugzilla.redhat.com/show_bug.cgi?id=1131914 
Kernel > 3.15.3 [drm:cpt_serr_int_handler] *ERROR* PCH transcoder A FIFO underrun (xorg-x11-drv-intel)

Please advise whether it's an actual systemd bug or not.

(In reply to Benjamin Masse from comment #8)
> Please advise whether it's an actual systemd bug or not.
Probably not. We expect the font to stay put once set. Let's see if resolving #1131914 fixes your problem.

This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. 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 EOL if it remains open with a Fedora  'version'
of '20'.

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.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 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 this bug is closed as described in the policy above.

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.

Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.