Reporting 'Unable to load such font with such kernel version' at boot

[thealio]

Hi I reported this bug, about this error message that appeared after the latest kernel update (in my case latest 6.1 LTS) on Arch Linux https://bugs.archlinux.org/task/78958

[Vogtinator]

I suspect it's called either before the graphical console was initialized or for a text only console.

Before https://github.com/legionus/kbd/commit/1e15af4d8b272ca50e9ee1d0c584c5859102c848, this was simply ignored.

[legionus]

what kernel version are you using? what font are you trying to load?

[thealio]

Kernel 6.1lts

Terminus fonts

[legionus]

Kernel 6.1lts

OK, old kernel. I mean a pre-tall-font kernel.

Terminus fonts

@thealio I don't know these fonts. can you give a link to them?

[rosslaird]

I was seeing this with kernel 6.4.1, using the ter-132n terminus font (on Arch). As @thealio notes in the bug report, changing keymap consolefont to the combined notation sd-vconsole in mkinitcpio.conf and regenerating the kernel seems to resolve the issue. This fix works for me for both ter-132n and ter-132b fonts.

[sajcho]

Linux 6.4.1 - boot without ramdisk kernel config:

CONFIG_FONT_SUPPORT=y CONFIG_FONTS=y # CONFIG_FONT_8x8 is not set CONFIG_FONT_8x16=y # CONFIG_FONT_6x11 is not set # CONFIG_FONT_7x14 is not set # CONFIG_FONT_PEARL_8x8 is not set # CONFIG_FONT_ACORN_8x8 is not set # CONFIG_FONT_MINI_4x6 is not set # CONFIG_FONT_6x10 is not set # CONFIG_FONT_10x18 is not set # CONFIG_FONT_SUN8x16 is not set # CONFIG_FONT_SUN12x22 is not set # CONFIG_FONT_TER16x32 is not set # CONFIG_FONT_6x8 is not set CONFIG_FONT_AUTOSELECT=y

I use fonts terminus - ter-v16n Booting without problem

[legionus]

I suspect it's called either before the graphical console was initialized or for a text only console.

Before 1e15af4, this was simply ignored.

About this message: Before that, ENOSYS was ignored. The lack of a message only masked the problem - the kernel returned an error when trying to load the font.

[acheronfail]

If it helps, I'm also seeing this with Linux 6.1.37.

In /etc/vconsole.conf I have:

FONT=solar24x32

In /etc/mkinitcpio.conf I have:

# ...
BINARIES=(setfont)
# ...
HOOKS=(base udev autodetect modconf kms keyboard keymap consolefont block encrypt filesystems fsck)
# ...

[legionus]

If it helps, I'm also seeing this with Linux 6.1.37.

In /etc/vconsole.conf I have:

FONT=solar24x32

@acheronfail framebuffer is used, right?

[acheronfail]

Not sure? Whatever is the default I guess. I'm using integrated intel graphics (no discrete GPUs, etc). I haven't added i915 to mkinitcpio.conf's MODULES or anything.

dmesg shows these lines:

❯ sudo dmesg | rg -e framebuffer -e 'fb\d+'
709:[    0.963349] efifb: framebuffer at 0x4000000000, using 36000k, total 36000k
714:[    0.963373] fb0: EFI VGA frame buffer device
880:[    2.743782] fbcon: i915drmfb (fb0) is primary device
882:[    2.743787] i915 0000:00:02.0: [drm] fb0: i915drmfb frame buffer device

Let me know if you have a way for me to check it to be sure, etc.

Oh, if it helps, I get this error logged before my LUKS decryption prompt - so it's only occurring in the initramfs stage.

[legionus]

Do I understand correctly that the previous version loads the font and it is visually visible? I mean before decrypting the root partition.

[openscript]

Do I understand correctly that the previous version loads the font and it is visually visible? I mean before decrypting the root partition.

I'm not 100% sure if the font was loaded and used before, but there was no error message. How can I validate this for you? I can reproduce the error on my machine.

[legionus]

I'm not 100% sure if the font was loaded and used before, but there was no error message. How can I validate this for you? I can reproduce the error on my machine.

You can add init=/bin/sh to cmdline to eliminate system influence. And put some large font in the initramfs (for example, solar24x32) to see the difference.

If the setfont from the previous version loads the font, but the new one doesn't, then this is a regression.

[acheronfail]

I downgraded to kbd-2.5.1 on my system (Arch) and the error is gone, but the font is not loaded (I couldn't remember if the font loaded before the decryption prompt or after :laughing:).

So I don't think this is a regression, but it's just an extra log that now appears... Though I swear I had this working before the decryption prompt at some point... perhaps I'm mistaken

[openscript]

I'm not 100% sure if the font was loaded and used before, but there was no error message. How can I validate this for you? I can reproduce the error on my machine.

You can add init=/bin/sh to cmdline to eliminate system influence. And put some large font in the initramfs (for example, solar24x32) to see the difference.

If the setfont from the previous version loads the font, but the new one doesn't, then this is a regression.

I've tried it and it seems that the fonts aren't loaded.

[legionus]

Exactly. Previously, a certain class of errors was simply ignored and it seemed that everything was working. But it's not. The font didn't load. If you load some very different font, then the problem is immediately visible, but if the font is not very different (for example, UniCyr_8x16), then this error is not so obvious. I added an error message so as not to confuse users that a new font has been loaded.

I'm going to close this bug because the message matches what's going on.

[Vogtinator]

The issue is that this message is printed even when it's somewhat expected but unavoidable, see also https://github.com/systemd/systemd/commit/93c9a9d235e2304500c490b4868534385f925c76 and the downstream bug report https://bugzilla.opensuse.org/show_bug.cgi?id=1212970

I don't see a simple way to figure out whether a given tty is able to handle fonts or not to decide whether setfont can be called or not.

[legionus]

@Vogtinator This message is shown if ioctl with KD_FONT_OP_SET returned ENOSYS. There are several reasons for this error:

• The KD_FONTOP* operation is not supported by the current kernel. This is unlikely because this can only happen with large fonts, which were added to the 6.2 kernel. https://github.com/torvalds/linux/blob/master/drivers/tty/vt/vt.c#L4683

• Font loading is not supported for the current console type. Neither fbcon nor vgacon nor newpost can return ENOSYS from their implementations. https://github.com/torvalds/linux/blob/master/drivers/tty/vt/vt.c#L4628

If you do not tell setfont which device to use, the utility will look for it itself: https://github.com/legionus/kbd/blob/master/src/libcommon/getfd.c#L13

But since we see the ENOSYS error, the device that was selected is not suitable. It's definitely a terminal, but for some reason it doesn't support loading fonts. The only obvious thing is that setfont was run in the wrong environment.

To specify the correct terminal there is the -C option. systemd-vconsole-setup should use it.

I'm also know that systemd doesn't properly start the console configuration service and that this can cause errors: https://github.com/legionus/kbd/issues/92#issuecomment-1554451788

[Vogtinator]

Font loading is not supported for the current console type. Neither fbcon nor vgacon nor newpost can return ENOSYS from their implementations. https://github.com/torvalds/linux/blob/master/drivers/tty/vt/vt.c#L4628

My suspicion is that systemd-vconsole-setup is started at a time when /dev/ttyX is still a dummy console, without support for font loading.

[legionus]

My suspicion is that systemd-vconsole-setup is started at a time when /dev/ttyX is still a dummy console, without support for font loading.

That would be the explanation for what's going on. Either way, the setfont error message points to a real problem. Perhaps systemd-vconsole-setup should check and not run on such a console.

I think it's worth asking someone who knows better about systemd.

@keszybz Could you help us ?

[Vogtinator]

My suspicion is that systemd-vconsole-setup is started at a time when /dev/ttyX is still a dummy console, without support for font loading.

That would be the explanation for what's going on. Either way, the setfont error message points to a real problem.

Not necessarily. systemd-vconsole-setup runs multiple times during boot: Once the .service way ASAP during boot and then triggered by udev for each time a vtcon appears. So it'll end up set up properly even if some earlier runs were against the dummy console.

Perhaps systemd-vconsole-setup should check and not run on such a console.

Yes, question is how. Check which /sys/class/vtconsole/vtconX has bind set and look at its name?

[keszybz]

Note that we're still figuring out how systemd-vconsole-setup should be called in early boot. https://github.com/systemd/systemd/pull/27867 is the latest attempt. Earlier versions are all known to be borked in some scenarios.

Perhaps systemd-vconsole-setup should check and not run on such a console.

Yes, question is how. Check which /sys/class/vtconsole/vtconX has bind set and look at its name?

Yeah, we could add a test. I don't know enough about the kernel semantics, but if somebody tells me what to check, I'd be happy to implement this.

[legionus]

Perhaps systemd-vconsole-setup should check and not run on such a console.

Yes, question is how. Check which /sys/class/vtconsole/vtconX has bind set and look at its name?

Possibly. I'm afraid to give bad advice now. To answer, I need to look at the console parameters that are passed to setfont. We can make a wrapper for setfont and see how they differ.

[lfom]

I also started to have the same error while booting a while ago, changed to sd-vconsole and the error message is not shown on the screen anymore, but it seems that the error still happens, it is just hidden now:

$ journalctl --no-hostname -b | grep -i -e vconsole
jul 20 20:01:26 systemd-vconsole-setup[334]: Failed to import credentials, ignoring: No such file or directory
jul 20 20:01:26 systemd-vconsole-setup[334]: /usr/bin/setfont failed with exit status 71.
jul 20 20:01:26 systemd-vconsole-setup[334]: Setting fonts failed with a "system error", ignoring.
jul 20 20:01:26 systemd-vconsole-setup[336]: setfont: ERROR kdfontop.c:183 put_font_kdfontop: Unable to load such font with such kernel version

$ grep ^HOOKS /etc/mkinitcpio.conf
HOOKS=(base systemd autodetect modconf kms keyboard sd-vconsole block filesystems)

$ grep FONT /etc/vconsole.conf
FONT=ter-120n
FONT_MAP=8859-2

I had added setfont to BINARIES in mkinitcpio.conf a long time ago to make the config in vconsole.conf work, but it seems that it is not needed anymore, but either adding it or not, it does not seem to change anything.

[hainingning]

I was seeing this with kernel 6.4.1, using the ter-132n terminus font (on Arch). As @thealio notes in the bug report, changing keymap consolefont to the combined notation sd-vconsole in mkinitcpio.conf and regenerating the kernel seems to resolve the issue. This fix works for me for both ter-132n and ter-132b fonts.

thanks, this works for me

[T0MuX]

Hi, I confirm this worked for me too ! Thank you !

A bit of details : I was using consolefont in mkinitcpio.conf, juste replaced by sd-vconsole (before block like @lfom's mkinitcpio.conf), regenerated mkinit, and now it's ok ! I even don't have any error by firing journalctl --no-hostname -b | grep -i -e vconsole :nerd_face:

And there is my vconsole.conf :

KEYMAP=fr-latin9
FONT=ter-222b

[lfom]

FONT=ter-222b

Hmm, it seems that the error actually happens when the chosen font is not included in the kernel. But then I do not understand why ter-222b would work since it seems that the only Terminus font included in the kernel is ter-132:

$ zcat /proc/config.gz | grep FONT
CONFIG_FONT_SUPPORT=y
CONFIG_FONTS=y
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
# CONFIG_FONT_6x11 is not set
# CONFIG_FONT_7x14 is not set
# CONFIG_FONT_PEARL_8x8 is not set
CONFIG_FONT_ACORN_8x8=y
# CONFIG_FONT_MINI_4x6 is not set
CONFIG_FONT_6x10=y
# CONFIG_FONT_10x18 is not set
# CONFIG_FONT_SUN8x16 is not set
# CONFIG_FONT_SUN12x22 is not set
CONFIG_FONT_TER16x32=y
# CONFIG_FONT_6x8 is not set

[barzog]

Some additions for those who came there on google search link: On my system (similar to [thealio], i.e. archlinux) I had same problem after kbd upgrade (but on 6.1.30 and using dracut). After digging it turns on that [Vogtinator] was right: in default arch setup graphiccard driver (i915 in my case) was loaded before vconsole setup. Solution cames from here and it turn out that the problem was in "deferred" fbcon takeover due to kernel compile option: CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER=y, so due to that we have text-only console After modifyind kernel cmdline to include fbcon=nodefer - all works perfectly (modifying systemd-vconsole-setup.service should also work). So before we had:

kernel: fbcon: Deferring console take-over
systemd[1]: Starting Setup Virtual Console...
systemd[1]: Finished Setup Virtual Console.
systemd-vconsole-setup[215]: /usr/bin/setfont failed with exit status 71.
systemd-vconsole-setup[215]: Setting fonts failed with a "system error", ignoring.
systemd-vconsole-setup[220]: setfont: ERROR kdfontop.c:183 put_font_kdfontop: Unable to load such font with such kernel version
kernel: fbcon: i915drmfb (fb0) is primary device
kernel: fbcon: Deferring console take-over      

After change:

systemd[1]: Starting Setup Virtual Console...
systemd[1]: Finished Setup Virtual Console.
kernel: fbcon: i915drmfb (fb0) is primary device
kernel: Console: switching to colour frame buffer device 240x67

and no errors in systemctl status systemd-vconsole-setup In dracut.conf: add_drivers+=" i915 " and add fbcon=nodefer to kernel_cmdline

Those changes works only when external display is connected. In order to get setfont even without connected display some additional steps needs to be performed: Add to cmdline video=HDMI-A-1:1920x1080@60e drm.edid_firmware=edid/1920x1080.bin rd.modules-load=i915 First options (video) forces HDMA-A-1 output to be in connected state, regardless whether real display is connected (in mode 1920x1080@60Hz' 2nd option (drm) - allows to setting 1920x1080 mode in video option using default kernel edit 3rd opton (modules-load) - allows us to alter systemd-vconsole-setup service. After that we need to alter /usr/lib/systemd/system/systemd-vconsole-setup.service and add After=systemd-modules-load.service to [Unit] section So console setting will be called after systemd load modules (and we load i915 by using rd.modules-load).

[acheronfail]

Beautiful! Thank you @barzog!

I can confirm that your solution fixed it for me, now the font is updating properly.

Adding i915 to /etc/mkinitcpio.conf:

# ...
MODULES=(i915)
# ...

And, adding fbcon=nodefer to my kernel command line means that the font now updates properly with no errors.

[D3vil0p3r]

I just added fbcon=nodefer and I don't get the issue anymore. How can we verify that the font is loaded properly?

[acheronfail]

@D3vil0p3r if you change to font to something much different to the default font, you can notice the font changing.

I set mine to solar: https://github.com/legionus/kbd/issues/99#issuecomment-1621470094 which is a fairly large font, if you do the same you should see the font you set early on as a sign of it working

[VladimirFomin90]

В комментах на баг-трекере есть рецепт: "Replacing the hooks keymap and consolefont with sd-vconsole and regenerating the kernel image will remove the message." Если заменить хуки keymap и consolefont на sd-vconsole, то действительно ошибка исчезает. Чем это грозит и в чем разница я не стал вникать. ))

[lfom]

As of today, it seems that the error is gone, using either keymap consolefont or just sd-vconsole in HOOKS, without the need to add setfont to BINARIES, and the custom font is correctly applied to all VTs after boot. Tested with both Arch LTS and Zen kernels.

For me adding fbcon=nodefer actually prevented the custom font to be applied using either HOOKS setting (I was hoping it would actually fix the screen flicker that started to happen somewhere after kernel 6.0, but it didn't).

The log shows some error, but it seems harmless and it is not visible during boot either:

$ journalctl --no-hostname -b | grep -i -e vconsole       # booting with sd-vconsole
ago 05 16:48:14 systemd[1]: systemd-vconsole-setup.service: Deactivated successfully.
ago 05 16:48:14 systemd-vconsole-setup[507]: KD_FONT_OP_GET failed while trying to get the font metadata: Invalid argument
ago 05 16:48:14 systemd-vconsole-setup[507]: Fonts will not be copied to remaining consoles

$ pacman -Q | grep -e kbd -e systemd
kbd 2.6.1-1
lib32-systemd 254-1
libgnomekbd 1:3.28.1-1
mkinitcpio-systemd-tool 37-3
systemd 254-1
systemd-libs 254-1
systemd-oomd-defaults 253.5-1
systemd-sysvcompat 254-1

[tobrunn]

This issue is not solved! Since update to systemd 254-1 the 'sd-vconsole' hook does not work with busybox based init anymore. Neither keymap nor consolefont are applied. With mkinitcpio hooks 'keymap consolefont' the keymap is applied at last but consolefont is ignored and the error message "ERROR kdfontop.c:183 put_font_kdfontop: Unable to load such font with such kernel version" appears again.

[lfom]

@tobrunn What font are you using? Did you try using one of the kernel builtin fonts (check one of my previous comments)?

[gavsiu]

Beautiful! Thank you @barzog!

I can confirm that your solution fixed it for me, now the font is updating properly.

Adding i915 to /etc/mkinitcpio.conf:

# ...
MODULES=(i915)
# ...

And, adding fbcon=nodefer to my kernel command line means that the font now updates properly with no errors.

I didn't even need to add i915 for this to work.