Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#35721 - [systemd] systemd-vconsole-setup silently fails to load FONT

Attached to Project: Arch Linux
Opened by Lukas B (teateawhy) - Saturday, 08 June 2013, 13:44 GMT
Last edited by Dave Reisner (falconindy) - Tuesday, 30 July 2013, 11:29 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Dave Reisner (falconindy)
Tom Gundersen (tomegun)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No

Details

Some characters show the wrong symbols on the tty commandline.
Whenever a German umlaut should be displayed, it shows this instead:

ö: the greek letter beta
ä: the right guillemet (http://en.wikipedia.org/wiki/Guillemets)
ü: the pilcrow (http://en.wikipedia.org/wiki/Pilcrow)
Eszett: the letter t with an accent under it

The font is configured here:
/etc/vconsole.conf
KEYMAP=de-latin1-nodeadkeys
FONT=Lat2-Terminus16

systemctl status systemd-vconsole-setup.service shows status=0/SUCCESS .

I can succesfully set the font with 'setfont Lat2-Terminus16' .

Also the font works as designed, including Umlaute, after doing this:
'systemctl restart sytemd-vconsole-setup.service'

There seems to be a race-condition, where vconsole-setup.service does not work while booting. After booting is completed it does work.
The bug did never show up on my older installation with the exact same settings, but it shows up on a newer installation on usb stick.
Other users having this issue:
https://bbs.archlinux.org/viewtopic.php?id=161116
https://bbs.archlinux.org/viewtopic.php?id=161339
(Adding the 'consolefont' hook to mkinitcpio.conf does not solve the issue.)
This task depends upon

Closed by  Dave Reisner (falconindy)
Tuesday, 30 July 2013, 11:29 GMT
Reason for closing:  Won't fix
Additional comments about closing:  This is a limitation of CONFIG_VT and framebuffers. Either load your graphics driver earlier, or use something like kmscon which has its own font config.
Comment by Dave Reisner (falconindy) - Saturday, 08 June 2013, 13:47 GMT
Graphics driver is relevant. I suspect this is yet another case of vconsole-setup being run before udev loads the graphics driver, triggering KMS and the framebuffer switch (which resets the kernel font).
Comment by Lukas B (teateawhy) - Saturday, 08 June 2013, 13:59 GMT
On my other installation that does not have this issue, i set KMS on the kernel commandline:
i915.modeset=1 modprobe.blacklist=vesafb
That means KMS is not executed from udev, and therefore there is no framebuffer switch, and the kernel font is not reset.

On the problematic installation i have not installed graphics drivers or enabled KMS explicitly. (It is xf86-video-intel)
Comment by Dave Reisner (falconindy) - Saturday, 08 June 2013, 14:05 GMT
> That means KMS is not executed from udev
No. That kernel commandline alone doesn't do anything to load the driver -- it only sets options which kmod will later interpret.
Comment by Lukas B (teateawhy) - Saturday, 08 June 2013, 14:10 GMT
Ok. thanks for explaining.
Comment by Lukas B (teateawhy) - Saturday, 08 June 2013, 15:26 GMT
This is way over my head, but if i understand correctly the linux kernel does not restore the font after a driver is loaded. Is that a bug in the kernel, or is this supposed to be done from userspace (systemd)?
Comment by Jan de Groot (JGC) - Tuesday, 11 June 2013, 15:14 GMT
Loading a framebuffer driver will cause a reset, so you'll lose all settings. The better solution here is to load the framebuffer console driver (i915 in your case) from initramfs. Maybe our autodetect hook should just include such drivers by default.
Comment by Dave Reisner (falconindy) - Tuesday, 11 June 2013, 15:17 GMT
> Maybe our autodetect hook should just include such drivers by default.
Autodetect already does whitelist graphics drivers -- what we would need is to add a "graphics" hook which would add the driver in accordance with the whitelist.

Loading...